[jira] [Commented] (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457326#comment-13457326 ] Sean Timm commented on SOLR-139: It appears that SolrJ does not yet (as of 4.0 Alpha) support updating fields in a document. Is there a separate Jira ticket for this? Support updateable/modifiable documents --- Key: SOLR-139 URL: https://issues.apache.org/jira/browse/SOLR-139 Project: Solr Issue Type: New Feature Components: update Reporter: Ryan McKinley Fix For: 4.1 Attachments: Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, SOLR-139_createIfNotExist.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139.patch, SOLR-139.patch, SOLR-139-XmlUpdater.patch, SOLR-269+139-ModifiableDocumentUpdateProcessor.patch It would be nice to be able to update some fields on a document without having to insert the entire document. Given the way lucene is structured, (for now) one can only modify stored fields. While we are at it, we can support incrementing an existing value - I think this only makes sense for numbers. for background, see: http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] Created: (SOLR-1810) DataImportHandler: dataimporter.functions.formatDate should have a redefined concept of NOW for each import
DataImportHandler: dataimporter.functions.formatDate should have a redefined concept of NOW for each import --- Key: SOLR-1810 URL: https://issues.apache.org/jira/browse/SOLR-1810 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Sean Timm Assignee: Noble Paul Fix For: 1.5 MySQL requires that the backslash and the quote character used to quote the string in the query be escaped. Currently only single and double quotes are escaped. See: http://dev.mysql.com/doc/refman/4.1/en/mysql-real-escape-string.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-1810) DataImportHandler: dataimporter.functions.formatDate should have a redefined concept of NOW for each import
[ https://issues.apache.org/jira/browse/SOLR-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm closed SOLR-1810. --- Resolution: Won't Fix Clone in JIRA didn' t work the way I thought it would. :-) DataImportHandler: dataimporter.functions.formatDate should have a redefined concept of NOW for each import --- Key: SOLR-1810 URL: https://issues.apache.org/jira/browse/SOLR-1810 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Sean Timm Assignee: Noble Paul Fix For: 1.5 MySQL requires that the backslash and the quote character used to quote the string in the query be escaped. Currently only single and double quotes are escaped. See: http://dev.mysql.com/doc/refman/4.1/en/mysql-real-escape-string.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1811) DataImportHandler: dataimporter.functions.formatDate should have a redefined concept of NOW for each import
DataImportHandler: dataimporter.functions.formatDate should have a redefined
concept of NOW for each import
---
Key: SOLR-1811
URL: https://issues.apache.org/jira/browse/SOLR-1811
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 1.4
Reporter: Sean Timm
Priority: Minor
Fix For: 1.5
The first argument can be a computed value eg:
'${dataimporter.functions.formatDate('NOW-3DAYS', '-MM-dd HH:mm')}' and it
uses the syntax of the datemath parser in Solr. When using a relative date
with NOW, NOW is set with teh first full-import but not with subsequent
imports. NOW should be redefined with each new import.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1811) DataImportHandler: dataimporter.functions.formatDate should have a redefined concept of NOW for each import
[
https://issues.apache.org/jira/browse/SOLR-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842018#action_12842018
]
Sean Timm commented on SOLR-1811:
-
Looking at the query sent to MySQL, I see that the time doesn't change from the
first invocation. Looking at the code, it looks like
EvaluatorBag.dateMathParser.setNow(new Date()); is never called. I fixed it
locally. I'll upload a patch shortly for you to look over.
DataImportHandler: dataimporter.functions.formatDate should have a redefined
concept of NOW for each import
---
Key: SOLR-1811
URL: https://issues.apache.org/jira/browse/SOLR-1811
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 1.4
Reporter: Sean Timm
Assignee: Noble Paul
Priority: Minor
Fix For: 1.5
The first argument can be a computed value eg:
'${dataimporter.functions.formatDate('NOW-3DAYS', '-MM-dd HH:mm')}' and
it uses the syntax of the datemath parser in Solr. When using a relative
date with NOW, NOW is set with teh first full-import but not with subsequent
imports. NOW should be redefined with each new import.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1811) DataImportHandler: dataimporter.functions.formatDate should have a redefined concept of NOW for each import
[
https://issues.apache.org/jira/browse/SOLR-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Timm updated SOLR-1811:
Attachment: SOLR-1811.patch
DataImportHandler: dataimporter.functions.formatDate should have a redefined
concept of NOW for each import
---
Key: SOLR-1811
URL: https://issues.apache.org/jira/browse/SOLR-1811
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 1.4
Reporter: Sean Timm
Assignee: Noble Paul
Priority: Minor
Fix For: 1.5
Attachments: SOLR-1811.patch
The first argument can be a computed value eg:
'${dataimporter.functions.formatDate('NOW-3DAYS', '-MM-dd HH:mm')}' and
it uses the syntax of the datemath parser in Solr. When using a relative
date with NOW, NOW is set with teh first full-import but not with subsequent
imports. NOW should be redefined with each new 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-1767) DataImportHandler: dataimporter.functions.escapeSql
DataImportHandler: dataimporter.functions.escapeSql --- Key: SOLR-1767 URL: https://issues.apache.org/jira/browse/SOLR-1767 Project: Solr Issue Type: Bug Reporter: Sean Timm -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1767) DataImportHandler: dataimporter.functions.escapeSql() does not escape backslash character
[ https://issues.apache.org/jira/browse/SOLR-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-1767: Labels: dih (was: ) Component/s: contrib - DataImportHandler Fix Version/s: 1.5 Description: MySQL requires that the backslash and the quote character used to quote the string in the query be escaped. Currently only single and double quotes are escaped. See: http://dev.mysql.com/doc/refman/4.1/en/mysql-real-escape-string.html Affects Version/s: 1.4 Summary: DataImportHandler: dataimporter.functions.escapeSql() does not escape backslash character (was: DataImportHandler: dataimporter.functions.escapeSql) DataImportHandler: dataimporter.functions.escapeSql() does not escape backslash character - Key: SOLR-1767 URL: https://issues.apache.org/jira/browse/SOLR-1767 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Sean Timm Fix For: 1.5 MySQL requires that the backslash and the quote character used to quote the string in the query be escaped. Currently only single and double quotes are escaped. See: http://dev.mysql.com/doc/refman/4.1/en/mysql-real-escape-string.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-1767) DataImportHandler: dataimporter.functions.escapeSql() does not escape backslash character
[ https://issues.apache.org/jira/browse/SOLR-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-1767: Attachment: SOLR-1767.patch adds escaping of backslash with a test case. DataImportHandler: dataimporter.functions.escapeSql() does not escape backslash character - Key: SOLR-1767 URL: https://issues.apache.org/jira/browse/SOLR-1767 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Sean Timm Fix For: 1.5 Attachments: SOLR-1767.patch MySQL requires that the backslash and the quote character used to quote the string in the query be escaped. Currently only single and double quotes are escaped. See: http://dev.mysql.com/doc/refman/4.1/en/mysql-real-escape-string.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LUCENE-1390) add ISOLatinAccentFilter and deprecate ISOLatin1AccentFilter
[ https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652808#action_12652808 ] Sean Timm commented on LUCENE-1390: --- From my brief reading, it seems that ae would be the best transliteration for the schwa character. Some people write 'æ' instead if the schwa is not available. http://www.omniglot.com/writing/azeri.htm add ISOLatinAccentFilter and deprecate ISOLatin1AccentFilter Key: LUCENE-1390 URL: https://issues.apache.org/jira/browse/LUCENE-1390 Project: Lucene - Java Issue Type: Improvement Components: Analysis Environment: any Reporter: Andi Vajda Priority: Minor Fix For: 2.9 Attachments: ASCIIFoldingFilter.patch, ASCIIFoldingFilter.patch, ISOLatinAccentFilter.java The ISOLatin1AccentFilter is removing accents from accented characters in the ISO Latin 1 character set. It does what it does and there is no bug with it. It would be nicer, though, if there was a more comprehensive version of this code that included not just ISO-Latin-1 (ISO-8859-1) but the entire Latin 1 and Latin Extended A unicode blocks. See: http://en.wikipedia.org/wiki/Latin-1_Supplement_unicode_block See: http://en.wikipedia.org/wiki/Latin_Extended-A_unicode_block That way, all languages using roman characters are covered. A new class, ISOLatinAccentFilter is attached. It is intended to supercede ISOLatin1AccentFilter which should get deprecated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SOLR-774) Logging admin servlet incorrectly displays the logging level
Logging admin servlet incorrectly displays the logging level Key: SOLR-774 URL: https://issues.apache.org/jira/browse/SOLR-774 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Sean Timm Priority: Minor A bug fix for SOLR-554 (revision 683672) was incorrectly applied resulting in the effective log level being displayed incorrectly. The attached patch fixes the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-774) Logging admin servlet incorrectly displays the logging level
[ https://issues.apache.org/jira/browse/SOLR-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-774: --- Attachment: SOLR-774.patch Logging admin servlet incorrectly displays the logging level Key: SOLR-774 URL: https://issues.apache.org/jira/browse/SOLR-774 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Sean Timm Priority: Minor Attachments: SOLR-774.patch A bug fix for SOLR-554 (revision 683672) was incorrectly applied resulting in the effective log level being displayed incorrectly. The attached patch fixes the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-774) Logging admin servlet displays an incorrect effective logging level
[ https://issues.apache.org/jira/browse/SOLR-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-774: --- Summary: Logging admin servlet displays an incorrect effective logging level (was: Logging admin servlet incorrectly displays the logging level) Logging admin servlet displays an incorrect effective logging level --- Key: SOLR-774 URL: https://issues.apache.org/jira/browse/SOLR-774 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Sean Timm Priority: Minor Attachments: SOLR-774.patch A bug fix for SOLR-554 (revision 683672) was incorrectly applied resulting in the effective log level being displayed incorrectly. The attached patch fixes the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-754) Solr logo on admin pages should always link back to main admin page
Solr logo on admin pages should always link back to main admin page --- Key: SOLR-754 URL: https://issues.apache.org/jira/browse/SOLR-754 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 1.2, 1.3 Reporter: Sean Timm Priority: Trivial Fix For: 1.3 The Solr logo on the threaddump, ping and registry admin pages do not link back to the main admin page as the logos on the other pages do. This patch fixes the hyperlinks in the XSL files for those three admin pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-754) Solr logo on admin pages should always link back to main admin page
[ https://issues.apache.org/jira/browse/SOLR-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-754: --- Attachment: SOLR-754.patch Solr logo on admin pages should always link back to main admin page --- Key: SOLR-754 URL: https://issues.apache.org/jira/browse/SOLR-754 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 1.2, 1.3 Reporter: Sean Timm Priority: Trivial Fix For: 1.3 Attachments: SOLR-754.patch The Solr logo on the threaddump, ping and registry admin pages do not link back to the main admin page as the logos on the other pages do. This patch fixes the hyperlinks in the XSL files for those three admin pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LUCENE-1360) A Similarity class which has unique length norms for numTerms = 10
A Similarity class which has unique length norms for numTerms = 10
---
Key: LUCENE-1360
URL: https://issues.apache.org/jira/browse/LUCENE-1360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Sean Timm
Priority: Trivial
Attachments: ShortFieldNormSimilarity.java
A Similarity class which extends DefaultSimilarity and simply overrides
lengthNorm. lengthNorm is implemented as a lookup for numTerms = 10, else as
{{1/sqrt(numTerms)}}. This is to avoid term counts below 11 from having the
same lengthNorm after stored as a single byte in the index.
This is useful if your search is only on short fields such as titles or product
descriptions.
See mailing list discussion:
http://www.nabble.com/How-to-boost-the-score-higher-in-case-user-query-matches-entire-field-value-than-just-some-words-within-a-field-td19079221.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1360) A Similarity class which has unique length norms for numTerms = 10
[
https://issues.apache.org/jira/browse/LUCENE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Timm updated LUCENE-1360:
--
Attachment: ShortFieldNormSimilarity.java
A Similarity class which has unique length norms for numTerms = 10
---
Key: LUCENE-1360
URL: https://issues.apache.org/jira/browse/LUCENE-1360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Sean Timm
Priority: Trivial
Attachments: ShortFieldNormSimilarity.java
A Similarity class which extends DefaultSimilarity and simply overrides
lengthNorm. lengthNorm is implemented as a lookup for numTerms = 10, else
as {{1/sqrt(numTerms)}}. This is to avoid term counts below 11 from having
the same lengthNorm after stored as a single byte in the index.
This is useful if your search is only on short fields such as titles or
product descriptions.
See mailing list discussion:
http://www.nabble.com/How-to-boost-the-score-higher-in-case-user-query-matches-entire-field-value-than-just-some-words-within-a-field-td19079221.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SOLR-707) DocIterator doesn't support remove(); should throw UnsupportedOperationException
DocIterator doesn't support remove(); should throw UnsupportedOperationException Key: SOLR-707 URL: https://issues.apache.org/jira/browse/SOLR-707 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: Sean Timm Priority: Trivial In DocSlice, DocIterator doesn't support the optional remove operation. According to the Iterator Javadocs, remove should throw an UnsupportedOperationException in this case rather than be a no-op. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-707) DocIterator doesn't support remove(); should throw UnsupportedOperationException
[ https://issues.apache.org/jira/browse/SOLR-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-707: --- Attachment: SOLR-707.patch Patch to throw UnsupportedOperationException and simple Javadoc comment saying the remove() method is not supported. DocIterator doesn't support remove(); should throw UnsupportedOperationException Key: SOLR-707 URL: https://issues.apache.org/jira/browse/SOLR-707 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: Sean Timm Priority: Trivial Attachments: SOLR-707.patch In DocSlice, DocIterator doesn't support the optional remove operation. According to the Iterator Javadocs, remove should throw an UnsupportedOperationException in this case rather than be a no-op. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-589) DisMaxRequestHandler crashes on badly formed query strings ( combinations of - and + )
[ https://issues.apache.org/jira/browse/SOLR-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-589: --- Attachment: SOLR-589.patch Simplified one of the regular expressions and improved performance for queries with a large number of sequential +/- operators. Added two additional test cases to test these scenarios. DisMaxRequestHandler crashes on badly formed query strings ( combinations of - and + ) -- Key: SOLR-589 URL: https://issues.apache.org/jira/browse/SOLR-589 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.2 Environment: all platforms Reporter: bram de jong Priority: Minor Attachments: SOLR-589.patch, SOLR-589.patch, SOLR-589.patch The DisMaxRequestHandler parser crashes on strings which contain double dashes or various combinations of - and + like: chocolate cookie - chocolate -+cookie chocolate --cookie chocolate - - cookie Originally found by me: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser And verified by Sean Tim: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SOLR-554) Hierarchical JDK log level selector for SOLR Admin
[
https://issues.apache.org/jira/browse/SOLR-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Timm reopened SOLR-554:
Found a bug. If a synthesized logger is set to OFF, the below exception is
thrown.
{noformat}
HTTP ERROR: 500
INTERNAL_SERVER_ERROR
RequestURI=/solr/admin/logging
Caused by:
java.lang.NullPointerException
at
org.apache.solr.servlet.LogLevelSelection.doGet(LogLevelSelection.java:134)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
[...]
{noformat}
The fix is to ensure that the Level returned from getEffectiveLevel is not
null. If it is null, return Level.OFF.
{code}
private Level getEffectiveLevel( Logger logger ) {
Level level = logger.getLevel();
for( Level l : LEVELS ) {
if( level != null ) {
return level;
}
if( l == null ) { continue; }
if( logger.isLoggable( l ) ) {
level = l;
}
}
if( level == null ) {
level = Level.OFF;
}
return level;
}
{code}
Hierarchical JDK log level selector for SOLR Admin
--
Key: SOLR-554
URL: https://issues.apache.org/jira/browse/SOLR-554
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: Sean Timm
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 1.3
Attachments: LogLevelSelection.java, SOLR-554-screenshot-3.jpg,
SOLR-554.patch, SOLR-554.patch, SOLR-554.patch
An admin web page to allow displaying and setting the log level of
hierarchical loggers from the UI at runtime. The existing logging.jsp only
sets and displays the root log level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-554) Hierarchical JDK log level selector for SOLR Admin
[ https://issues.apache.org/jira/browse/SOLR-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12619886#action_12619886 ] Sean Timm commented on SOLR-554: There have been times that I've wanted to turn on logging for components outside of Solr. Since it is hierarchical and sorted alphabetically, I've never found it a problem to find the loggers that I am looking for. My preference would be to keep all of the available loggers in the table and keep the configuration to a minimum (right now the user does not need to configure anything). Hierarchical JDK log level selector for SOLR Admin -- Key: SOLR-554 URL: https://issues.apache.org/jira/browse/SOLR-554 Project: Solr Issue Type: Improvement Components: web gui Reporter: Sean Timm Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 1.3 Attachments: LogLevelSelection.java, SOLR-554-screenshot-3.jpg, SOLR-554.patch, SOLR-554.patch, SOLR-554.patch An admin web page to allow displaying and setting the log level of hierarchical loggers from the UI at runtime. The existing logging.jsp only sets and displays the root log level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-527) An XML commit only request handler
[ https://issues.apache.org/jira/browse/SOLR-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-527: --- Attachment: ReadOnlyUpdateProcessorFactory.java Updated to work with recently committed SOLR-660. An XML commit only request handler -- Key: SOLR-527 URL: https://issues.apache.org/jira/browse/SOLR-527 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.3 Reporter: Sean Timm Priority: Trivial Attachments: ReadOnlyUpdateProcessorFactory.java, ReadOnlyUpdateProcessorFactory.java, ReadOnlyUpdateProcessorFactory.java, SOLR-527.patch This request handler only permits commit/ messages. It is provided as one way to prevent adds and deletes on a Solr slave machine that could potentially be accessed by outside parties where a firewall or other access control is either not possible or not desired. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-665) FIFO Cache (Unsynchronized): 9x times performance boost
[ https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617448#action_12617448 ] Sean Timm commented on SOLR-665: Fuad-- I agree with Yonik here. From the HashMap Javadoc: bq. If multiple threads access this map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.) FIFO Cache (Unsynchronized): 9x times performance boost --- Key: SOLR-665 URL: https://issues.apache.org/jira/browse/SOLR-665 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Environment: JRockit R27 (Java 6) Reporter: Fuad Efendi Attachments: FIFOCache.java Original Estimate: 672h Remaining Estimate: 672h Attached is modified version of LRUCache where 1. map = new LinkedHashMap(initialSize, 0.75f, false) - so that reordering/true (performance bottleneck of LRU) is replaced to insertion-order/false (so that it became FIFO) 2. Almost all (absolutely unneccessary) synchronized statements commented out See discussion at http://www.nabble.com/LRUCache---synchronized%21--td16439831.html Performance metrics (taken from SOLR Admin): LRU Requests: 7638 Average Time-Per-Request: 15300 Average Request-per-Second: 0.06 FIFO: Requests: 3355 Average Time-Per-Request: 1610 Average Request-per-Second: 0.11 Performance increased 9 times which roughly corresponds to a number of CPU in a system, http://www.tokenizer.org/ (Shopping Search Engine at Tokenizer.org) Current number of documents: 7494689 name: filterCache class:org.apache.solr.search.LRUCache version: 1.0 description: LRU Cache(maxSize=1000, initialSize=1000) stats:lookups : 15966954582 hits : 16391851546 hitratio : 0.102 inserts : 4246120 evictions : 0 size : 2668705 cumulative_lookups : 16415839763 cumulative_hits : 16411608101 cumulative_hitratio : 0.99 cumulative_inserts : 4246246 cumulative_evictions : 0 Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12612596#action_12612596 ] Sean Timm commented on SOLR-502: I think that the code is fine as is. Just the Javadoc comment needs to be changed. The Integer is explicitly cast to a long when it is used. And as you note, 1.6 years is plenty long enough. :-) Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Yonik Seeley Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12612176#action_12612176 ] Sean Timm commented on SOLR-502: Yonik-- I just noticed that the Javadoc specifies Long, but the setTimeAllowed function takes an Integer in org.apache.solr.client.solrj.SolrQuery. Thanks, Sean Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Yonik Seeley Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611758#action_12611758 ] Sean Timm commented on SOLR-303: Another option is to pass state on the number of documents and positions retrieved from each shard. I have a client layer that can do that, so it works, but it is complicated, maintaining state is messy, and the vast majority of requests are first page requests so in practice we almost never use that feature, but instead do exactly as is implemented here and request the full document count from each shard. Distributed Search over HTTP Key: SOLR-303 URL: https://issues.apache.org/jira/browse/SOLR-303 Project: Solr Issue Type: New Feature Components: search Reporter: Sharad Agarwal Assignee: Yonik Seeley Fix For: 1.3 Attachments: distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed_add_tests_for_intended_behavior.patch, distributed_facet_count_bugfix.patch, distributed_pjaol.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, fedsearch.stu.patch, shards.start_rows.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch Searching over multiple shards and aggregating results. Motivated by http://wiki.apache.org/solr/DistributedSearch -- 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-527) An XML commit only request handler
[
https://issues.apache.org/jira/browse/SOLR-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591678#action_12591678
]
timmsc edited comment on SOLR-527 at 6/27/08 6:48 AM:
-
I serendipitously discovered what is probably the cleanest way to only allow
commits on the slave. If the index is owned by user A with permissions
{noformat}-rw-r--r--{noformat} yet the slave solr process is run as user B,
only read operations are allowed. This is obvious in retrospect. I just
didn't think of it.
was (Author: timmsc):
I serendipitously discovered what is probably the cleanest way to only
allow commits on the slave. If the index is owned by user A with permissions
-rw-r--r-- yet the slave solr process is run as user B, only read operations
are allowed. This is obvious in retrospect. I just didn't think of it.
An XML commit only request handler
--
Key: SOLR-527
URL: https://issues.apache.org/jira/browse/SOLR-527
Project: Solr
Issue Type: New Feature
Components: update
Affects Versions: 1.3
Reporter: Sean Timm
Priority: Trivial
Attachments: ReadOnlyUpdateProcessorFactory.java,
ReadOnlyUpdateProcessorFactory.java, SOLR-527.patch
This request handler only permits commit/ messages. It is provided as one
way to prevent adds and deletes on a Solr slave machine that could
potentially be accessed by outside parties where a firewall or other access
control is either not possible or not desired.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: SOLR-502.patch Added a SolrIndexSearcher.search() method that uses a command pattern. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[
https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608527#action_12608527
]
Sean Timm commented on SOLR-572:
For what it is worth, here is the code that I used client side before the
collation feature was available. I haven't looked at how it is done in this
patch. It has some nice features such as delimiting the spelling correction,
e.g., with HTML bold tags, and preserving the users initial case on each word.
{code}
StringBuilder buff = new StringBuilder();
StringBuilder rawBuff = new StringBuilder();
int last = 0;
String userStr = null;
// for each suggestion
for( Suggestion s : suggestions ) {
// add part before the mispelling
userStr = userQuery.substring( last, s.startOffset );
buff.append( userStr );
rawBuff.append( userStr );
String suggestion = s.suggestion;
if( _spellCheckPreserveUserCase ) {
userStr = userQuery.substring( s.startOffset, s.endOffset );
char[] userCh = userStr.toCharArray();
boolean initialUpper = Character.isUpperCase( userCh[0] );
boolean allUpper = true;
for( char c : userCh ) {
if( Character.isLowerCase( c ) ) {
allUpper = false;
break;
}
}
if( allUpper ) {
suggestion = suggestion.toUpperCase();
}
else if( initialUpper ) {
userCh = suggestion.toCharArray();
userCh[0] = Character.toUpperCase( userCh[0] );
suggestion = new String( userCh );
}
}
buff.append( _spellCheckStartHighlight ).append( suggestion )
.append( _spellCheckEndHighlight );
rawBuff.append( suggestion );
last = s.endOffset;
}
// add part after all mispellings
userStr = userQuery.substring( last );
buff.append( userStr );
rawBuff.append( userStr );
if( log().isDebugEnabled() ) {
log().debug( Did you mean: + buff );
log().debug( Did you mean link: + rawBuff );
}
{code}
Spell Checker as a Search Component
---
Key: SOLR-572
URL: https://issues.apache.org/jira/browse/SOLR-572
Project: Solr
Issue Type: New Feature
Components: spellchecker
Affects Versions: 1.3
Reporter: Shalin Shekhar Mangar
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.3
Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch
http://wiki.apache.org/solr/SpellCheckComponent
Expose the Lucene contrib SpellChecker as a Search Component. Provide the
following features:
* Allow creating a spell index on a given field and make it possible to have
multiple spell indices -- one for each field
* Give suggestions on a per-field basis
* Given a multi-word query, give only one consistent suggestion
* Process the query with the same analyzer specified for the source field and
process each token separately
* Allow the user to specify minimum length for a token (optional)
Consistency criteria for a multi-word query can consist of the following:
* Preserve the correct words in the original query as it is
* Never give duplicate words in a suggestion
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-607) Commit only request handler for read only slaves
[
https://issues.apache.org/jira/browse/SOLR-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608647#action_12608647
]
Sean Timm commented on SOLR-607:
How is this different from SOLR-527?
Commit only request handler for read only slaves
Key: SOLR-607
URL: https://issues.apache.org/jira/browse/SOLR-607
Project: Solr
Issue Type: New Feature
Components: update
Reporter: Hoss Man
Replication currently requires that the snapinstaller script be able to use
curl to hit a URL (/update) to stream a {{{commit/}} command to.
To help make it easier to secure read only Solr slave instances, we should
add a CommitOnlyRequestHandler which would ignore all content streams and
could be used on slaves in place of XmlUpdateRequestHandler just for
triggering a commit to open a new Searcher.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606798#action_12606798 ] Sean Timm commented on SOLR-502: Are you thinking the command pattern would be the preferred way of doing a SolrIndexSearcher.search(), possibly even deprecating the existing methods? I think that makes sense, but seems to be a big change to add to this patch. I think I'd prefer to see it fleshed out in a separate issue. The methods returning Hits should probably be deprecated in Solr 1.3 anyway since Hits is going away in Lucene 3.0. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: SOLR-502.patch Changes the setting of the partialResults flag from the results to the responseHeader. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606428#action_12606428 ] Sean Timm commented on SOLR-502: The timeout is to protect the server side. The client side can be largely protected by setting a read timeout, but if the client aborts before the server responds, the server is just wasting resources processing a request that will never be used. The partial results is useful in a couple of scenarios, probably the most important is a large distributed complex where you would rather get whatever results you can from a slow shard rather than throw them away. As a real world example, the query contact us about our site on a 2.3MM document index (partial Dmoz crawl) takes several seconds to complete, while the mean response time is sub 50 ms. We've had cases where a bot walks the next page links (including expensive queries such as this). Also users are prone to repeatedly click the query button if they get impatient on a slow site. Without a server side timeout, this is a real issue. Rate limiting and limiting the number of next pages that can be fetched at the front end are also part of the solution to the above example. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606473#action_12606473 ] Sean Timm commented on SOLR-502: bq. that definitely cuts down the patch size [...] What's your take? Before I made the change, I was against it as it seems more logical to have the partialResults associated with the results list, where the total count, etc. are. But this greatly simplifies the patch. I could go either way. bq. Another thing to consider is perhaps a SolrIndexSearcher.search() method that uses a command pattern I think I agree. :-) How is this different than my suggestion of passing the ResponseBuilder into the searcher? It seems that it would be useful to take it even a step further and pass the ResonseBuilder object around everywhere including the response handlers and writers. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606050#action_12606050 ] Sean Timm commented on SOLR-502: I've been thinking about putting the timeout info in the response header. Throwing an exception from the searcher will not work because that sacrifices the ability to get partial results. I really feel that having the partial results flag as an attribute on the response tag makes more sense than putting it in the resonse header as the partial results pertains to the results section of the response. I will create an alternate patch however with the partial results flag in the response header to compare the two methods. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605666#action_12605666 ] Sean Timm commented on SOLR-303: In SOLR-502, there is the notion of partialResults. It seems that the same flag could be used in this case. Perhaps a string should also be added indicating why all results were not able to be returned. Distributed Search over HTTP Key: SOLR-303 URL: https://issues.apache.org/jira/browse/SOLR-303 Project: Solr Issue Type: New Feature Components: search Reporter: Sharad Agarwal Assignee: Yonik Seeley Fix For: 1.3 Attachments: distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed_add_tests_for_intended_behavior.patch, distributed_facet_count_bugfix.patch, distributed_pjaol.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch Searching over multiple shards and aggregating results. Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605714#action_12605714 ] Sean Timm commented on SOLR-502: Yonik-- Do you have a suggestion on how to get it into the response header? That isn't available down at the SolrIndexSearcher level as far as I can tell. It would be much easier if the ResponseBuilder or some other object was passed all the way down to the searcher level, but I was trying to make the smallest change possible. I think an easy machine readable value to indicate partial results is important. I think a descriptive string is optional, but would be a nice addition. -Sean Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[
https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604617#action_12604617
]
Sean Timm commented on SOLR-572:
It doesn't appear that you can get both extendedResults and count 1. With
the below URL, I get 1 suggestion for each misspelled term regardless of the
value of spellcheck.count. If I set spellcheck.extendedResults=false, then I
get the requested three suggestions for each term.
{noformat}
/solr/spellCheckCompRH/?q=waz+designatd+two+bee+Arvil+25+bye+Pres.+it+wazversion=2.2start=0rows=2indent=onspellcheck=truefl=title,url,id,categories,scorehl=onhl.fl=bodyqt=dismaxspellcheck.extendedResults=truespellcheck.count=3
{noformat}
Spell Checker as a Search Component
---
Key: SOLR-572
URL: https://issues.apache.org/jira/browse/SOLR-572
Project: Solr
Issue Type: New Feature
Components: spellchecker
Affects Versions: 1.3
Reporter: Shalin Shekhar Mangar
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.3
Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
SOLR-572.patch, SOLR-572.patch, SOLR-572.patch
Expose the Lucene contrib SpellChecker as a Search Component. Provide the
following features:
* Allow creating a spell index on a given field and make it possible to have
multiple spell indices -- one for each field
* Give suggestions on a per-field basis
* Given a multi-word query, give only one consistent suggestion
* Process the query with the same analyzer specified for the source field and
process each token separately
* Allow the user to specify minimum length for a token (optional)
Consistency criteria for a multi-word query can consist of the following:
* Preserve the correct words in the original query as it is
* Never give duplicate words in a suggestion
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-589) DisMaxRequestHandler crashes on badly formed query strings ( combinations of - and + )
[ https://issues.apache.org/jira/browse/SOLR-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-589: --- Attachment: SOLR-589.patch This patch strips out consecutive +/- operators, or dangling +/- operators. DisMaxRequestHandler crashes on badly formed query strings ( combinations of - and + ) -- Key: SOLR-589 URL: https://issues.apache.org/jira/browse/SOLR-589 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.2 Environment: all platforms Reporter: bram de jong Priority: Minor Attachments: SOLR-589.patch The DisMaxRequestHandler parser crashes on strings which contain double dashes or various combinations of - and + like: chocolate cookie - chocolate -+cookie chocolate --cookie chocolate - - cookie Originally found by me: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser And verified by Sean Tim: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-589) DisMaxRequestHandler crashes on badly formed query strings ( combinations of - and + )
[ https://issues.apache.org/jira/browse/SOLR-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-589: --- Attachment: SOLR-589.patch Changed to use non-capturing groups. Also reversed the order the regular expressions are run. Both changes are for performance only. DisMaxRequestHandler crashes on badly formed query strings ( combinations of - and + ) -- Key: SOLR-589 URL: https://issues.apache.org/jira/browse/SOLR-589 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.2 Environment: all platforms Reporter: bram de jong Priority: Minor Attachments: SOLR-589.patch, SOLR-589.patch The DisMaxRequestHandler parser crashes on strings which contain double dashes or various combinations of - and + like: chocolate cookie - chocolate -+cookie chocolate --cookie chocolate - - cookie Originally found by me: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser And verified by Sean Tim: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: SOLR-502.patch This patch adds a conditional to ensure backwards compatibility within SOLR 1.3 nightly builds, per Noble Paul's suggestion. Is that necessary? Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: SOLR-502.patch * Adds partialResults support to the binary response, which is used by distributed search. * Really removes the System.out.println() this time. * timeallowed param is now camelcase (timeAllowed). Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[
https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602550#action_12602550
]
Sean Timm commented on SOLR-502:
Sorry about the timeallowed parameter. For some reason I had in my head that
the parameters were not supposed to be camel case and I only switched the
parameter variable names.
You should be seeing a log message similar to:
{noformat}
WARNING: Query: title:s*; Elapsed time: 20Exceeded allowed search time: 1 ms.
{noformat}
even with the previous patch. Though, when using distributed search, the new
binary response is used which I hadn't modified to include partial results
support. It should work with this new patch.
{noformat}
lst name=responseHeader
int name=status0/int
int name=QTime39/int
lst name=params
str
name=shardsnaan.office.aol.com:8973/solr,naan.office.aol.com:8993/solr/str
str name=indenton/str
str name=start0/str
str name=qheadline:s*/str
str name=timeAllowed1/str
str name=version2.2/str
str name=rows100/str
/lst
/lst
result name=response numFound=0 start=0 partialResults=true/
{noformat}
bq. If timeallowed=1, should I ever be seeing QTime over 1?
Yes, the TimeLimitedCollector can only interrupt searches during the collect()
calls. Other, sometimes substantial, work is done outside of the collect().
Also, see the note in the TimeLimitedCollector.setResolution(long) Javadocs
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/javadoc//org/apache/lucene/search/TimeLimitedCollector.html#setResolution(long)
Add search time out support
---
Key: SOLR-502
URL: https://issues.apache.org/jira/browse/SOLR-502
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Sean Timm
Assignee: Otis Gospodnetic
Priority: Minor
Fix For: 1.3
Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch,
solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch,
solrTimeout.patch
Uses LUCENE-997 to add time out support to Solr.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LUCENE-1026) Provide a simple way to concurrently access a Lucene index from multiple threads
[
https://issues.apache.org/jira/browse/LUCENE-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600274#action_12600274
]
Sean Timm commented on LUCENE-1026:
---
bq. 2. Logger.isLoggable is supposed to be faster than logging at a level thats
not turned on.
That is certainly true if you are creating a string from an object, or
concatenating strings. I don't believe that is true for static strings.
E.g., {code}logger.fine(closing cached reading reader);{code} you might as
well skip the Logger.isLoggable. In the case {code}logger.fine(closing cached
searchers ( + cachedSearchers.size() + ));{code} it is certainly better to
check the log level first.
Provide a simple way to concurrently access a Lucene index from multiple
threads
Key: LUCENE-1026
URL: https://issues.apache.org/jira/browse/LUCENE-1026
Project: Lucene - Java
Issue Type: New Feature
Components: Index, Search
Reporter: Mark Miller
Priority: Minor
Attachments: DefaultIndexAccessor.java,
DefaultMultiIndexAccessor.java, IndexAccessor-02.04.2008.zip,
IndexAccessor-02.07.2008.zip, IndexAccessor-02.28.2008.zip,
IndexAccessor-1.26.2008.zip, IndexAccessor-2.15.2008.zip,
IndexAccessor.04032008.zip, IndexAccessor.java, IndexAccessor.zip,
IndexAccessorFactory.java, MultiIndexAccessor.java, shai-IndexAccessor-2.zip,
shai-IndexAccessor.zip, shai-IndexAccessor3.zip, SimpleSearchServer.java,
StopWatch.java, TestIndexAccessor.java
For building interactive indexes accessed through a network/internet
(multiple threads).
This builds upon the LuceneIndexAccessor patch. That patch was not very
newbie friendly and did not properly handle MultiSearchers (or at the least
made it easy to get into trouble).
This patch simplifies things and provides out of the box support for sharing
the IndexAccessors across threads. There is also a simple test class and
example SearchServer to get you started.
Future revisions will be zipped.
Works pretty solid as is, but could use the ability to warm new Searchers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600191#action_12600191 ] timmsc edited comment on SOLR-502 at 5/27/08 9:55 AM: - * Added Javadoc note that a timeallowed param =0 (or omitted) results in no timeout. * Fixed the CamelCase: timeallowed = timeAllowed * Removed the System.out.println(...) statements. bq. I see This should only be called using either filterList or filter, but not both., but I don't see a check for that. Should there be a test for the two vars? This comment was copied from the existing getDocListC method (without the timeAllowed parameter). If there should be a sanity check there, it should probably be added as a separate JIRA issue. was (Author: timmsc): * Added Javadoc note that a timeallowed param =0 (or omitted) results in no timeout. * Fixed the CamelCase: timeallowed = timeAllowed * Removed the System.out.println(...) statements. bq. I see This should only be called using either filterList or filter, but not both., but I don't see a check for that. Should there be a test for the two vars? bq. This comment was copied from the existing getDocListC method (without the timeAllowed parameter). If there should be a sanity check there, it should probably be added as a separate JIRA issue. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502-solrj.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: SOLR-502.patch * Added Javadoc note that a timeallowed param =0 (or omitted) results in no timeout. * Fixed the CamelCase: timeallowed = timeAllowed * Removed the System.out.println(...) statements. bq. I see This should only be called using either filterList or filter, but not both., but I don't see a check for that. Should there be a test for the two vars? bq. This comment was copied from the existing getDocListC method (without the timeAllowed parameter). If there should be a sanity check there, it should probably be added as a separate JIRA issue. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502-solrj.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600196#action_12600196 ] Sean Timm commented on SOLR-502: bq. SOLR-502-solrj.patch is just an old patch that we can really remove so it doesn't confuse anyone, correct? Yes, this is an old patch which can be removed. The solrTimeout.patch files could be removed as well if they are found to be confusing. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502-solrj.patch, SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-554) Hierarchical JDK log level selector for SOLR Admin
[ https://issues.apache.org/jira/browse/SOLR-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-554: --- Attachment: SOLR-554-screenshot-2.jpg LF screenshot Hierarchical JDK log level selector for SOLR Admin -- Key: SOLR-554 URL: https://issues.apache.org/jira/browse/SOLR-554 Project: Solr Issue Type: Improvement Components: web gui Reporter: Sean Timm Priority: Minor Attachments: LogLevelSelection.java, SOLR-554-screenshot-1.jpg, SOLR-554-screenshot-2.jpg, SOLR-554.patch, SOLR-554.patch An admin web page to allow displaying and setting the log level of hierarchical loggers from the UI at runtime. The existing logging.jsp only sets and displays the root log level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-554) Hierarchical JDK log level selector for SOLR Admin
[ https://issues.apache.org/jira/browse/SOLR-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-554: --- Attachment: (was: SOLR-554-screenshot-1.jpg) Hierarchical JDK log level selector for SOLR Admin -- Key: SOLR-554 URL: https://issues.apache.org/jira/browse/SOLR-554 Project: Solr Issue Type: Improvement Components: web gui Reporter: Sean Timm Priority: Minor Attachments: LogLevelSelection.java, SOLR-554-screenshot-2.jpg, SOLR-554.patch, SOLR-554.patch An admin web page to allow displaying and setting the log level of hierarchical loggers from the UI at runtime. The existing logging.jsp only sets and displays the root log level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-554) Hierarchical JDK log level selector for SOLR Admin
[ https://issues.apache.org/jira/browse/SOLR-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-554: --- Attachment: (was: SOLR-554-screenshot-2.jpg) Hierarchical JDK log level selector for SOLR Admin -- Key: SOLR-554 URL: https://issues.apache.org/jira/browse/SOLR-554 Project: Solr Issue Type: Improvement Components: web gui Reporter: Sean Timm Priority: Minor Attachments: LogLevelSelection.java, SOLR-554-screenshot-3.jpg, SOLR-554.patch, SOLR-554.patch, SOLR-554.patch An admin web page to allow displaying and setting the log level of hierarchical loggers from the UI at runtime. The existing logging.jsp only sets and displays the root log level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-554) Hierarchical JDK log level selector for SOLR Admin
[ https://issues.apache.org/jira/browse/SOLR-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-554: --- Attachment: SOLR-554-screenshot-3.jpg Better logo positioning. Hierarchical JDK log level selector for SOLR Admin -- Key: SOLR-554 URL: https://issues.apache.org/jira/browse/SOLR-554 Project: Solr Issue Type: Improvement Components: web gui Reporter: Sean Timm Priority: Minor Attachments: LogLevelSelection.java, SOLR-554-screenshot-3.jpg, SOLR-554.patch, SOLR-554.patch, SOLR-554.patch An admin web page to allow displaying and setting the log level of hierarchical loggers from the UI at runtime. The existing logging.jsp only sets and displays the root log level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-554) Hierarchical JDK log level selector for SOLR Admin
[ https://issues.apache.org/jira/browse/SOLR-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599434#action_12599434 ] Sean Timm commented on SOLR-554: No, like the existing logging.jsp, it doesn't touch the configuration file. When the server is bounced, the log levels revert back to those in the config file. Hierarchical JDK log level selector for SOLR Admin -- Key: SOLR-554 URL: https://issues.apache.org/jira/browse/SOLR-554 Project: Solr Issue Type: Improvement Components: web gui Reporter: Sean Timm Priority: Minor Attachments: LogLevelSelection.java, SOLR-554-screenshot-3.jpg, SOLR-554.patch, SOLR-554.patch, SOLR-554.patch An admin web page to allow displaying and setting the log level of hierarchical loggers from the UI at runtime. The existing logging.jsp only sets and displays the root log level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599085#action_12599085 ] Sean Timm commented on SOLR-502: Otis, I'd be happy to do so. Is there a way to generate a patch excluding the content of another patch without doing a manual editing of the patch file--which would be error prone? Or should I wait until SOLR-505 is committed? Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502-solrj.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-554) Hierarchical JDK log level selector for SOLR Admin
[ https://issues.apache.org/jira/browse/SOLR-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-554: --- Attachment: SOLR-554.patch Patch format this time. Added using the solr-admin.css to help the LF. Includes mods to web.xml and admin/index.jsp to load this servlet instead of the logging.jsp. Hierarchical JDK log level selector for SOLR Admin -- Key: SOLR-554 URL: https://issues.apache.org/jira/browse/SOLR-554 Project: Solr Issue Type: Improvement Components: web gui Reporter: Sean Timm Priority: Minor Attachments: LogLevelSelection.java, SOLR-554-screenshot-1.jpg, SOLR-554.patch An admin web page to allow displaying and setting the log level of hierarchical loggers from the UI at runtime. The existing logging.jsp only sets and displays the root log level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-505) Give RequestHandlers the possiblity to suppress the generation of HTTP caching headers
[ https://issues.apache.org/jira/browse/SOLR-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598751#action_12598751 ] Sean Timm commented on SOLR-505: It worked well for me. I'd like to see it included in 1.3. Give RequestHandlers the possiblity to suppress the generation of HTTP caching headers -- Key: SOLR-505 URL: https://issues.apache.org/jira/browse/SOLR-505 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: Thomas Peuss Attachments: SOLR-505.patch, SOLR-505.patch The code from SOLR-127 emits HTTP cache headers for all handlers if configured. We should not emit cache related headers for update request handlers. Partial responses (coming from the Timeout request stuff) should not be cached as well. To solve this problem we can simply add two methods to the SolrQueryResponse class (like void setAvoidHTTPCaching(boolean) and boolean isAvoidHTTPCaching() - the default for the value would be false). The update request handlers should set this to true all the time. The partial response stuff can set this to true as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-560) Convert JDK logging to SLF4J
[ https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594603#action_12594603 ] Sean Timm commented on SOLR-560: Thanks for taking a look at SOLR-554, Patrick. I did test the log level selector with this SLF4J patch and it works fine as is. It might be desirable to change the log level names in the log level selector to match the names in SLF4J however. From the SLF4J FAQ: SLF4J is only a facade, meaning that it does not provide a complete logging solution. Operations such as [...] setting logging levels cannot be performed with SLF4J. Convert JDK logging to SLF4J Key: SOLR-560 URL: https://issues.apache.org/jira/browse/SOLR-560 Project: Solr Issue Type: Wish Reporter: Ryan McKinley Fix For: 1.3 Attachments: slf4j-api-1.5.0.jar, slf4j-jdk14-1.5.0.jar, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch After lots of discussion, we should consider using SLF4j to enable more flexibility in logging configuration. See: http://www.nabble.com/Solr-Logging-td16836646.html http://www.nabble.com/logging-through-log4j-td13747253.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-554) Hierarchical JDK log level selector for SOLR Admin
[
https://issues.apache.org/jira/browse/SOLR-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Timm updated SOLR-554:
---
Attachment: LogLevelSelection.java
Here is an implementation written in a servlet. To configure, add
{code:xml}
servlet
servlet-nameLogging/servlet-name
servlet-classorg.apache.solr.servlet.LogLevelSelection/servlet-class
/servlet
servlet-mapping
servlet-nameLogging/servlet-name
url-pattern/admin/logging/url-pattern
/servlet-mapping
{code}
to the web.xml configuration.
It doesn't have the same look and feel of the rest of the admin UI, but I did
throw in a link to the Solr logo. :-)
This is adapted from a former co-workers implementation for an AOL internal
framework using Log4j.
Hierarchical JDK log level selector for SOLR Admin
--
Key: SOLR-554
URL: https://issues.apache.org/jira/browse/SOLR-554
Project: Solr
Issue Type: Improvement
Reporter: Sean Timm
Priority: Minor
Attachments: LogLevelSelection.java
An admin web page to allow displaying and setting the log level of
hierarchical loggers from the UI at runtime. The existing logging.jsp only
sets and displays the root log level.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-489) Added @deprecation Javadoc comments
[ https://issues.apache.org/jira/browse/SOLR-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-489: --- Component/s: documentation Added @deprecation Javadoc comments --- Key: SOLR-489 URL: https://issues.apache.org/jira/browse/SOLR-489 Project: Solr Issue Type: Bug Components: documentation Reporter: Sean Timm Priority: Trivial Attachments: deprecationDocumentation.patch In a number of files, @Deprecation annotations were added without accompanying @deprecation Javadoc comments to explain what to use now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-527) An XML commit only request handler
[ https://issues.apache.org/jira/browse/SOLR-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585573#action_12585573 ] Sean Timm commented on SOLR-527: Thanks all for taking a look at this. The ReadOnlyUpdateProcessorFactory.java is great, Ryan. I didn't realize that update processor factories could be chained. That is cleaner than my solution. Hoss, I realize that DOS attacks are still possible, however, my bigger concern is someone modifying our index (e.g., injecting a Viagra advert or the like into our index). An XML commit only request handler -- Key: SOLR-527 URL: https://issues.apache.org/jira/browse/SOLR-527 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.3 Reporter: Sean Timm Priority: Trivial Attachments: ReadOnlyUpdateProcessorFactory.java, ReadOnlyUpdateProcessorFactory.java, SOLR-527.patch This request handler only permits commit/ messages. It is provided as one way to prevent adds and deletes on a Solr slave machine that could potentially be accessed by outside parties where a firewall or other access control is either not possible or not desired. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-527) An XML commit only request handler
An XML commit only request handler -- Key: SOLR-527 URL: https://issues.apache.org/jira/browse/SOLR-527 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.3 Reporter: Sean Timm Priority: Trivial This request handler only permits commit/ messages. It is provided as one way to prevent adds and deletes on a Solr slave machine that could potentially be accessed by outside parties where a firewall or other access control is either not possible or not desired. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: solrTimeout.patch Added the ability to allows timeouts to occur on one or more shards in a distributed search (SOLR-303) and still be merged. The resulting set is reported as a partial result and is not cachable in an HTTP cache. This fixes the last known issue. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Priority: Minor Attachments: SOLR-502-solrj.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580392#action_12580392 ] Sean Timm commented on SOLR-303: Jayson-- I agree. I've been meaning to recommend that be added. We've found it invaluable in the past (mostly with debugging) when doing federated and distributed search. I would like to see a shard field added which would contain the base URI of the shard where the result originated as provided in the request. The index of each result is less important to me, but I can see how that would be useful. Distributed Search over HTTP Key: SOLR-303 URL: https://issues.apache.org/jira/browse/SOLR-303 Project: Solr Issue Type: New Feature Components: search Reporter: Sharad Agarwal Assignee: Yonik Seeley Attachments: distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed.patch, distributed_add_tests_for_intended_behavior.patch, distributed_facet_count_bugfix.patch, distributed_pjaol.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, fedsearch.stu.patch Searching over multiple shards and aggregating results. Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: solrTimeout.patch This patch includes Shalin's SolrJ patch and includes the SOLR-505 patch. HTTP cache headers are now suppressed on a timeout. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Priority: Minor Attachments: SOLR-502-solrj.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: solrTimeout.patch Better handling of timeout condition with other code paths such as sorting by a field. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Priority: Minor Attachments: solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578939#action_12578939 ] Sean Timm commented on SOLR-502: It looks like the recent work on playing nice with external HTTP caches (SOLR-127) will need to be aware of the timeout condition. I do not think a timeout should be cached. Currently an HTTP/1.x 304 Not Modified is returned. I'll try to work this into my next patch update. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Priority: Minor Attachments: solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: solrTimeout.patch This patch adds a partialResults flag which is set to true in the event of a timeout. A partial set of results will be returned (including possibly no results). The flag is supported in the XML, JSON, Ruby, and Python response writers. A count of the number of timeouts is included in the statistics similar to the errors count. Caveats/ToDo: SolrJ is not aware of this setting, nor is distributed search (SOLR-303). Some execution paths may not recognize partial results (such as sorting by field) as I haven't tested those yet. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Priority: Minor Attachments: solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to 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-502) Add search time out support
Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Priority: Minor Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: solrTimeout.patch This patch adds a timeallowed parameter which takes a time out value in milliseconds. On a timeout, an exception is thrown from the searcher which results in a 500 error page with the time out exception message. I'd like to add support to return partial results, but I haven't done that part yet. Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Priority: Minor Attachments: solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-489) Added @deprecation Javadoc comments
[ https://issues.apache.org/jira/browse/SOLR-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-489: --- Attachment: deprecationDocumentation.patch Adds @deprecation comments to many of the files where they are missing. Added @deprecation Javadoc comments --- Key: SOLR-489 URL: https://issues.apache.org/jira/browse/SOLR-489 Project: Solr Issue Type: Bug Reporter: Sean Timm Priority: Trivial Attachments: deprecationDocumentation.patch In a number of files, @Deprecation annotations were added without accompanying @deprecation Javadoc comments to explain what to use now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568280#action_12568280 ] Sean Timm commented on LUCENE-997: -- If there are no more major concerns I think this is now ready to go in, question is where to - under core o.a.l.search or under contrib (query or misc). My preference would be for core o.a.l.search. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, timeout.patch, timeout.patch, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566171#action_12566171 ] Sean Timm commented on LUCENE-997: -- Doron, your comment for setResolution(long) says The default timer resolution is 50 milliseconds, however, the default is actually 20 ms (public static final int DEFAULT_RESOLUTION = 20;). Other than that, everything looks great. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: timeout.patch Patch adds JUnit test cases as suggested by Doren. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565835#action_12565835 ] timmsc edited comment on LUCENE-997 at 2/5/08 9:51 AM: -- Patch adds JUnit test cases as suggested by Doron. was (Author: timmsc): Patch adds JUnit test cases as suggested by Doren. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565906#action_12565906 ] Sean Timm commented on LUCENE-997: -- Paul, I think that if we were to use System.currentTimeMillis(), we would eschew the TimerThread as Doron suggests in his Dec. 15 comment. I haven't seen any performance issues with System.currentTimeMillis(). As far as 200ms, I think that is too large of a default resolution (and with the current implementation it is not configurable). With a 200 ms resolution, a query with a 1 second time allowed could timeout in 800 ms, and one with a time allowed of 500 ms could timeout in 300 ms. I think it is much worse to timeout a query early than to timeout late. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: timeout.patch This is a minor update to timeout.patch which fixes the comment about updates to 32-bit-sized variables being atomic and instead talks about volatile longs, as pointed out by Andrzej. It also computes the time out moment up front to save a subtraction on each document collection as suggested by Paul. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563632#action_12563632 ] Sean Timm commented on LUCENE-997: -- I could go either way on the System.currentTimeMillis() versus a TimerThread issue. I agree nanoTime is the correct implementation when using 1.5. It doesn't seem like on Linux running ntp it matters much either way. NTP tries to perform smoothing and makes clock changes slowly over a longer period of time when it can rather than have an abrupt change, but YMMV if your system is having clock issues. On a really overloaded Windows box, the TimerThread implementation will not behave well as demonstrated above. I can't speak to any other platforms. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563155#action_12563155 ] Sean Timm commented on LUCENE-997: -- @Timo: didn't I use a volatile long already? Indeed. I guess that wasn't a very big change then. ;-) Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562869#action_12562869 ] Sean Timm commented on LUCENE-997: -- Andrzej-- JLS 17.7 Non-atomic Treatment of double and long Writes and reads of volatile long and double values are always atomic. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562952#action_12562952 ] Sean Timm commented on LUCENE-997: -- You are right that I forgot to change the comment when I changed it from an int to a long though. * updates to 32-bit-sized variables are atomic is a pretty pointless comment now. :-) Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: TimerThreadTest.java The TimerThreadTest illustrates the accuracy of the TimerThread under load. On my 2GHz Xeon 4 CPU dual core RH AS 4 Linux box, it get a 20% difference between the TimerThread implementation and System.currentTimeMillis() and is independent of load. java TimerThreadTest 8 [...] 10010 12020 [...] With my single core single CPU Windows XP laptop I see a 20% difference at load, but when adding additional threads, I see an increasing difference. java TimerThreadTest 0 [...] 1 11819 [...] java TimerThreadTest 2 [...] 10040 18890 [...] Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch, TimerThreadTest.java This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: timeout.patch Updated bad patch with good copy. Created a patch using Timo's HitCollectorTimeoutDecorator. This patch just has a few mostly minor changes. The biggest changes are that it uses a long instead of an int for the counter in TimerThread and the TimerThread interval is fixed at 10 ms. It also throws a TimeLimitedCollector.TimeExceeded exception on a timeout. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: (was: timeout.patch) Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: timeout.patch Created a patch using Timo's HitCollectorTimeoutDecorator. This patch just has a few mostly minor changes. The biggest changes are that it uses a long instead of an int for the counter in TimerThread and the TimerThread interval is fixed at 10 ms. It also throws a TimeLimitedCollector.TimeExceeded exception on a timeout. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: LuceneTimeoutTest.java Updated to work with latest patch. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: HitCollectorTimeoutDecorator.java, LuceneTimeoutTest.java, LuceneTimeoutTest.java, MyHitCollector.java, timeout.patch, timeout.patch, timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (SOLR-457) A multi threaded implementation for solrJ
[ https://issues.apache.org/jira/browse/SOLR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559340#action_12559340 ] timmsc edited comment on SOLR-457 at 1/21/08 7:26 AM: - Currently with Solrj, if you want to take advantage of the connection pooling, I think you need to create a single instance of CommonsHttpSolrServer in your application (and if you aren't, you are better off using SimpleHttpConnectionManager). So, it seems to make sense to make it easier to use in this fashion. This could be made more general purpose though if process just took a single request and returned a single response and you called it once for each server. This would abstract out the threading and connection pooling while not constraining the class to something designed primarily for SOLR-303. A couple of other comments: The threads should probably be pooled rather than creating and destroying on each request. While creating and destroying threads has gotten faster, pooling is usually beneficial. Unless I'm mistaken, it appears that your connectionManager is different from the _connectionManager in CommonsHttpSolrServer, so the methods that you didn't override will not work correctly, e.g., setConnectionTimeout(). Neither the CommonsHttpSolrServer currently in Solrj nor this patch appear to allow setting of the read timeout: setSoTimeout(int timeout) or the connection manager timeout: setConnectionManagerTimeout(long timeout). Other HttpClient options such as disabling Nagle's algorithm are probably not as important. This should probably be opened as a separate JIRA issue (edit: see SOLR-462). was (Author: timmsc): Currently with Solrj, if you want to take advantage of the connection pooling, I think you need to create a single instance of CommonsHttpSolrServer in your application (and if you aren't, you are better off using SimpleHttpConnectionManager). So, it seems to make sense to make it easier to use in this fashion. This could be made more general purpose though if process just took a single request and returned a single response and you called it once for each server. This would abstract out the threading and connection pooling while not constraining the class to something designed primarily for SOLR-303. A couple of other comments: The threads should probably be pooled rather than creating and destroying on each request. While creating and destroying threads has gotten faster, pooling is usually beneficial. Unless I'm mistaken, it appears that your connectionManager is different from the _connectionManager in CommonsHttpSolrServer, so the methods that you didn't override will not work correctly, e.g., setConnectionTimeout(). Neither the CommonsHttpSolrServer currently in Solrj nor this patch appear to allow setting of the read timeout: setSoTimeout(int timeout) or the connection manager timeout: setConnectionManagerTimeout(long timeout). Other HttpClient options such as disabling Nagle's algorithm are probably not as important. This should probably be opened as a separate JIRA issue. A multi threaded implementation for solrJ - Key: SOLR-457 URL: https://issues.apache.org/jira/browse/SOLR-457 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 1.3 Reporter: patrick o'leary Priority: Minor Fix For: 1.3 Attachments: multithreaded-solrj.patch Provide a multi threaded implementation of CommonsHttpSolrServer For usage with distributed searching in solr-303 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-462) Performance related enhancements to Solrj
[ https://issues.apache.org/jira/browse/SOLR-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561035#action_12561035 ] Sean Timm commented on SOLR-462: There are two reasons I chose to not have compression enabled by default: (1) it seems like most Solr deployments use Tomcat or Jetty stand-alone--to get compression, you need to either use a servlet filter to do the compression or put the servlet container behind Apache or another web server enabled to provide the compression, and (2) if both the Solr servers and the Solrj clients are on the same local network, with a 100 Mbps or even gigabit connection, is the CPU overhead of compression going to buy you enough on the IO side? Now if you have Solr in one data center and your Solrj in a different data center, compression is likely a benefit. The option is nice and it is a quick thing to try to see if it helps in your particular circumstance. Performance related enhancements to Solrj - Key: SOLR-462 URL: https://issues.apache.org/jira/browse/SOLR-462 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Sean Timm Assignee: Ryan McKinley Fix For: 1.3 Attachments: solrj-SOLR-462.patch Changes to CommonsHttpSolrServer.java to add soTimeout (read timeout), connection pool timeout, directive to not follow HTTP redirects, configurable retries on NoHttpResponseException, compression, and not creating a new HttpClient on each request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-462) Performance related enhancements to Solrj
[ https://issues.apache.org/jira/browse/SOLR-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561189#action_12561189 ] Sean Timm commented on SOLR-462: It's not a big deal to me either way. It just seems that if you can save the bytes, you might as well. In our case for one of our sites, we get ~25MM queries per day. We don't use compression. Sending the request header would result in an extra 725 MB of data (29 bytes * 25MM) over the course of a day (which would be ignored). Compared to the GBs of actual data, it's not much, but a penny saved is a penny earned. :-) Performance related enhancements to Solrj - Key: SOLR-462 URL: https://issues.apache.org/jira/browse/SOLR-462 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Sean Timm Assignee: Ryan McKinley Fix For: 1.3 Attachments: solrj-SOLR-462.patch Changes to CommonsHttpSolrServer.java to add soTimeout (read timeout), connection pool timeout, directive to not follow HTTP redirects, configurable retries on NoHttpResponseException, compression, and not creating a new HttpClient on each request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-462) Performance related enhancements to Solrj
[ https://issues.apache.org/jira/browse/SOLR-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-462: --- Attachment: solrj-SOLR-462.patch patch applies to client/java/solrj/src/org/apache/solr/client/solrj/impl/CommonsHttpSolrServer.java Performance related enhancements to Solrj - Key: SOLR-462 URL: https://issues.apache.org/jira/browse/SOLR-462 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Sean Timm Attachments: solrj-SOLR-462.patch Changes to CommonsHttpSolrServer.java to add soTimeout (read timeout), connection pool timeout, directive to not follow HTTP redirects, configurable retries on NoHttpResponseException, compression, and not creating a new HttpClient on each request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-462) Performance related enhancements to Solrj
Performance related enhancements to Solrj - Key: SOLR-462 URL: https://issues.apache.org/jira/browse/SOLR-462 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Sean Timm Changes to CommonsHttpSolrServer.java to add soTimeout (read timeout), connection pool timeout, directive to not follow HTTP redirects, configurable retries on NoHttpResponseException, compression, and not creating a new HttpClient on each request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-303: --- Comment: was deleted Distributed Search over HTTP Key: SOLR-303 URL: https://issues.apache.org/jira/browse/SOLR-303 Project: Solr Issue Type: New Feature Components: search Reporter: Sharad Agarwal Assignee: Yonik Seeley Attachments: distributed.patch, distributed.patch, distributed.patch, distributed_trunk.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, fedsearch.stu.patch Searching over multiple shards and aggregating results. Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553586 ] Sean Timm commented on LUCENE-997: -- Thanks for all of the feedback. I'll take another stab at this. I'm on vacation now and probably won't have time until I get back. It'll probably be early Jan. before I have a new patch ready. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: LuceneTimeoutTest.java, timeout.patch, timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SOLR-392) Way to control search time, hits, and memory usage
[ https://issues.apache.org/jira/browse/SOLR-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537480 ] Sean Timm commented on SOLR-392: This is related to LUCENE-997 Add search timeout support to Lucene. Way to control search time, hits, and memory usage -- Key: SOLR-392 URL: https://issues.apache.org/jira/browse/SOLR-392 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Lance Norskog Priority: Minor It would be good for end-user applications if Solr allowed searches to time out. It is possible now for the servlet container to throw a timeout exception. It would be very useful if the Solr search request timeout offered these features: 1) timeout: stop searching after N milliseconds and return results using only those hits already found 2) hit limit: stop searching after N milliseconds and return results using only those hits already found 3) ram limit: estimate the amount of ram used so far and stop searching at a given amount In all cases it would be very useful to estimate the remaining results to any degree of accuracy. Argument for estimation: For an extreme example, Google clearly does not finish any search that is more than the requested return value. Instead it returns very quickly on any search and overestimates all searches. If the first page says there are five pages, the second will often say that there are four pages instead. The third page will say 3 out of 3. Argument for 'timeout' control: we've all waited too long for searches Argument for 'hit limit' control: I really don't need to know that I'll have 14 thousand results. I'm not going to view them all. Argument for 'ram limit' control: Over-complex queries can cause Java OutOfMemory errors, and Tomcat does not recover gracefully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: timeout.patch Two issues are addressed in this latest patch: 1) Timeout support was not added to: public TopFieldDocs search(Weight weight, Filter filter, final int nDocs, Sort sort) 2) getCounter() in TimerThread was replaced by getMilliseconds() Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: LuceneTimeoutTest.java, timeout.patch, timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: timeout.patch http://www-128.ibm.com/developerworks/java/library/j-jtp05236.html TimerThread Now follows Brian Goetz's best practice for a noncancelable task that restores interrupted status before returning rather than ignoring the InterruptedException. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: LuceneTimeoutTest.java, timeout.patch, timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: (was: timeout.patch) Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: LuceneTimeoutTest.java, timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-997) Add search timeout support to Lucene
Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: timeout.patch Patch against trunk revision 575451. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated LUCENE-997: - Attachment: LuceneTimeoutTest.java Simple test case. Run by passing in the index directory as an argument. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: LuceneTimeoutTest.java, timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-997) Add search timeout support to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527264 ] Sean Timm commented on LUCENE-997: -- Here are some additional details on the changes. New files: TimeLimitedCollector.java Extends HitCollector and detects timeouts resulting in a TimeLimitedCollector.TimeExceeded exception being thrown. TimerThread.java TimerThread provides a pseudo-clock service to all searching threads, so that they can count elapsed time with less overhead than repeatedly calling System.currentTimeMillis. A single thread should be created to be used for all searches. Modified Files: Hits.java Added partial result flag. IndexSearcher.java Catches TimeLimitedCollector.TimeExceeded, sets partial results flag on TopDocs and estimates the total hit count (if we hadn't timed out partway through). Returns TopDocs with partial results. Searcher.java Added methods to set and get the timeout parameters. This implementation decision has the limitation of only permitting a single timeout value per Searcher instance (of which there is usually only one). However, this greatly minimizes the number of search methods that would need to be added. In practice, I have not needed the functionality to change the timeout settings on a per query basis. TopFieldDocCollector.java Uses TimeLimitedCollector functionality. TopDocCollector.java Uses TimeLimitedCollector functionality and exposes it to child class TopFieldDocCollector. TopDocs.java Added partial results flag. Note, TopFieldDocs extends this class and inherits the new functionality. Add search timeout support to Lucene Key: LUCENE-997 URL: https://issues.apache.org/jira/browse/LUCENE-997 Project: Lucene - Java Issue Type: New Feature Reporter: Sean Timm Priority: Minor Attachments: LuceneTimeoutTest.java, timeout.patch This patch is based on Nutch-308. This patch adds support for a maximum search time limit. After this time is exceeded, the search thread is stopped, partial results (if any) are returned and the total number of results is estimated. This patch tries to minimize the overhead related to time-keeping by using a version of safe unsynchronized timer. This was also discussed in an e-mail thread. http://www.nabble.com/search-timeout-tf3410206.html#a9501029 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
