[jira] [Commented] (SOLR-656) better error message when "data/index" is completely empty
[ https://issues.apache.org/jira/browse/SOLR-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541556#comment-13541556 ] Shawn Heisey commented on SOLR-656: --- What do you think about the "isFSBased()" idea in the patch on DirectoryFactory? I know that nothing included in Solr/Lucene would have use for it now, but in the future a Directory might be created that uses persistent but not-filesystem-based storage (Hadoop, MongoDB, Swift, etc.). That probably needs its own issue - just asking whether I should go ahead and make one, and whether a matching issue in Lucene might be a good idea. > better error message when "data/index" is completely empty > -- > > Key: SOLR-656 > URL: https://issues.apache.org/jira/browse/SOLR-656 > Project: Solr > Issue Type: Wish >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 4.2, 5.0 > > Attachments: SOLR-656.patch, SOLR-656-rmdir.patch, > SOLR-656-rmdir.patch > > > Solr's normal behavior is to create an "index" dire in the dataDir if one > does not already exist, but if "index" does exist it is used as is, warts and > all ... if the index is corrupt in some way, and Solr can't create an > IndexWriter or IndexReader that error is propagated up to the user. > I don't think this should change: Solr shouldn't attempt to do anything > special if there is a low level problem with the index, but something that > i've seen happen more then a few times is that people unwittingly "rm > index/*" when they should "run -r index" and as a result Solr+Lucene gives > them an error instead of just giving them an empty index > when checking if an existing index dir exists, it would probably be worth > while to add a little one line sanity test that it contains some files, and > log a warning. -- 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] [Commented] (SOLR-1535) Pre-analyzed field type
[ https://issues.apache.org/jira/browse/SOLR-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541555#comment-13541555 ] Alexandre Rafalovitch commented on SOLR-1535: - Not sure where to ask this, as the feature is so new. But how does this work at query time? This needs to be pared somehow with a query-time tokenizer/filters, right? I could not find a trivial (or complex) example showing this in action. > Pre-analyzed field type > --- > > Key: SOLR-1535 > URL: https://issues.apache.org/jira/browse/SOLR-1535 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.5 >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki > Fix For: 4.0-ALPHA > > Attachments: preanalyzed.patch, preanalyzed.patch, SOLR-1535.patch, > SOLR-1535.patch, SOLR-1535.patch > > > PreAnalyzedFieldType provides a functionality to index (and optionally store) > content that was already processed and split into tokens using some external > processing chain. This implementation defines a serialization format for > sending tokens with any currently supported Attributes (eg. type, posIncr, > payload, ...). This data is de-serialized into a regular TokenStream that is > returned in Field.tokenStreamValue() and thus added to the index as index > terms, and optionally a stored part that is returned in Field.stringValue() > and is then added as a stored value of the field. > This field type is useful for integrating Solr with existing text-processing > pipelines, such as third-party NLP systems. -- 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] [Commented] (SOLR-656) better error message when "data/index" is completely empty
[ https://issues.apache.org/jira/browse/SOLR-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541553#comment-13541553 ] Shawn Heisey commented on SOLR-656: --- I did not actually try it before making the patch. I know that I have run into problems with Solr starting when index exists but is empty, but now I don't remember whether that was on 1.4.x or 3.x. > better error message when "data/index" is completely empty > -- > > Key: SOLR-656 > URL: https://issues.apache.org/jira/browse/SOLR-656 > Project: Solr > Issue Type: Wish >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 4.2, 5.0 > > Attachments: SOLR-656.patch, SOLR-656-rmdir.patch, > SOLR-656-rmdir.patch > > > Solr's normal behavior is to create an "index" dire in the dataDir if one > does not already exist, but if "index" does exist it is used as is, warts and > all ... if the index is corrupt in some way, and Solr can't create an > IndexWriter or IndexReader that error is propagated up to the user. > I don't think this should change: Solr shouldn't attempt to do anything > special if there is a low level problem with the index, but something that > i've seen happen more then a few times is that people unwittingly "rm > index/*" when they should "run -r index" and as a result Solr+Lucene gives > them an error instead of just giving them an empty index > when checking if an existing index dir exists, it would probably be worth > while to add a little one line sanity test that it contains some files, and > log a warning. -- 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] [Updated] (SOLR-4251) SynonymFilter fails when provided with optional tokenizerFactory
[ https://issues.apache.org/jira/browse/SOLR-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Bleakley updated SOLR-4251: - Attachment: SOLR-4251.patch > SynonymFilter fails when provided with optional tokenizerFactory > > > Key: SOLR-4251 > URL: https://issues.apache.org/jira/browse/SOLR-4251 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 4.0, 4.0.1, 4.1, 4.2 >Reporter: Chris Bleakley >Priority: Minor > Attachments: SOLR-4251.patch > > > Using the solr 4.0 example, if I add an optional tokenizerFactory ( as per > http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory > ) to the synonymFilter for the "text_general" field type: > synonyms="synonyms.txt" > tokenizerFactory="solr.StandardTokenizerFactory" > ignoreCase="true" > expand="true"/> > I receive the error at startup: > SEVERE: null:java.lang.IllegalArgumentException: Configuration Error: Factory > 'org.apache.lucene.analysis.standard.StandardTokenizerFactory' needs a > 'luceneMatchVersion' parameter > It also fails if I try adding the param luceneMatchVersion="LUCENE_40" : > synonyms="synonyms.txt" > tokenizerFactory="solr.StandardTokenizerFactory" > luceneMatchVersion="LUCENE_40" > ignoreCase="true" > expand="true"/> > -- > It looks like the delegator in the SynonymFilterFactory is not propagating > the LUCENE_MATCH_VERSION to the tokenizer. For tokenizers that don't require > a match version (whitespace) everything works correctly. This issue seems to > be a problem in the 4x branch... trunk removes the code that delegates > between the 2 types of synonym filters. -- 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-4251) SynonymFilter fails when provided with optional tokenizerFactory
Chris Bleakley created SOLR-4251: Summary: SynonymFilter fails when provided with optional tokenizerFactory Key: SOLR-4251 URL: https://issues.apache.org/jira/browse/SOLR-4251 Project: Solr Issue Type: Bug Components: Schema and Analysis Affects Versions: 4.0, 4.0.1, 4.1, 4.2 Reporter: Chris Bleakley Priority: Minor Using the solr 4.0 example, if I add an optional tokenizerFactory ( as per http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory ) to the synonymFilter for the "text_general" field type: I receive the error at startup: SEVERE: null:java.lang.IllegalArgumentException: Configuration Error: Factory 'org.apache.lucene.analysis.standard.StandardTokenizerFactory' needs a 'luceneMatchVersion' parameter It also fails if I try adding the param luceneMatchVersion="LUCENE_40" : -- It looks like the delegator in the SynonymFilterFactory is not propagating the LUCENE_MATCH_VERSION to the tokenizer. For tokenizers that don't require a match version (whitespace) everything works correctly. This issue seems to be a problem in the 4x branch... trunk removes the code that delegates between the 2 types of synonym filters. -- 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] [Assigned] (SOLR-656) better error message when "data/index" is completely empty
[ https://issues.apache.org/jira/browse/SOLR-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reassigned SOLR-656: - Assignee: Hoss Man > better error message when "data/index" is completely empty > -- > > Key: SOLR-656 > URL: https://issues.apache.org/jira/browse/SOLR-656 > Project: Solr > Issue Type: Wish >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 4.2, 5.0 > > Attachments: SOLR-656.patch, SOLR-656-rmdir.patch, > SOLR-656-rmdir.patch > > > Solr's normal behavior is to create an "index" dire in the dataDir if one > does not already exist, but if "index" does exist it is used as is, warts and > all ... if the index is corrupt in some way, and Solr can't create an > IndexWriter or IndexReader that error is propagated up to the user. > I don't think this should change: Solr shouldn't attempt to do anything > special if there is a low level problem with the index, but something that > i've seen happen more then a few times is that people unwittingly "rm > index/*" when they should "run -r index" and as a result Solr+Lucene gives > them an error instead of just giving them an empty index > when checking if an existing index dir exists, it would probably be worth > while to add a little one line sanity test that it contains some files, and > log a warning. -- 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] [Commented] (SOLR-656) better error message when "data/index" is completely empty
[ https://issues.apache.org/jira/browse/SOLR-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541549#comment-13541549 ] Hoss Man commented on SOLR-656: --- Shawn: thanks for looking into this, but i'm not sure any changes are really needed anymore. At the time i created this issue, you would get a really ugly and confusing error message if you stoped solr, ran "rm dataDir/index/*" and left the index directory empty, and then restarted solr. it appears that at some point in the past 5 years, the underlying behavior of lucene has changed, such that an "empty" Directory is now acceptable, and that same behavior works fine -- solr/lucene happily adds new segments file to the empty directory on startup and you can start indexing documents. So unless you're seeing some error i'm not (maybe this only works cleanly with the default DirectoryFactory?) i think we can resolve this as not a problem > better error message when "data/index" is completely empty > -- > > Key: SOLR-656 > URL: https://issues.apache.org/jira/browse/SOLR-656 > Project: Solr > Issue Type: Wish >Reporter: Hoss Man > Fix For: 4.2, 5.0 > > Attachments: SOLR-656.patch, SOLR-656-rmdir.patch, > SOLR-656-rmdir.patch > > > Solr's normal behavior is to create an "index" dire in the dataDir if one > does not already exist, but if "index" does exist it is used as is, warts and > all ... if the index is corrupt in some way, and Solr can't create an > IndexWriter or IndexReader that error is propagated up to the user. > I don't think this should change: Solr shouldn't attempt to do anything > special if there is a low level problem with the index, but something that > i've seen happen more then a few times is that people unwittingly "rm > index/*" when they should "run -r index" and as a result Solr+Lucene gives > them an error instead of just giving them an empty index > when checking if an existing index dir exists, it would probably be worth > while to add a little one line sanity test that it contains some files, and > log a warning. -- 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] [Updated] (SOLR-3963) SOLR: map() does not allow passing sub-functions in 4,5 parameters
[ https://issues.apache.org/jira/browse/SOLR-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-3963: --- Fix Version/s: (was: 4.0) > SOLR: map() does not allow passing sub-functions in 4,5 parameters > -- > > Key: SOLR-3963 > URL: https://issues.apache.org/jira/browse/SOLR-3963 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Bill Bell >Assignee: Hoss Man >Priority: Minor > Attachments: SOLR-3963.2.patch > > > I want to do: > boost=map(achievement_count,1,1000,recip(achievement_count,-.5,10,25),1) > I want to return recip(achievement_count,-.5,10,25) if achievement_count is > between 1 and 1,000. FOr any other values I want to return 1. > I cannot get it to work. I get the error below. Interesting this does work: > boost=recip(map(achievement_count,0,0,-200),-.5,10,25) > It almost appears that map() cannot take a function. > Specified argument was out of the range of valid values. > Parameter name: value > Description: An unhandled exception occurred during the execution of the > current web request. Please review the stack trace for more information about > the error and where it originated in the code. > Exception Details: System.ArgumentOutOfRangeException: Specified argument was > out of the range of valid values. > Parameter name: value > Source Error: > An unhandled exception was generated during the execution of the current web > request. Information regarding the origin and location of the exception can > be identified using the exception stack trace below. > Stack Trace: > [ArgumentOutOfRangeException: Specified argument was out of the range of > valid values. > Parameter name: value] >System.Web.HttpResponse.set_StatusDescription(String value) +5200522 >FacilityService.Controllers.FacilityController.ActionCompleted(String > actionName, IFacilityResults results) +265 > > FacilityService.Controllers.FacilityController.SearchByPointCompleted(IFacilityResults > results) +25 >lambda_method(Closure , ControllerBase , Object[] ) +114 >System.Web.Mvc.Async.<>c__DisplayClass7.b__5(IAsyncResult > asyncResult) +283 > > System.Web.Mvc.Async.<>c__DisplayClass41.b__40(IAsyncResult > asyncResult) +22 > > System.Web.Mvc.Async.<>c__DisplayClass3b.b__35() > +120 > > System.Web.Mvc.Async.<>c__DisplayClass51.b__4b() > +452 > > System.Web.Mvc.Async.<>c__DisplayClass39.b__38(IAsyncResult > asyncResult) +15 >System.Web.Mvc.Async.<>c__DisplayClass2c.b__22() +33 > > System.Web.Mvc.Async.<>c__DisplayClass27.b__24(IAsyncResult > asyncResult) +240 >System.Web.Mvc.<>c__DisplayClass19.b__14(IAsyncResult > asyncResult) +28 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.Mvc.AsyncController.EndExecuteCore(IAsyncResult asyncResult) +63 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.Mvc.<>c__DisplayClassb.b__4(IAsyncResult > asyncResult) +42 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.CallHandlerExecutionStep.OnAsyncHandlerCompletion(IAsyncResult > ar) +282 -- 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] [Reopened] (SOLR-3963) SOLR: map() does not allow passing sub-functions in 4,5 parameters
[ https://issues.apache.org/jira/browse/SOLR-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reopened SOLR-3963: hmmm... good catch david, not sure when/how that happened. as far as i know this situation hasn't changed since my last comment: happy to commit if we clean up the patch a bit. > SOLR: map() does not allow passing sub-functions in 4,5 parameters > -- > > Key: SOLR-3963 > URL: https://issues.apache.org/jira/browse/SOLR-3963 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Bill Bell >Assignee: Hoss Man >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3963.2.patch > > > I want to do: > boost=map(achievement_count,1,1000,recip(achievement_count,-.5,10,25),1) > I want to return recip(achievement_count,-.5,10,25) if achievement_count is > between 1 and 1,000. FOr any other values I want to return 1. > I cannot get it to work. I get the error below. Interesting this does work: > boost=recip(map(achievement_count,0,0,-200),-.5,10,25) > It almost appears that map() cannot take a function. > Specified argument was out of the range of valid values. > Parameter name: value > Description: An unhandled exception occurred during the execution of the > current web request. Please review the stack trace for more information about > the error and where it originated in the code. > Exception Details: System.ArgumentOutOfRangeException: Specified argument was > out of the range of valid values. > Parameter name: value > Source Error: > An unhandled exception was generated during the execution of the current web > request. Information regarding the origin and location of the exception can > be identified using the exception stack trace below. > Stack Trace: > [ArgumentOutOfRangeException: Specified argument was out of the range of > valid values. > Parameter name: value] >System.Web.HttpResponse.set_StatusDescription(String value) +5200522 >FacilityService.Controllers.FacilityController.ActionCompleted(String > actionName, IFacilityResults results) +265 > > FacilityService.Controllers.FacilityController.SearchByPointCompleted(IFacilityResults > results) +25 >lambda_method(Closure , ControllerBase , Object[] ) +114 >System.Web.Mvc.Async.<>c__DisplayClass7.b__5(IAsyncResult > asyncResult) +283 > > System.Web.Mvc.Async.<>c__DisplayClass41.b__40(IAsyncResult > asyncResult) +22 > > System.Web.Mvc.Async.<>c__DisplayClass3b.b__35() > +120 > > System.Web.Mvc.Async.<>c__DisplayClass51.b__4b() > +452 > > System.Web.Mvc.Async.<>c__DisplayClass39.b__38(IAsyncResult > asyncResult) +15 >System.Web.Mvc.Async.<>c__DisplayClass2c.b__22() +33 > > System.Web.Mvc.Async.<>c__DisplayClass27.b__24(IAsyncResult > asyncResult) +240 >System.Web.Mvc.<>c__DisplayClass19.b__14(IAsyncResult > asyncResult) +28 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.Mvc.AsyncController.EndExecuteCore(IAsyncResult asyncResult) +63 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.Mvc.<>c__DisplayClassb.b__4(IAsyncResult > asyncResult) +42 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.CallHandlerExecutionStep.OnAsyncHandlerCompletion(IAsyncResult > ar) +282 -- 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] [Commented] (SOLR-4238) filename pattern of jetty request log file in sample example\etc\jetty.xml is wrong
[ https://issues.apache.org/jira/browse/SOLR-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541537#comment-13541537 ] Commit Tag Bot commented on SOLR-4238: -- [branch_4x commit] Chris M. Hostetter http://svn.apache.org/viewvc?view=revision&revision=1427259 SOLR-4238: only fix one place, the other place is suppose to be broken for things to work properly (merge r1427258) > filename pattern of jetty request log file in sample example\etc\jetty.xml is > wrong > --- > > Key: SOLR-4238 > URL: https://issues.apache.org/jira/browse/SOLR-4238 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: jm >Assignee: Hoss Man >Priority: Minor > Labels: logging > Fix For: 4.1, 5.0 > > Attachments: solr-4238.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This is being used now: > _mm_dd > but mm means minutes (I guess) and filenames created are not meaningfull. > Changing to > _MM_dd > creates proper filenames. > Note that the logger is commented out by default, but I always enable it. -- 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] [Commented] (SOLR-4238) filename pattern of jetty request log file in sample example\etc\jetty.xml is wrong
[ https://issues.apache.org/jira/browse/SOLR-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541535#comment-13541535 ] Commit Tag Bot commented on SOLR-4238: -- [trunk commit] Chris M. Hostetter http://svn.apache.org/viewvc?view=revision&revision=1427258 SOLR-4238: only fix one place, the other place is suppose to be broken for things to work properly > filename pattern of jetty request log file in sample example\etc\jetty.xml is > wrong > --- > > Key: SOLR-4238 > URL: https://issues.apache.org/jira/browse/SOLR-4238 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: jm >Assignee: Hoss Man >Priority: Minor > Labels: logging > Fix For: 4.1, 5.0 > > Attachments: solr-4238.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This is being used now: > _mm_dd > but mm means minutes (I guess) and filenames created are not meaningfull. > Changing to > _MM_dd > creates proper filenames. > Note that the logger is commented out by default, but I always enable it. -- 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] [Commented] (SOLR-4238) filename pattern of jetty request log file in sample example\etc\jetty.xml is wrong
[ https://issues.apache.org/jira/browse/SOLR-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541534#comment-13541534 ] Hoss Man commented on SOLR-4238: blarg. thanks for catching that ... sigh. It would be nice if there wasn't 5,000 diff jetty docs out there with conflicting info. Committed revision 1427258. Committed revision 1427259. > filename pattern of jetty request log file in sample example\etc\jetty.xml is > wrong > --- > > Key: SOLR-4238 > URL: https://issues.apache.org/jira/browse/SOLR-4238 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: jm >Assignee: Hoss Man >Priority: Minor > Labels: logging > Fix For: 4.1, 5.0 > > Attachments: solr-4238.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This is being used now: > _mm_dd > but mm means minutes (I guess) and filenames created are not meaningfull. > Changing to > _MM_dd > creates proper filenames. > Note that the logger is commented out by default, but I always enable it. -- 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] [Resolved] (SOLR-3388) HTTP caching should be disabled by default for ContentStreamHandlers
[
https://issues.apache.org/jira/browse/SOLR-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-3388.
-
Resolution: Fixed
Fix Version/s: (was: 5.0)
(was: 4.1)
4.0
This should have been resolved long ago. SOLR-3388 is in the CHANGES.txt for
4.0
thanks for pinging me on this Mark!
> HTTP caching should be disabled by default for ContentStreamHandlers
>
>
> Key: SOLR-3388
> URL: https://issues.apache.org/jira/browse/SOLR-3388
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-3388-http-caching.patch
>
>
> RequestHandlers can disable HTTP Caching with the init-parameter:
> {code:xml}false{code}
> For UpdateHandlers, disabling caching by default makes more sense.
--
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] [Commented] (SOLR-4238) filename pattern of jetty request log file in sample example\etc\jetty.xml is wrong
[ https://issues.apache.org/jira/browse/SOLR-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541518#comment-13541518 ] jm commented on SOLR-4238: -- Thanks Hos for taking care of this. I have to clarify two things: 1. I changed the wrong property when creating the patch :(, the only thing I should have changed was as I said in the description: _MM_dd 2. the reason filename was not changed, is that according to http://stackoverflow.com/questions/11527194/jetty-access-log-is-no-longer-logging is not clear filename must match filenameDateFormat, and that retainDays won't work if you change that format (see Bob Kuhar's comment). And I have verified the filename created is correct when changing just filenameDateFormat so not sure you should change filename, up to you. jm > filename pattern of jetty request log file in sample example\etc\jetty.xml is > wrong > --- > > Key: SOLR-4238 > URL: https://issues.apache.org/jira/browse/SOLR-4238 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: jm >Assignee: Hoss Man >Priority: Minor > Labels: logging > Fix For: 4.1, 5.0 > > Attachments: solr-4238.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This is being used now: > _mm_dd > but mm means minutes (I guess) and filenames created are not meaningfull. > Changing to > _MM_dd > creates proper filenames. > Note that the logger is commented out by default, but I always enable it. -- 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
Re: Improvement: Add commented-out /MLT handler to example solrconfig.xml
Done. https://issues.apache.org/jira/browse/SOLR-4250 Register MoreLikeThis request handler in example solrconfig.xml -- Jack Krupansky -Original Message- From: Mark Miller Sent: Monday, December 31, 2012 1:21 PM To: dev@lucene.apache.org Subject: Re: Improvement: Add commented-out /MLT handler to example solrconfig.xml Could you make a JIRA issue? On Mon, Dec 31, 2012 at 11:27 AM, Jack Krupansky wrote: Solrconfig.xml has lots of great suggestions for various options that are commented out, which is fine. I did notice one useful feature that doesn’t even have a commented-out suggestion: the MoreLikeThis request handler. I suggest we add it. Does anybody know of any good reason why it isn’t there already? Or why it shouldn’t be added? And is there any significant downside to adding it as an active handler in the example solrconfig? I would simply note that since the mlt search component is already configured in Solr by default, most of the MLT code is already being loaded in Solr, so there should be no significant penalty. -- Jack Krupansky -- - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4250) Register MoreLikeThis request handler in example solrconfig.xml
Jack Krupansky created SOLR-4250:
Summary: Register MoreLikeThis request handler in example
solrconfig.xml
Key: SOLR-4250
URL: https://issues.apache.org/jira/browse/SOLR-4250
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Affects Versions: 4.0
Reporter: Jack Krupansky
Priority: Minor
Fix For: 4.2
The MoreLikeThis request handler is a very useful feature of Solr, but needs to
be registered in solrconfig.xml.
I suggest adding:
{code}
explicit
{code}
--
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
Re: get a Word in FuzzyQuery
Sorry, but you need to ask this on the Lucene user list.
-- Jack Krupansky
-Original Message-
From: algebra
Sent: Friday, December 28, 2012 6:49 PM
To: dev@lucene.apache.org
Subject: get a Word in FuzzyQuery
Hello guys. I'm working with FuzzyQuery and I a have a doubt: I would like
the lucene, return to me the correct word instead of me returning the
document, for example:
query = Brazil
document = "Brazil is a big country"
with this code:
[code]
Analyzer analyzer = new StandardAnalyzer(Version.LUCENE_CURRENT);
Directory directory = new RAMDirectory();
IndexWriter iwriter = new IndexWriter(directory, analyzer, true, new
IndexWriter.MaxFieldLength(25000));
Document doc;
for (int i = 0; i < list.size(); i++) {
doc = new Document();
doc.add(new Field("fieldname", list.get(i), Field.Store.YES,
Field.Index.ANALYZED));
iwriter.addDocument(doc);
}
iwriter.close();
IndexSearcher isearcher = new IndexSearcher(directory);
Term term = new Term("fieldname", s);
FuzzyQuery query = new FuzzyQuery(term, 0.75f, 0);
TopScoreDocCollector collector = TopScoreDocCollector.create(10, true);
isearcher.search(query, collector);
ScoreDoc[] hits = collector.topDocs().scoreDocs;
for (int i = 0; i < hits.length; i++) {
Document hitDoc = isearcher.doc(hits[i].doc);
listr.add(hitDoc.get("fieldname"));
}
isearcher.close();
directory.close();
for (int i = 0 ; i < listr.size() ; i++ ) {
resp.add(listr.get(i));//melhorar método para fazer busca dentro de
busca
}
return resp;
[/code]
The lucene, return to me the entire document ie "Brazil is a big country",
but I just wanted the word "Brazil". Somebody can help me?
--
View this message in context:
http://lucene.472066.n3.nabble.com/get-a-Word-in-FuzzyQuery-tp4029521.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541508#comment-13541508 ] Jack Krupansky commented on SOLR-788: - Thanks, Mark! > MoreLikeThis should support distributed search > -- > > Key: SOLR-788 > URL: https://issues.apache.org/jira/browse/SOLR-788 > Project: Solr > Issue Type: Improvement > Components: MoreLikeThis >Reporter: Grant Ingersoll >Assignee: Mark Miller >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: AlternateDistributedMLT.patch, MLT.patch, MLT.patch, > MoreLikeThisComponentTest.patch, SOLR-788.patch, SOLR-788.patch, > SolrMoreLikeThisPatch.txt > > > The MoreLikeThis component should support distributed processing. > See SOLR-303. -- 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] [Commented] (SOLR-4238) filename pattern of jetty request log file in sample example\etc\jetty.xml is wrong
[ https://issues.apache.org/jira/browse/SOLR-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541501#comment-13541501 ] Commit Tag Bot commented on SOLR-4238: -- [branch_4x commit] Chris M. Hostetter http://svn.apache.org/viewvc?view=revision&revision=1427241 SOLR-4238: Fix jetty example requestLog config (merge r1427240) > filename pattern of jetty request log file in sample example\etc\jetty.xml is > wrong > --- > > Key: SOLR-4238 > URL: https://issues.apache.org/jira/browse/SOLR-4238 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: jm >Assignee: Hoss Man >Priority: Minor > Labels: logging > Fix For: 4.1, 5.0 > > Attachments: solr-4238.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This is being used now: > _mm_dd > but mm means minutes (I guess) and filenames created are not meaningfull. > Changing to > _MM_dd > creates proper filenames. > Note that the logger is commented out by default, but I always enable it. -- 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] [Resolved] (SOLR-4238) filename pattern of jetty request log file in sample example\etc\jetty.xml is wrong
[ https://issues.apache.org/jira/browse/SOLR-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-4238. Resolution: Fixed Fix Version/s: 5.0 4.1 Assignee: Hoss Man thanks jm (oddly, your patch changed the "filename" property, but not the "filenameDateFormat" as mentioned in your issue description -- from what i can tell those are suppose to be in sync, so i committed both) > filename pattern of jetty request log file in sample example\etc\jetty.xml is > wrong > --- > > Key: SOLR-4238 > URL: https://issues.apache.org/jira/browse/SOLR-4238 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: jm >Assignee: Hoss Man >Priority: Minor > Labels: logging > Fix For: 4.1, 5.0 > > Attachments: solr-4238.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This is being used now: > _mm_dd > but mm means minutes (I guess) and filenames created are not meaningfull. > Changing to > _MM_dd > creates proper filenames. > Note that the logger is commented out by default, but I always enable it. -- 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] [Commented] (SOLR-4238) filename pattern of jetty request log file in sample example\etc\jetty.xml is wrong
[ https://issues.apache.org/jira/browse/SOLR-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541497#comment-13541497 ] Commit Tag Bot commented on SOLR-4238: -- [trunk commit] Chris M. Hostetter http://svn.apache.org/viewvc?view=revision&revision=1427240 SOLR-4238: Fix jetty example requestLog config > filename pattern of jetty request log file in sample example\etc\jetty.xml is > wrong > --- > > Key: SOLR-4238 > URL: https://issues.apache.org/jira/browse/SOLR-4238 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: jm >Priority: Minor > Labels: logging > Attachments: solr-4238.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This is being used now: > _mm_dd > but mm means minutes (I guess) and filenames created are not meaningfull. > Changing to > _MM_dd > creates proper filenames. > Note that the logger is commented out by default, but I always enable it. -- 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] [Closed] (SOLR-1829) Cleaned up analysis.jsp - removed all token API scriptlets
[ https://issues.apache.org/jira/browse/SOLR-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man closed SOLR-1829. -- Resolution: Not A Problem Fix Version/s: (was: 4.2) (was: 5.0) 4.0 marking not a problem as of 4.0 since hte JSPs were removed at that point > Cleaned up analysis.jsp - removed all token API scriptlets > -- > > Key: SOLR-1829 > URL: https://issues.apache.org/jira/browse/SOLR-1829 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 1.4 >Reporter: Uri Boness > Labels: admin > Fix For: 4.0 > > Attachments: SOLR-1829.patch > > > The analysis.jsp was polluted with the old token stream api in scriptlets all > over the place. Since the introduction of the FieldAnalysisRequestHandler, > there's no need to keep this mess. Instead, the page can just call the > analysis request handler and with parameter generated by the form and display > the xml response the same way as it is displayed at the moment. Moreover, it > will save some work when updating the code base to the new token stream API. -- 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] [Commented] (SOLR-4248) "ant eclipse" should declare .svn directories as derived
[ https://issues.apache.org/jira/browse/SOLR-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541479#comment-13541479 ] Commit Tag Bot commented on SOLR-4248: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1427234 SOLR-4248: "ant eclipse" should declare .svn directories as derived. > "ant eclipse" should declare .svn directories as derived > > > Key: SOLR-4248 > URL: https://issues.apache.org/jira/browse/SOLR-4248 > Project: Solr > Issue Type: Improvement > Components: Build >Affects Versions: 4.0 >Reporter: Shawn Heisey >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4248.patch > > > Eclipse has an awesome "file search" feature, but with the default eclipse > config, such searches also search the numerous and large .svn directories. > If there's any way to mark .svn directories as "derived" then eclipse will > not search them, which will greatly speed up searches. > I will look into whether I can figure out a patch for doing this, but someone > who is already intimately familiar with the workings of "ant eclipse" may be > able to do it faster. -- 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-4249) change UniqFieldsUpdateProcessorFactory to subclass FieldValueSubsetUpdateProcessorFactory
Hoss Man created SOLR-4249: -- Summary: change UniqFieldsUpdateProcessorFactory to subclass FieldValueSubsetUpdateProcessorFactory Key: SOLR-4249 URL: https://issues.apache.org/jira/browse/SOLR-4249 Project: Solr Issue Type: Improvement Reporter: Hoss Man Assignee: Hoss Man Priority: Minor UniqFieldsUpdateProcessorFactory has been arround for a while, but if we change it to subclass FieldValueSubsetUpdateProcessorFactory, a lot of redundent code could be eliminated from that class, and the factory could be made more configurable by supporting all of the field matching logic in FieldMutatingUpdateProcessorFactory, not just a list of field names. (the only new code that would be needed is handling the legacy config case currently supported by UniqFieldsUpdateProcessorFactory) -- 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] [Resolved] (SOLR-4248) "ant eclipse" should declare .svn directories as derived
[ https://issues.apache.org/jira/browse/SOLR-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-4248. --- Resolution: Fixed Thanks Shawn! > "ant eclipse" should declare .svn directories as derived > > > Key: SOLR-4248 > URL: https://issues.apache.org/jira/browse/SOLR-4248 > Project: Solr > Issue Type: Improvement > Components: Build >Affects Versions: 4.0 >Reporter: Shawn Heisey >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4248.patch > > > Eclipse has an awesome "file search" feature, but with the default eclipse > config, such searches also search the numerous and large .svn directories. > If there's any way to mark .svn directories as "derived" then eclipse will > not search them, which will greatly speed up searches. > I will look into whether I can figure out a patch for doing this, but someone > who is already intimately familiar with the workings of "ant eclipse" may be > able to do it faster. -- 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] [Commented] (SOLR-4248) "ant eclipse" should declare .svn directories as derived
[ https://issues.apache.org/jira/browse/SOLR-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541475#comment-13541475 ] Commit Tag Bot commented on SOLR-4248: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1427232 SOLR-4248: "ant eclipse" should declare .svn directories as derived. > "ant eclipse" should declare .svn directories as derived > > > Key: SOLR-4248 > URL: https://issues.apache.org/jira/browse/SOLR-4248 > Project: Solr > Issue Type: Improvement > Components: Build >Affects Versions: 4.0 >Reporter: Shawn Heisey >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4248.patch > > > Eclipse has an awesome "file search" feature, but with the default eclipse > config, such searches also search the numerous and large .svn directories. > If there's any way to mark .svn directories as "derived" then eclipse will > not search them, which will greatly speed up searches. > I will look into whether I can figure out a patch for doing this, but someone > who is already intimately familiar with the workings of "ant eclipse" may be > able to do it faster. -- 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] [Assigned] (SOLR-4248) "ant eclipse" should declare .svn directories as derived
[ https://issues.apache.org/jira/browse/SOLR-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-4248: - Assignee: Mark Miller > "ant eclipse" should declare .svn directories as derived > > > Key: SOLR-4248 > URL: https://issues.apache.org/jira/browse/SOLR-4248 > Project: Solr > Issue Type: Improvement > Components: Build >Affects Versions: 4.0 >Reporter: Shawn Heisey >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > Attachments: SOLR-4248.patch > > > Eclipse has an awesome "file search" feature, but with the default eclipse > config, such searches also search the numerous and large .svn directories. > If there's any way to mark .svn directories as "derived" then eclipse will > not search them, which will greatly speed up searches. > I will look into whether I can figure out a patch for doing this, but someone > who is already intimately familiar with the workings of "ant eclipse" may be > able to do it faster. -- 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] [Commented] (SOLR-4061) CREATE action in Collections API should allow to upload a new configuration
[ https://issues.apache.org/jira/browse/SOLR-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541473#comment-13541473 ] Mark Miller commented on SOLR-4061: --- It seems the limitation on this is that the conf set must be on the remote solr machine you are talking to and not a local dir? What if you are using the CloudSolrServer? Could be a future issue, but we should document this stuff well I think. > CREATE action in Collections API should allow to upload a new configuration > --- > > Key: SOLR-4061 > URL: https://issues.apache.org/jira/browse/SOLR-4061 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Tomás Fernández Löbbe >Assignee: Mark Miller >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4061.patch > > > When creating new collections with the Collection API, the only option is to > point to an existing configuration in ZK. It would be nice to be able to > upload a new configuration in the same command. > For more details see > http://lucene.472066.n3.nabble.com/Error-with-SolrCloud-td4019351.html -- 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] [Updated] (SOLR-4061) CREATE action in Collections API should allow to upload a new configuration
[ https://issues.apache.org/jira/browse/SOLR-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4061: -- Fix Version/s: (was: 4.2) 4.1 > CREATE action in Collections API should allow to upload a new configuration > --- > > Key: SOLR-4061 > URL: https://issues.apache.org/jira/browse/SOLR-4061 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Tomás Fernández Löbbe >Assignee: Mark Miller >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4061.patch > > > When creating new collections with the Collection API, the only option is to > point to an existing configuration in ZK. It would be nice to be able to > upload a new configuration in the same command. > For more details see > http://lucene.472066.n3.nabble.com/Error-with-SolrCloud-td4019351.html -- 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] [Assigned] (SOLR-4061) CREATE action in Collections API should allow to upload a new configuration
[ https://issues.apache.org/jira/browse/SOLR-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-4061: - Assignee: Mark Miller > CREATE action in Collections API should allow to upload a new configuration > --- > > Key: SOLR-4061 > URL: https://issues.apache.org/jira/browse/SOLR-4061 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Tomás Fernández Löbbe >Assignee: Mark Miller >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: SOLR-4061.patch > > > When creating new collections with the Collection API, the only option is to > point to an existing configuration in ZK. It would be nice to be able to > upload a new configuration in the same command. > For more details see > http://lucene.472066.n3.nabble.com/Error-with-SolrCloud-td4019351.html -- 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] [Updated] (SOLR-4248) "ant eclipse" should declare .svn directories as derived
[ https://issues.apache.org/jira/browse/SOLR-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-4248: --- Attachment: SOLR-4248.patch Patch implementing this eclipse filter. The id values seemed to be incremented by 2, so I just followed that convention. > "ant eclipse" should declare .svn directories as derived > > > Key: SOLR-4248 > URL: https://issues.apache.org/jira/browse/SOLR-4248 > Project: Solr > Issue Type: Improvement > Components: Build >Affects Versions: 4.0 >Reporter: Shawn Heisey > Fix For: 4.1, 5.0 > > Attachments: SOLR-4248.patch > > > Eclipse has an awesome "file search" feature, but with the default eclipse > config, such searches also search the numerous and large .svn directories. > If there's any way to mark .svn directories as "derived" then eclipse will > not search them, which will greatly speed up searches. > I will look into whether I can figure out a patch for doing this, but someone > who is already intimately familiar with the workings of "ant eclipse" may be > able to do it faster. -- 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] [Updated] (SOLR-4196) Untangle XML-specific nature of Config and Container classes
[ https://issues.apache.org/jira/browse/SOLR-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4196: - Attachment: SOLR-4196.patch Latest version. This has enough of the methods for the properties case to allow at least a very simple test with using a properties file rather than a solr.xml file to work. Nowhere near complete testing of using the properties file, a start though. I did violence to CoreDescriptor, having individual setters and getters when we move to properties-based files seems unnecessary, so I combined the individual fields into a Properties member var. I could be talked out of that, but it seems like it's going in the right direction. I think at this point we can see what this whole clumsy intermediate form for back-compat will look like, gives me more sympathy for folks maintaining the back-compat layers in Lucene ... I was wondering if there's a way to wire in randomly using the properties case or the xml-based case to leverage all of the tests built up over the years and all the assumptions they make... haven't looked at how to do that at all though > Untangle XML-specific nature of Config and Container classes > > > Key: SOLR-4196 > URL: https://issues.apache.org/jira/browse/SOLR-4196 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, > SOLR-4196.patch > > > sub-task for SOLR-4083. If we're going to try to obsolete solr.xml, we need > to pull all of the specific XML processing out of Config and Container. > Currently, we refer to xpaths all over the place. This JIRA is about > providing a thunking layer to isolate the XML-esque nature of solr.xml and > allow a simple properties file to be used instead which will lead, > eventually, to solr.xml going away. -- 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] [Commented] (SOLR-4061) CREATE action in Collections API should allow to upload a new configuration
[ https://issues.apache.org/jira/browse/SOLR-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541469#comment-13541469 ] Tomás Fernández Löbbe commented on SOLR-4061: - Mark, do you think there is more to be done in order to get this committed? > CREATE action in Collections API should allow to upload a new configuration > --- > > Key: SOLR-4061 > URL: https://issues.apache.org/jira/browse/SOLR-4061 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Tomás Fernández Löbbe >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: SOLR-4061.patch > > > When creating new collections with the Collection API, the only option is to > point to an existing configuration in ZK. It would be nice to be able to > upload a new configuration in the same command. > For more details see > http://lucene.472066.n3.nabble.com/Error-with-SolrCloud-td4019351.html -- 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] [Updated] (LUCENE-3614) Add a JUL/SLF4J example InfoStream implementation so IndexWriter can log to JUL/SLF4J
[ https://issues.apache.org/jira/browse/LUCENE-3614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated LUCENE-3614: Fix Version/s: (was: 4.1) 5.0 4.2 > Add a JUL/SLF4J example InfoStream implementation so IndexWriter can log to > JUL/SLF4J > - > > Key: LUCENE-3614 > URL: https://issues.apache.org/jira/browse/LUCENE-3614 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 4.0-ALPHA >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.2, 5.0 > > > Followup to LUCENE-3598: Hoss suggested to add a default JUL/SLF4J > implementation to contrib/misc (that can also be used by SOLR to log > IndexWriter verbose messages to its logging framework). -- 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] [Updated] (LUCENE-3786) Create SearcherTaxoManager
[
https://issues.apache.org/jira/browse/LUCENE-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated LUCENE-3786:
Fix Version/s: (was: 4.1)
5.0
4.2
> Create SearcherTaxoManager
> --
>
> Key: LUCENE-3786
> URL: https://issues.apache.org/jira/browse/LUCENE-3786
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/facet
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 4.2, 5.0
>
>
> If an application wants to use an IndexSearcher and TaxonomyReader in a
> SearcherManager-like fashion, it cannot use a separate SearcherManager, and
> say a TaxonomyReaderManager, because the IndexSearcher and TaxoReader
> instances need to be in sync. That is, the IS-TR pair must match, or
> otherwise the category ordinals that are encoded in the search index might
> not match the ones in the taxonomy index.
> This can happen if someone reopens the IndexSearcher's IndexReader, but does
> not refresh the TaxonomyReader, and the category ordinals that exist in the
> reopened IndexReader are not yet visible to the TaxonomyReader instance.
> I'd like to create a SearcherTaxoManager (which is a ReferenceManager) which
> manages an IndexSearcher and TaxonomyReader pair. Then an application will
> call:
> {code}
> SearcherTaxoPair pair = manager.acquire();
> try {
> IndexSearcher searcher = pair.searcher;
> TaxonomyReader taxoReader = pair.taxoReader;
> // do something with them
> } finally {
> manager.release(pair);
> pair = null;
> }
> {code}
--
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] [Commented] (LUCENE-3581) IndexReader#isCurrent() should return true on a NRT reader if no deletes are applied and only deletes are present in IW
[ https://issues.apache.org/jira/browse/LUCENE-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541466#comment-13541466 ] Mark Miller commented on LUCENE-3581: - Fixing this for 4.1 or should we push it? > IndexReader#isCurrent() should return true on a NRT reader if no deletes are > applied and only deletes are present in IW > --- > > Key: LUCENE-3581 > URL: https://issues.apache.org/jira/browse/LUCENE-3581 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 3.5, 4.0-ALPHA >Reporter: Simon Willnauer >Assignee: Simon Willnauer > Fix For: 4.1 > > > I keep forgetting about this, I better open an issue. If you have a NRT > reader without deletes applied it should infact return true on IR#isCurrent() > if the IW only has deletes in its buffer ie. no documents where updated / > added since the NRT reader was opened. Currently if there is a delete coming > in we force a reopen which does nothing since deletes are not applied anyway. -- 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] [Updated] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated LUCENE-2899: Fix Version/s: (was: 4.1) 5.0 4.2 > Add OpenNLP Analysis capabilities as a module > - > > Key: LUCENE-2899 > URL: https://issues.apache.org/jira/browse/LUCENE-2899 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, > LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, > OpenNLPTokenizer.java, opennlp_trunk.patch > > > Now that OpenNLP is an ASF project and has a nice license, it would be nice > to have a submodule (under analysis) that exposed capabilities for it. Drew > Farris, Tom Morton and I have code that does: > * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it > would have to change slightly to buffer tokens) > * NamedEntity recognition as a TokenFilter > We are also planning a Tokenizer/TokenFilter that can put parts of speech as > either payloads (PartOfSpeechAttribute?) on a token or at the same position. > I'd propose it go under: > modules/analysis/opennlp -- 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
4.1 release
I've started pushing on JIRA issue for a 4.1 release. If something is pushed that you are going to work on in the very near term, please put it back. I'll progressively get more aggressive about pushing and count on committers to fix any mistakes if they want something in 4.1. Remember, 4.2 can come shortly after 4.1. Next I will be pushing any 4.1 issues that have not been updated in a couple months. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3109) Rename FieldsConsumer to InvertedFieldsConsumer
[ https://issues.apache.org/jira/browse/LUCENE-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541461#comment-13541461 ] Mark Miller commented on LUCENE-3109: - 4.1 or push to 4.2? > Rename FieldsConsumer to InvertedFieldsConsumer > --- > > Key: LUCENE-3109 > URL: https://issues.apache.org/jira/browse/LUCENE-3109 > Project: Lucene - Core > Issue Type: Task > Components: core/codecs >Affects Versions: 4.0-ALPHA >Reporter: Simon Willnauer >Assignee: Michael McCandless >Priority: Minor > Fix For: 4.1 > > Attachments: LUCENE-3109.patch, LUCENE-3109.patch, LUCENE-3109.patch, > LUCENE-3109.patch, LUCENE-3109.patch, LUCENE-3109.patch > > > The name FieldsConsumer is missleading here it really is an > InvertedFieldsConsumer and since we are extending codecs to consume > non-inverted Fields we should be clear here. Same applies to Fields.java as > well as FieldsProducer. -- 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] [Updated] (LUCENE-2026) Refactoring of IndexWriter
[ https://issues.apache.org/jira/browse/LUCENE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated LUCENE-2026: Fix Version/s: (was: 4.1) 5.0 4.2 Been a long time since this has seen action - pushing out of 4.1. > Refactoring of IndexWriter > -- > > Key: LUCENE-2026 > URL: https://issues.apache.org/jira/browse/LUCENE-2026 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Minor > Fix For: 4.2, 5.0 > > > I've been thinking for a while about refactoring the IndexWriter into > two main components. > One could be called a SegmentWriter and as the > name says its job would be to write one particular index segment. The > default one just as today will provide methods to add documents and > flushes when its buffer is full. > Other SegmentWriter implementations would do things like e.g. appending or > copying external segments [what addIndexes*() currently does]. > The second component's job would it be to manage writing the segments > file and merging/deleting segments. It would know about > DeletionPolicy, MergePolicy and MergeScheduler. Ideally it would > provide hooks that allow users to manage external data structures and > keep them in sync with Lucene's data during segment merges. > API wise there are things we have to figure out, such as where the > updateDocument() method would fit in, because its deletion part > affects all segments, whereas the new document is only being added to > the new segment. > Of course these should be lower level APIs for things like parallel > indexing and related use cases. That's why we should still provide > easy to use APIs like today for people who don't need to care about > per-segment ops during indexing. So the current IndexWriter could > probably keeps most of its APIs and delegate to the new classes. -- 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] [Updated] (SOLR-3388) HTTP caching should be disabled by default for ContentStreamHandlers
[
https://issues.apache.org/jira/browse/SOLR-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-3388:
--
Fix Version/s: 5.0
> HTTP caching should be disabled by default for ContentStreamHandlers
>
>
> Key: SOLR-3388
> URL: https://issues.apache.org/jira/browse/SOLR-3388
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-3388-http-caching.patch
>
>
> RequestHandlers can disable HTTP Caching with the init-parameter:
> {code:xml}false{code}
> For UpdateHandlers, disabling caching by default makes more sense.
--
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] [Commented] (SOLR-3388) HTTP caching should be disabled by default for ContentStreamHandlers
[
https://issues.apache.org/jira/browse/SOLR-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541459#comment-13541459
]
Mark Miller commented on SOLR-3388:
---
Do you plan on committing this for 4.1 Ryan?
> HTTP caching should be disabled by default for ContentStreamHandlers
>
>
> Key: SOLR-3388
> URL: https://issues.apache.org/jira/browse/SOLR-3388
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 4.1
>
> Attachments: SOLR-3388-http-caching.patch
>
>
> RequestHandlers can disable HTTP Caching with the init-parameter:
> {code:xml}false{code}
> For UpdateHandlers, disabling caching by default makes more sense.
--
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] [Commented] (SOLR-4247) Investigate TestSimplePropertiesWriter failure
[ https://issues.apache.org/jira/browse/SOLR-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541458#comment-13541458 ] Commit Tag Bot commented on SOLR-4247: -- [branch_4x commit] James Dyer http://svn.apache.org/viewvc?view=revision&revision=1427220 SOLR-4247: fix bug with TestSimplePropertiesWriter > Investigate TestSimplePropertiesWriter failure > -- > > Key: SOLR-4247 > URL: https://issues.apache.org/jira/browse/SOLR-4247 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 >Reporter: James Dyer >Assignee: James Dyer > Fix For: 4.1, 5.0 > > Attachments: SOLR-4247.patch > > > TestSimplePropertiesWriter fails with this seed: > B1D1027ED05EBE82:35144E46BF1DD437 -- 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] [Updated] (SOLR-3570) Release Resource Stream in Suggestor
[ https://issues.apache.org/jira/browse/SOLR-3570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3570: -- Fix Version/s: (was: 4.1) > Release Resource Stream in Suggestor > - > > Key: SOLR-3570 > URL: https://issues.apache.org/jira/browse/SOLR-3570 > Project: Solr > Issue Type: Improvement > Components: spellchecker >Affects Versions: 3.6, 4.0-ALPHA, 5.0 >Reporter: Simon Willnauer >Assignee: Simon Willnauer > Attachments: SOLR-3570.patch > > > Currently the Suggestor doesn't release the resource stream if a file > dictionary is loaded. The FileDictionary implemenation closes the stream but > only if we exhaust the stream entirely. Yet, we should close this on the > consumer side too. double close is no harm. -- 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] [Commented] (SOLR-3279) Upgrade Carrot2 to minimize the possibility of dependency clashes
[ https://issues.apache.org/jira/browse/SOLR-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541457#comment-13541457 ] Mark Miller commented on SOLR-3279: --- Any plans on this for 4.1 Stanislaw? > Upgrade Carrot2 to minimize the possibility of dependency clashes > - > > Key: SOLR-3279 > URL: https://issues.apache.org/jira/browse/SOLR-3279 > Project: Solr > Issue Type: Task > Components: contrib - Clustering >Reporter: Stanislaw Osinski >Assignee: Stanislaw Osinski >Priority: Minor > Fix For: 4.1 > > > When we get closer to the 4.0 release, update Carrot2 to the then newest > version so that the dependencies get a refresh too (re: > http://lucene.472066.n3.nabble.com/Old-Google-Guava-library-needs-updating-r05-td3854433.html). -- 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] [Updated] (SOLR-3626) CurrencyField with sortMissingLast="true"
[ https://issues.apache.org/jira/browse/SOLR-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3626: -- Fix Version/s: (was: 4.1) 5.0 4.2 > CurrencyField with sortMissingLast="true" > - > > Key: SOLR-3626 > URL: https://issues.apache.org/jira/browse/SOLR-3626 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 3.6 >Reporter: Mikhail Mitrofanov >Assignee: Jan Høydahl > Fix For: 4.2, 5.0 > > > My schema.xml has: > precisionStep="8" currencyConfig="currency.xml" defaultCurrency="RUR" /> > ... > > However, the record without specifying a price_r, if you sort appear in the > list. -- 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] [Updated] (SOLR-3613) Namespace Solr's JAVA OPTIONS
[
https://issues.apache.org/jira/browse/SOLR-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-3613:
--
Fix Version/s: (was: 4.1)
5.0
4.2
> Namespace Solr's JAVA OPTIONS
> -
>
> Key: SOLR-3613
> URL: https://issues.apache.org/jira/browse/SOLR-3613
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.0-ALPHA
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 4.2, 5.0
>
>
> Solr being a web-app, should play nicely in a setting where users deploy it
> on a shared appServer.
> To this regard Solr's JAVA_OPTS should be properly name spaced, both to avoid
> name clashes and for clarity when reading your appserver startup script. We
> currently do that with most: {{solr.solr.home, solr.data.dir,
> solr.abortOnConfigurationError, solr.directoryFactory,
> solr.clustering.enabled, solr.velocity.enabled etc}}, but for some opts we
> fail to do so.
> Before release of 4.0 we should make sure to clean this up.
--
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] [Updated] (SOLR-2347) Use InputStream and not Reader for XML parsing
[ https://issues.apache.org/jira/browse/SOLR-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2347: -- Fix Version/s: (was: 4.1) 5.0 4.2 > Use InputStream and not Reader for XML parsing > -- > > Key: SOLR-2347 > URL: https://issues.apache.org/jira/browse/SOLR-2347 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.2, 5.0 > > > Followup to SOLR-96: > Solr mostly uses java.io.Reader and passes this Reader to the XML parser. > According to XML spec, a XML file should be initially seen as a binary stream > with a default charset of UTF-8 or another charset given by the network > protocol (like Content-Type header in HTTP). But very important, this default > charset is only a "hint" to the parser - mandatory is the charset from the > XML header processing inctruction. Because of this, the parser must be able > to change the charset when reading the XML headers (possibly also when seeing > BOM markers). This is not possible if the XML parser gets a java.io.Reader > instead of java.io.InputStreams. SOLR-96 already fixed this for the > XmlUpdateRequestHandler and the DocumentAnalysisRequestHandler. This issue > should fix the rest to be conforming to XML-spec (open schema.xml and > config.xml as InputStream not Reader and others). > This change would not break anything in Solr (perhaps only backwards > compatibility in the API), as the default used by XML parsers is UTF-8. -- 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] [Updated] (SOLR-2827) RegexpBoost Update Processor
[ https://issues.apache.org/jira/browse/SOLR-2827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2827: -- Fix Version/s: (was: 4.1) 5.0 4.2 > RegexpBoost Update Processor > > > Key: SOLR-2827 > URL: https://issues.apache.org/jira/browse/SOLR-2827 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Labels: UpdateProcessor > Fix For: 4.2, 5.0 > > Attachments: SOLR-2827.patch > > > Processor which reads a string field and outputs a float field with a boost > value if the input string matched one of several RegEx. > The processor reads a separate file with one RegEx per line with associated > boost value. > We used it to (de)boost web pages based on URL patterns. Could be used for > many other use cases as well > Kindly donated by Oslo University -- 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] [Resolved] (SOLR-4247) Investigate TestSimplePropertiesWriter failure
[ https://issues.apache.org/jira/browse/SOLR-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer resolved SOLR-4247. -- Resolution: Fixed > Investigate TestSimplePropertiesWriter failure > -- > > Key: SOLR-4247 > URL: https://issues.apache.org/jira/browse/SOLR-4247 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 >Reporter: James Dyer >Assignee: James Dyer > Fix For: 4.1, 5.0 > > Attachments: SOLR-4247.patch > > > TestSimplePropertiesWriter fails with this seed: > B1D1027ED05EBE82:35144E46BF1DD437 -- 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] [Commented] (SOLR-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541456#comment-13541456 ] Commit Tag Bot commented on SOLR-788: - [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1427219 SOLR-788: set mlt.count back to 5 > MoreLikeThis should support distributed search > -- > > Key: SOLR-788 > URL: https://issues.apache.org/jira/browse/SOLR-788 > Project: Solr > Issue Type: Improvement > Components: MoreLikeThis >Reporter: Grant Ingersoll >Assignee: Mark Miller >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: AlternateDistributedMLT.patch, MLT.patch, MLT.patch, > MoreLikeThisComponentTest.patch, SOLR-788.patch, SOLR-788.patch, > SolrMoreLikeThisPatch.txt > > > The MoreLikeThis component should support distributed processing. > See SOLR-303. -- 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] [Updated] (SOLR-1337) Spans and Payloads Query Support
[ https://issues.apache.org/jira/browse/SOLR-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1337: -- Fix Version/s: (was: 4.1) 5.0 4.2 > Spans and Payloads Query Support > > > Key: SOLR-1337 > URL: https://issues.apache.org/jira/browse/SOLR-1337 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Fix For: 4.2, 5.0 > > > It would be really nice to have query side support for: Spans and Payloads. > The main ingredient missing at this point is QueryParser support and a output > format for the spans and the payload spans. -- 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] [Updated] (SOLR-2178) Use the Velocity UI as the default tutorial example
[ https://issues.apache.org/jira/browse/SOLR-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2178: -- Fix Version/s: (was: 4.1) 5.0 4.2 > Use the Velocity UI as the default tutorial example > --- > > Key: SOLR-2178 > URL: https://issues.apache.org/jira/browse/SOLR-2178 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.2, 5.0 > > > The /browse example in solr/example is much nicer to look at and work with, > we should convert the tutorial over to use it so as to present a nicer view > of Solr's capabilities. -- 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] [Updated] (SOLR-2580) Create Components to Support Using Business Rules in Solr
[
https://issues.apache.org/jira/browse/SOLR-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-2580:
--
Fix Version/s: (was: 4.1)
5.0
4.2
> Create Components to Support Using Business Rules in Solr
> -
>
> Key: SOLR-2580
> URL: https://issues.apache.org/jira/browse/SOLR-2580
> Project: Solr
> Issue Type: New Feature
> Components: Rules
>Reporter: Tomás Fernández Löbbe
>Assignee: Grant Ingersoll
> Fix For: 4.2, 5.0
>
>
> The goal is to be able to adjust the relevance of documents based on user
> defined business rules.
> For example, in a e-commerce site, when the user chooses the "shoes"
> category, we may be interested in boosting products from a certain brand.
> This can be expressed as a rule in the following way:
> rule "Boost Adidas products when searching shoes"
> when
> $qt : QueryTool()
> TermQuery(term.field=="category", term.text=="shoes")
> then
> $qt.boost("{!lucene}brand:adidas");
> end
> The QueryTool object should be used to alter the main query in a easy way.
> Even more human-like rules can be written:
> rule "Boost Adidas products when searching shoes"
> when
> Query has term "shoes" in field "product"
> then
> Add boost query "{!lucene}brand:adidas"
> end
> These rules are written in a text file in the config directory and can be
> modified at runtime. Rules will be managed using JBoss Drools:
> http://www.jboss.org/drools/drools-expert.html
> On a first stage, it will allow to add boost queries or change sorting fields
> based on the user query, but it could be extended to allow more options.
--
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] [Updated] (SOLR-4024) DebugComponent enhancement to report on what documents are potentially missing fields
[ https://issues.apache.org/jira/browse/SOLR-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4024: -- Fix Version/s: (was: 4.1) 4.2 > DebugComponent enhancement to report on what documents are potentially > missing fields > - > > Key: SOLR-4024 > URL: https://issues.apache.org/jira/browse/SOLR-4024 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.2, 5.0 > > > It's often handy when debugging to know when a document is missing a field > that is either searched against or in the schema -- 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] [Updated] (SOLR-2479) Phrase (arbitrary delimiter) based autocomplete
[ https://issues.apache.org/jira/browse/SOLR-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2479: -- Fix Version/s: (was: 4.1) 5.0 4.2 > Phrase (arbitrary delimiter) based autocomplete > --- > > Key: SOLR-2479 > URL: https://issues.apache.org/jira/browse/SOLR-2479 > Project: Solr > Issue Type: New Feature > Components: spellchecker >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.2, 5.0 > > > Much like the one described here by Google: > http://googleblog.blogspot.com/2011/04/more-predictions-in-autocomplete.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FMKuf+%28Official+Google+Blog%29 > My idea was to allow arbitrary delimiters -- then infix suggestions would > also be possible (although these are _not_ of much practical importance and > relatively few geeks would find them useful :). -- 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] [Commented] (SOLR-3507) Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler
[ https://issues.apache.org/jira/browse/SOLR-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541455#comment-13541455 ] Mark Miller commented on SOLR-3507: --- You going to finish this for 4.1 sami? > Refactor parts of solr doing inter node communication to use > shardhandlerfactory/shardhandler > - > > Key: SOLR-3507 > URL: https://issues.apache.org/jira/browse/SOLR-3507 > Project: Solr > Issue Type: Improvement >Reporter: Sami Siren >Assignee: Sami Siren >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-3507.patch, SOLR-3507.patch, SOLR-3507.patch > > > Sequal to SOLR-3480, the aim is to change most (all?) parts of solr that need > to talk to different nodes to use ShardHandlerFacory from corecontainer. -- 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] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541454#comment-13541454 ] Mark Miller commented on SOLR-3854: --- Sami, Hossman, will you get this in shortly for 4.1 or should I push it to 4.2? > SolrCloud does not work with https > -- > > Key: SOLR-3854 > URL: https://issues.apache.org/jira/browse/SOLR-3854 > Project: Solr > Issue Type: Bug >Reporter: Sami Siren >Assignee: Sami Siren > Fix For: 4.1, 5.0 > > Attachments: SOLR-3854.patch, SOLR-3854.patch > > > There are a few places in current codebase that assume http is used. This > prevents using https when running solr in cloud mode. -- 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] [Commented] (SOLR-1972) Need additional query stats in admin interface - median, 95th and 99th percentile
[ https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541453#comment-13541453 ] Shawn Heisey commented on SOLR-1972: Alan, my latest plan still utilized the global registry, though it did it explicitly, so that individual metric objects were removed by a close() method on RequestHandlerBase. That would have required many changes - finding every place that a handler might be deleted or replaced. That likely would require significant refactoring rather than just a few code edits. I was prepared to do it, if someone could light the path. An explicit registry per core is an awesome idea, if it can be implemented without similar pain to what I've just described. Looking at RequestHandlerBase, I don't see any direct way to access the containing core object. Experimentation shows that adding a constructor with a SolrCore argument is not the right approach because it would require *a lot* of changes that are also likely to break custom user code. > Need additional query stats in admin interface - median, 95th and 99th > percentile > - > > Key: SOLR-1972 > URL: https://issues.apache.org/jira/browse/SOLR-1972 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 1.4 >Reporter: Shawn Heisey >Assignee: Alan Woodward >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, > elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, leak-closeable.patch, > leak.patch, revert-SOLR-1972.patch, SOLR-1972-branch3x-url_pattern.patch, > SOLR-1972-branch4x.patch, SOLR-1972-branch4x.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, solr1972-metricsregistry-branch4x-failure.log, > SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, > SOLR-1972-url_pattern.patch, stacktraces.tar.gz > > > I would like to see more detailed query statistics from the admin GUI. This > is what you can get now: > requests : 809 > errors : 0 > timeouts : 0 > totalTime : 70053 > avgTimePerRequest : 86.59209 > avgRequestsPerSecond : 0.8148785 > I'd like to see more data on the time per request - median, 95th percentile, > 99th percentile, and any other statistical function that makes sense to > include. In my environment, the first bunch of queries after startup tend to > take several seconds each. I find that the average value tends to be useless > until it has several thousand queries under its belt and the caches are > thoroughly warmed. The statistical functions I have mentioned would quickly > eliminate the influence of those initial slow queries. > The system will have to store individual data about each query. I don't know > if this is something Solr does already. It would be nice to have a > configurable count of how many of the most recent data points are kept, to > control the amount of memory the feature uses. The default value could be > something like 1024 or 4096. -- 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] [Updated] (SOLR-3382) Finegrained error propagation (focus on multi-document updates)
[ https://issues.apache.org/jira/browse/SOLR-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3382: -- Fix Version/s: (was: 4.1) 5.0 4.2 > Finegrained error propagation (focus on multi-document updates) > --- > > Key: SOLR-3382 > URL: https://issues.apache.org/jira/browse/SOLR-3382 > Project: Solr > Issue Type: New Feature > Components: clients - java, Response Writers, update >Affects Versions: 3.5 >Reporter: Per Steffensen >Assignee: Per Steffensen > Labels: client, documents, error, multiple, propagation, update > Fix For: 4.2, 5.0 > > > Today when an error occurs on server side during the handling of a request, > the handling of the request will stop at the point when the error occured, > and only a error-message (reason part of HTTP status line) and error-code > (HTTP response code) is pushed back to the sender of the request. > This can be improved in several ways > - Reacting as a client on errors, solely based on a textual message and a > HTTP response code is hard. The error ought have some kind of type telling > the client which kind of error happened. > - When handling multi-document updates the error might happen during the > handling of one of the documents - potentially not the first document and > potentially not the last document. > -- The client ought to get information about which documents where > successfully updated (the ones comming before the document creating the > error). > -- If the error updating a document is not due to a general problem, it could > very well be that some of the documents not yet handled at the time of the > error (the documents comming after the document creating the error), could be > successfully updated - so why not try that. > -- If continuing the updating of documents, even after one document-update > resulted in an error (as suggested above), the updating of some of those > documents might also result in an error. This leads to another improvement, > namely being able to send information about more than one error back to the > client. -- 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] [Updated] (SOLR-3383) Async responses in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3383: -- Fix Version/s: (was: 4.1) 5.0 4.2 > Async responses in SolrJ > > > Key: SOLR-3383 > URL: https://issues.apache.org/jira/browse/SOLR-3383 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 3.5 >Reporter: Per Steffensen >Assignee: Per Steffensen > Labels: async, asynchronous, concurrency, query, solrj, update > Fix For: 4.2, 5.0 > > Attachments: SOLR-3383.patch > > > Today it is like this > - SolrServer.request returns NamedList > - SolrRequest.process returns SolrResponse > - Public methods on SolrServer like addX, optimize, commit, queryX etc. > returns subclasses of SolrResponse (e.g. "add" returns UpdateResponse) > - etc > This is all synchronous - that is, the calling thread of those methods will > wait for the response before being able to continue. I believe the industry > today agrees that "operations" like client-server network-requireing > operations should be done asynchronously seens from the client API. Therefore > basically we should change those methods > - SolrServer.request returns Future> > - SolrRequest.process returns Future > - SolrServer.xxx returns Future > and make the appropriate changes in the implementations below. > My main argument for this right now, is that ConcurrentUpdateSolrServer > really is not able to hand over responses to the calling client. Guess that > it is also the reason why it is only a "Update"-SolrServer and not a complete > SolrServer (being able to do queries etc.) - updates does not require sending > responses (except primitive errors) back to the client, queries etc does. Now > that we do "finegrained error propagation" (SOLR-3382) in order to send > "unique key constraint"- and "versioning"-errors (SOLR-3173 and SOLR-3178) > back to the client in responses to update-request, suddenly it is not true > anymore that updates does not require sending responses back to the client. > Making the changes suggested above (returning Futures) would > - Allow ConcurrentUpdateSolrServer to be used for updates potentially > resulting in "unique key constraint"- and "versioning"-errors > - Allow ConcurrentUpdateSolrServer to become ConcurrentSolrServer - also > being able to do queries etc > - Do cool stuff like SOLR-3384 > - Make SolrJ more modern with respect to asynchronous principles -- 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] [Updated] (SOLR-3178) Versioning - optimistic locking
[ https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3178: -- Fix Version/s: (was: 4.1) > Versioning - optimistic locking > --- > > Key: SOLR-3178 > URL: https://issues.apache.org/jira/browse/SOLR-3178 > Project: Solr > Issue Type: New Feature > Components: update >Affects Versions: 3.5 > Environment: All >Reporter: Per Steffensen >Assignee: Per Steffensen > Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey, > update, versioning > Attachments: SOLR-3173_3178_3382_3428_plus.patch, > SOLR-3173_3178_3382_3428_plus.patch, SOLR_3173_3178_3382_plus.patch, > SOLR-3178.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > In order increase the ability of Solr to be used as a NoSql database (lots of > concurrent inserts, updates, deletes and queries in the entire lifetime of > the index) instead of just a search index (first: everything indexed (in one > thread), after: only queries), I would like Solr to support versioning to be > used for optimistic locking. > When my intent (see SOLR-3173) is to update an existing document, I will need > to provide a version-number equal to "the version number I got when I fetched > the existing document for update" plus one. If this provided version-number > does not correspond to "the newest version-number of that document at the > time of update" plus one, I will get a VersionConflict error. If it does > correspond the document will be updated with the new one, so that "the newest > version-number of that document" is NOW one higher than before the update. > Correct but efficient concurrency handling. > When my intent (see SOLR-3173) is to insert a new document, the version > number provided will not be used - instead a version-number 0 will be used. > According to SOLR-3173 insert will only succeed if a document with the same > value on uniqueKey-field does not already exist. > In general when talking about different versions of "the same document", of > course we need to be able to identify when a document "is the same" - that, > per definition, is when the values of the uniqueKey-fields are equal. > The functionality provided by this issue is only really meaningfull when you > run with "updateLog" activated. > This issue might be solved more or less at the same time as SOLR-3173, and > only one single SVN patch might be given to cover both issues. -- 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] [Updated] (SOLR-3173) Database semantics - insert and update
[ https://issues.apache.org/jira/browse/SOLR-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3173: -- Fix Version/s: (was: 4.1) 4.2 > Database semantics - insert and update > -- > > Key: SOLR-3173 > URL: https://issues.apache.org/jira/browse/SOLR-3173 > Project: Solr > Issue Type: New Feature > Components: update >Affects Versions: 3.5 > Environment: All >Reporter: Per Steffensen >Assignee: Per Steffensen > Labels: RDBMS, insert, nosql, uniqueKey, update > Fix For: 4.2, 5.0 > > Original Estimate: 168h > Remaining Estimate: 168h > > In order increase the ability of Solr to be used as a NoSql database (lots of > concurrent inserts, updates, deletes and queries in the entire lifetime of > the index) instead of just a search index (first: everything indexed (in one > thread), after: only queries), I would like Solr to support the following > features inspired by RDBMSs and other NoSql databases. > * Given a solr-core with a schema containing a uniqueKey-field "uniqueField" > and a document Dold, when trying to INSERT a new document Dnew where > Dold.uniqueField is equal to Dnew.uniqueField, then I want a > DocumentAlredyExists error. If no such document Dold exists I want Dnew > indexed into the solr-core. > * Given a solr-core with a schema containing a uniqueKey-field "uniqueField" > and a document Dold, when trying to UPDATE a document Dnew where > Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and > Dnew added to the index (just as it is today).If no such document Dold exists > I want nothing to happen (Dnew is not added to the index) > The essence of this issue is to be able to state your intent (insert or > update) and have slightly different semantics (from each other and the > existing update) depending on you intent. > The functionality provided by this issue is only really meaningfull when you > run with "updateLog" activated. > This issue might be solved more or less at the same time as SOLR-3178, and > only one single SVN patch might be given to cover both issues. -- 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] [Resolved] (SOLR-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-788. -- Resolution: Fixed > MoreLikeThis should support distributed search > -- > > Key: SOLR-788 > URL: https://issues.apache.org/jira/browse/SOLR-788 > Project: Solr > Issue Type: Improvement > Components: MoreLikeThis >Reporter: Grant Ingersoll >Assignee: Mark Miller >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: AlternateDistributedMLT.patch, MLT.patch, MLT.patch, > MoreLikeThisComponentTest.patch, SOLR-788.patch, SOLR-788.patch, > SolrMoreLikeThisPatch.txt > > > The MoreLikeThis component should support distributed processing. > See SOLR-303. -- 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
RE: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.6.0_37) - Build # 3515 - Failure!
Too funny that we hit this once per year *g*. We should have date randomization, too (not sure how to do this). I hope it is fixed now after SOLR-4247! This build did not yet contain the fix! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] > Sent: Monday, December 31, 2012 7:42 PM > To: dev@lucene.apache.org > Subject: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.6.0_37) - Build # 3515 - > Failure! > > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/3515/ > Java: 32bit/jdk1.6.0_37 -server -XX:+UseParallelGC > > 1 tests failed. > REGRESSION: > org.apache.solr.handler.dataimport.TestSimplePropertiesWriter.testSimpleP > ropertiesWriter > > Error Message: > Exception during query > > Stack Trace: > java.lang.RuntimeException: Exception during query > at > __randomizedtesting.SeedInfo.seed([11DAB83E0E826724:951FF40661C10D9 > 1]:0) > at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:518) > at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:485) > at > org.apache.solr.handler.dataimport.TestSimplePropertiesWriter.testSimpleP > ropertiesWriter(TestSimplePropertiesWriter.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j > ava:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > dRunner.java:1559) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(Rando > mizedRunner.java:79) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > mizedRunner.java:737) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > mizedRunner.java:773) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > mizedRunner.java:787) > at > com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1. > evaluate(SystemPropertiesRestoreRule.java:53) > at > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > SetupTeardownChained.java:50) > at > org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCa > cheSanity.java:51) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA > fterRule.java:46) > at > com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1 > .evaluate(SystemPropertiesInvariantRule.java:55) > at > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh > readAndTestName.java:49) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule > IgnoreAfterMaxFailures.java:70) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure > .java:48) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat > ementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner. > run(ThreadLeakControl.java:358) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > (ThreadLeakControl.java:782) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > eakControl.java:442) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > domizedRunner.java:746) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando > mizedRunner.java:648) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando > mizedRunner.java:682) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > mizedRunner.java:693) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat > ementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1. > evaluate(SystemPropertiesRestoreRule.java:53) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA > fterRule.java:46) > at > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCl > assName.java:42) > at > com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1 > .evaluate(SystemPropertiesInvariantRule.java:55) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat > ementAdapter.java:36) > at > org.apache.lucene
[jira] [Commented] (SOLR-4247) Investigate TestSimplePropertiesWriter failure
[ https://issues.apache.org/jira/browse/SOLR-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541450#comment-13541450 ] Commit Tag Bot commented on SOLR-4247: -- [trunk commit] James Dyer http://svn.apache.org/viewvc?view=revision&revision=1427215 SOLR-4247: fix bug with TestSimplePropertiesWriter > Investigate TestSimplePropertiesWriter failure > -- > > Key: SOLR-4247 > URL: https://issues.apache.org/jira/browse/SOLR-4247 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 >Reporter: James Dyer >Assignee: James Dyer > Fix For: 4.1, 5.0 > > Attachments: SOLR-4247.patch > > > TestSimplePropertiesWriter fails with this seed: > B1D1027ED05EBE82:35144E46BF1DD437 -- 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] [Commented] (SOLR-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541449#comment-13541449 ] Commit Tag Bot commented on SOLR-788: - [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1427218 SOLR-788: set mlt.count back to 5 > MoreLikeThis should support distributed search > -- > > Key: SOLR-788 > URL: https://issues.apache.org/jira/browse/SOLR-788 > Project: Solr > Issue Type: Improvement > Components: MoreLikeThis >Reporter: Grant Ingersoll >Assignee: Mark Miller >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: AlternateDistributedMLT.patch, MLT.patch, MLT.patch, > MoreLikeThisComponentTest.patch, SOLR-788.patch, SOLR-788.patch, > SolrMoreLikeThisPatch.txt > > > The MoreLikeThis component should support distributed processing. > See SOLR-303. -- 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
get a Word in FuzzyQuery
Hello guys. I'm working with FuzzyQuery and I a have a doubt: I would like
the lucene, return to me the correct word instead of me returning the
document, for example:
query = Brazil
document = "Brazil is a big country"
with this code:
[code]
Analyzer analyzer = new StandardAnalyzer(Version.LUCENE_CURRENT);
Directory directory = new RAMDirectory();
IndexWriter iwriter = new IndexWriter(directory, analyzer, true, new
IndexWriter.MaxFieldLength(25000));
Document doc;
for (int i = 0; i < list.size(); i++) {
doc = new Document();
doc.add(new Field("fieldname", list.get(i), Field.Store.YES,
Field.Index.ANALYZED));
iwriter.addDocument(doc);
}
iwriter.close();
IndexSearcher isearcher = new IndexSearcher(directory);
Term term = new Term("fieldname", s);
FuzzyQuery query = new FuzzyQuery(term, 0.75f, 0);
TopScoreDocCollector collector = TopScoreDocCollector.create(10, true);
isearcher.search(query, collector);
ScoreDoc[] hits = collector.topDocs().scoreDocs;
for (int i = 0; i < hits.length; i++) {
Document hitDoc = isearcher.doc(hits[i].doc);
listr.add(hitDoc.get("fieldname"));
}
isearcher.close();
directory.close();
for (int i = 0 ; i < listr.size() ; i++ ) {
resp.add(listr.get(i));//melhorar método para fazer busca dentro de
busca
}
return resp;
[/code]
The lucene, return to me the entire document ie "Brazil is a big country",
but I just wanted the word "Brazil". Somebody can help me?
--
View this message in context:
http://lucene.472066.n3.nabble.com/get-a-Word-in-FuzzyQuery-tp4029521.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.6.0_37) - Build # 3515 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/3515/ Java: 32bit/jdk1.6.0_37 -server -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.solr.handler.dataimport.TestSimplePropertiesWriter.testSimplePropertiesWriter Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([11DAB83E0E826724:951FF40661C10D91]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:518) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:485) at org.apache.solr.handler.dataimport.TestSimplePropertiesWriter.testSimplePropertiesWriter(TestSimplePropertiesWriter.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.RuntimeException: REQUEST FAILED:
[jira] [Commented] (SOLR-4124) You should be able to set the update log directory with the CoreAdmin API the same way as the data directory.
[ https://issues.apache.org/jira/browse/SOLR-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541442#comment-13541442 ] Commit Tag Bot commented on SOLR-4124: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1427214 SOLR-4124: persistence support > You should be able to set the update log directory with the CoreAdmin API the > same way as the data directory. > - > > Key: SOLR-4124 > URL: https://issues.apache.org/jira/browse/SOLR-4124 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4124.patch > > -- 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] [Updated] (SOLR-4247) Investigate TestSimplePropertiesWriter failure
[ https://issues.apache.org/jira/browse/SOLR-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-4247: - Attachment: SOLR-4247.patch Patch fixes this new-years-day issue. This was a test bug in that it was comparing GMT's year with the default locale's year. > Investigate TestSimplePropertiesWriter failure > -- > > Key: SOLR-4247 > URL: https://issues.apache.org/jira/browse/SOLR-4247 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 >Reporter: James Dyer >Assignee: James Dyer > Fix For: 4.1, 5.0 > > Attachments: SOLR-4247.patch > > > TestSimplePropertiesWriter fails with this seed: > B1D1027ED05EBE82:35144E46BF1DD437 -- 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-4248) "ant eclipse" should declare .svn directories as derived
Shawn Heisey created SOLR-4248: -- Summary: "ant eclipse" should declare .svn directories as derived Key: SOLR-4248 URL: https://issues.apache.org/jira/browse/SOLR-4248 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 4.0 Reporter: Shawn Heisey Fix For: 4.1, 5.0 Eclipse has an awesome "file search" feature, but with the default eclipse config, such searches also search the numerous and large .svn directories. If there's any way to mark .svn directories as "derived" then eclipse will not search them, which will greatly speed up searches. I will look into whether I can figure out a patch for doing this, but someone who is already intimately familiar with the workings of "ant eclipse" may be able to do it faster. -- 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] [Commented] (SOLR-4124) You should be able to set the update log directory with the CoreAdmin API the same way as the data directory.
[ https://issues.apache.org/jira/browse/SOLR-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541437#comment-13541437 ] Commit Tag Bot commented on SOLR-4124: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1427213 SOLR-4124: persistence support > You should be able to set the update log directory with the CoreAdmin API the > same way as the data directory. > - > > Key: SOLR-4124 > URL: https://issues.apache.org/jira/browse/SOLR-4124 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4124.patch > > -- 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] [Resolved] (SOLR-4124) You should be able to set the update log directory with the CoreAdmin API the same way as the data directory.
[ https://issues.apache.org/jira/browse/SOLR-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-4124. --- Resolution: Fixed > You should be able to set the update log directory with the CoreAdmin API the > same way as the data directory. > - > > Key: SOLR-4124 > URL: https://issues.apache.org/jira/browse/SOLR-4124 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4124.patch > > -- 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
Re: Improvement: Add commented-out /MLT handler to example solrconfig.xml
Could you make a JIRA issue? On Mon, Dec 31, 2012 at 11:27 AM, Jack Krupansky wrote: > Solrconfig.xml has lots of great suggestions for various options that are > commented out, which is fine. I did notice one useful feature that doesn’t > even have a commented-out suggestion: the MoreLikeThis request handler. I > suggest we add it. > > Does anybody know of any good reason why it isn’t there already? Or why it > shouldn’t be added? > > And is there any significant downside to adding it as an active handler in > the example solrconfig? > > > > > I would simply note that since the mlt search component is already > configured in Solr by default, most of the MLT code is already being loaded > in Solr, so there should be no significant penalty. > > -- Jack Krupansky -- - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3655) A starting replica can briefly appear active after Solr starts and before recovery begins.
[ https://issues.apache.org/jira/browse/SOLR-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3655: -- Fix Version/s: (was: 4.1) 4.2 > A starting replica can briefly appear active after Solr starts and before > recovery begins. > -- > > Key: SOLR-3655 > URL: https://issues.apache.org/jira/browse/SOLR-3655 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.2, 5.0 > > -- 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] [Updated] (SOLR-3881) frequent OOM in LanguageIdentifierUpdateProcessor
[
https://issues.apache.org/jira/browse/SOLR-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-3881:
--
Fix Version/s: (was: 4.1)
4.2
Assignee: (was: Mark Miller)
> frequent OOM in LanguageIdentifierUpdateProcessor
> -
>
> Key: SOLR-3881
> URL: https://issues.apache.org/jira/browse/SOLR-3881
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 4.0
> Environment: CentOS 6.x, JDK 1.6, (java -server -Xms2G -Xmx2G
> -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=)
>Reporter: Rob Tulloh
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-3881.patch
>
>
> We are seeing frequent failures from Solr causing it to OOM. Here is the
> stack trace we observe when this happens:
> {noformat}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2882)
> at
> java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
> at java.lang.StringBuffer.append(StringBuffer.java:224)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.concatFields(LanguageIdentifierUpdateProcessor.java:286)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(LanguageIdentifierUpdateProcessor.java:189)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.processAdd(LanguageIdentifierUpdateProcessor.java:171)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler$2.update(BinaryUpdateRequestHandler.java:90)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:140)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:120)
> at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:221)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:105)
> at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:186)
> at
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:112)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:147)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler.parseAndLoadDocs(BinaryUpdateRequestHandler.java:100)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler.access$000(BinaryUpdateRequestHandler.java:47)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler$1.load(BinaryUpdateRequestHandler.java:58)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
> {noformat}
--
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] [Updated] (SOLR-3872) When an update succeeds locally but fails on a replica, we ask that replica to recover - this should be done asynchronously.
[ https://issues.apache.org/jira/browse/SOLR-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3872: -- Fix Version/s: (was: 4.1) 4.2 > When an update succeeds locally but fails on a replica, we ask that replica > to recover - this should be done asynchronously. > > > Key: SOLR-3872 > URL: https://issues.apache.org/jira/browse/SOLR-3872 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.2, 5.0 > > -- 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] [Updated] (SOLR-4193) A ZooKeeper RequestHandler that allows you to post config files to a collections linked config set or a specific config set.
[ https://issues.apache.org/jira/browse/SOLR-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4193: -- Fix Version/s: (was: 4.1) 4.2 > A ZooKeeper RequestHandler that allows you to post config files to a > collections linked config set or a specific config set. > > > Key: SOLR-4193 > URL: https://issues.apache.org/jira/browse/SOLR-4193 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: SOLR-4193.patch, SOLR-4193.patch > > > Could have an admin zk handler and one per core? > An admin zk handler would allow you to access it without specifying an > existing core if done right. > One per core lets you do things like: > post solrconfig.xml to localhost:8983:/solr/collection1/zkhandler > Then we look up what config set we linked to and overwrite the solrconfig.xml. > You can already GET config files through another handler, so at the moment > I'd avoid duplicating that. > Could imagine adding commands over time though. -- 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
[JENKINS] Lucene-Solr-Tests-trunk-java7 - Build # 3595 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-java7/3595/ 1 tests failed. REGRESSION: org.apache.solr.handler.dataimport.TestSimplePropertiesWriter.testSimplePropertiesWriter Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([6C534269BEA6544D:E8960E51D1E53EF8]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:518) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:485) at org.apache.solr.handler.dataimport.TestSimplePropertiesWriter.testSimplePropertiesWriter(TestSimplePropertiesWriter.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//doc/str[@name="ayear_s"]="2012"
[jira] [Created] (SOLR-4247) Investigate TestSimplePropertiesWriter failure
James Dyer created SOLR-4247: Summary: Investigate TestSimplePropertiesWriter failure Key: SOLR-4247 URL: https://issues.apache.org/jira/browse/SOLR-4247 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 4.1 Reporter: James Dyer Assignee: James Dyer Fix For: 4.1, 5.0 TestSimplePropertiesWriter fails with this seed: B1D1027ED05EBE82:35144E46BF1DD437 -- 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
[JENKINS] Lucene-Solr-4.x-Windows ([[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }})
- Build # 2335 - Failure!
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_Part_0_1725780534.1356972720534"
X-Jenkins-Job: Lucene-Solr-4.x-Windows
X-Jenkins-Result: FAILURE
Precedence: bulk
--=_Part_0_1725780534.1356972720534
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/2335/
Java: [[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }}
No tests ran.
Build Log:
[...truncated 8952 lines...]
FATAL: hudson.remoting.RequestAbortedException: java.net.SocketException:
Connection reset
hudson.remoting.RequestAbortedException:
hudson.remoting.RequestAbortedException: java.net.SocketException: Connection
reset
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:672)
at
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158)
at $Proxy77.join(Unknown Source)
at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:915)
at hudson.Launcher$ProcStarter.join(Launcher.java:360)
at hudson.tasks.Ant.perform(Ant.java:217)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
at hudson.model.Run.execute(Run.java:1543)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: hudson.remoting.RequestAbortedException: java.net.SocketException:
Connection reset
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:732)
at
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at
java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2248)
at
java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2541)
at
java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2551)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at hudson.remoting.Command.readFrom(Command.java:92)
at
hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59)
at
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
--=_Part_0_1725780534.1356972720534--
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1176 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1176/ 1 tests failed. REGRESSION: org.apache.solr.handler.dataimport.TestSimplePropertiesWriter.testSimplePropertiesWriter Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([B1D1027ED05EBE82:35144E46BF1DD437]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:518) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:485) at org.apache.solr.handler.dataimport.TestSimplePropertiesWriter.testSimplePropertiesWriter(TestSimplePropertiesWriter.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:679) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//doc/str[@name="ayear_s"]="2012"
Improvement: Add commented-out /MLT handler to example solrconfig.xml
Solrconfig.xml has lots of great suggestions for various options that are commented out, which is fine. I did notice one useful feature that doesn’t even have a commented-out suggestion: the MoreLikeThis request handler. I suggest we add it. Does anybody know of any good reason why it isn’t there already? Or why it shouldn’t be added? And is there any significant downside to adding it as an active handler in the example solrconfig? I would simply note that since the mlt search component is already configured in Solr by default, most of the MLT code is already being loaded in Solr, so there should be no significant penalty. -- Jack Krupansky
[jira] [Updated] (SOLR-4231) Enhance extensibility of AbstractSpatialFieldType
[ https://issues.apache.org/jira/browse/SOLR-4231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-4231: --- Attachment: SOLR-4231_AbstractSpatialFieldType_extensibility.patch Updated patch to ensure a 400 error code occurs when a shape or SpatialArgs fails to parse. And I added a test for this. Perhaps that should be its own issue and of type bug but its minor. I also renamed "stringToShape" to "parseShape". I'll commit in a couple days or so. > Enhance extensibility of AbstractSpatialFieldType > - > > Key: SOLR-4231 > URL: https://issues.apache.org/jira/browse/SOLR-4231 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4231_AbstractSpatialFieldType_extensibility.patch, > SOLR-4231_AbstractSpatialFieldType_extensibility.patch > > > Just a few minor things to improve in AbstractSpatialField. (patch to follow) -- 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] [Commented] (SOLR-1972) Need additional query stats in admin interface - median, 95th and 99th percentile
[ https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541396#comment-13541396 ] Alan Woodward commented on SOLR-1972: - > Alan did try creating a registry for each handler. It caused OOM errors when > running Solr tests. See comments on 2012/10/26. Which, in retrospect, ought to have clued me in that something was wrong here... I think this is salvageable by having a MetricsRegistry per core, rather than per handler. This then allows the registry to be shut down/nulled out on Core shutdown. I'll try and work up a patch later today. FWIW, the latest version of Metrics removes the global registry entirely, presumably to stop idiots like me shooting themselves in the foot in this fashion. > Need additional query stats in admin interface - median, 95th and 99th > percentile > - > > Key: SOLR-1972 > URL: https://issues.apache.org/jira/browse/SOLR-1972 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 1.4 >Reporter: Shawn Heisey >Assignee: Alan Woodward >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, > elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, leak-closeable.patch, > leak.patch, revert-SOLR-1972.patch, SOLR-1972-branch3x-url_pattern.patch, > SOLR-1972-branch4x.patch, SOLR-1972-branch4x.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, solr1972-metricsregistry-branch4x-failure.log, > SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, > SOLR-1972-url_pattern.patch, stacktraces.tar.gz > > > I would like to see more detailed query statistics from the admin GUI. This > is what you can get now: > requests : 809 > errors : 0 > timeouts : 0 > totalTime : 70053 > avgTimePerRequest : 86.59209 > avgRequestsPerSecond : 0.8148785 > I'd like to see more data on the time per request - median, 95th percentile, > 99th percentile, and any other statistical function that makes sense to > include. In my environment, the first bunch of queries after startup tend to > take several seconds each. I find that the average value tends to be useless > until it has several thousand queries under its belt and the caches are > thoroughly warmed. The statistical functions I have mentioned would quickly > eliminate the influence of those initial slow queries. > The system will have to store individual data about each query. I don't know > if this is something Solr does already. It would be nice to have a > configurable count of how many of the most recent data points are kept, to > control the amount of memory the feature uses. The default value could be > something like 1024 or 4096. -- 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] [Commented] (SOLR-2463) Using an evaluator outside the scope of an entity results in a null context
[
https://issues.apache.org/jira/browse/SOLR-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541392#comment-13541392
]
James Dyer commented on SOLR-2463:
--
I wonder if this was fixed for SOLR 4.1 with SOLR-4086. Any chance someone can
test this?
> Using an evaluator outside the scope of an entity results in a null context
> ---
>
> Key: SOLR-2463
> URL: https://issues.apache.org/jira/browse/SOLR-2463
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 3.1.1, 3.5, 3.6, 4.0-ALPHA, 3.6.1
>Reporter: Robert Zotter
>Assignee: Shalin Shekhar Mangar
> Fix For: 3.1.1
>
>
> When using an Evaluator outside an entity element the Context argument is
> null.
> {code:title=foo.LowerCaseFunctionEvaluator.java|borderStyle=solid}
> public class LowerCaseFunctionEvaluator extends Evaluator {
> public String evaluate(String expression, Context context) {
>List l = EvaluatorBag.parseParams(expression,
> context.getVariableResolver());
>
>if (l.size() != 1) {
> throw new RuntimeException("'toLowerCase' must have only one parameter
> ");
>}
>return l.get(0).toString().toLowerCase();
> }
> }
> {code}
> {code:title=data-config.xml|borderStyle=solid}
> type="..."
> driver="..."
> url="..."
> user="${dataimporter.functions.toLowerCase('THIS_WILL_NOT_WORK')}"
> password="..."/>
> {code}
> {code:title=data-config.xml|borderStyle=solid}
> dataSource="..."
> query="select * from
> ${dataimporter.functions.toLowerCase('THIS_WILL_WORK')}"/>
> {code}
> This use case worked in 1.4
--
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] [Commented] (SOLR-2899) Custom DIH Functions in Delta-Query have null Context
[ https://issues.apache.org/jira/browse/SOLR-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541391#comment-13541391 ] James Dyer commented on SOLR-2899: -- Jens, I wonder if this was fixed for SOLR 4.1 with SOLR-4086. Any chance you can test this? > Custom DIH Functions in Delta-Query have null Context > - > > Key: SOLR-2899 > URL: https://issues.apache.org/jira/browse/SOLR-2899 > Project: Solr > Issue Type: Bug >Affects Versions: 3.4 >Reporter: Jens Zastrow > Labels: custom, dih, functions > > We must use a custom fucntion in the deltaQuery, but the passed in Context is > always null, preventing any variable resolution. > In full-import mode behavior is correct. > Looking into the sources showed that the Conext is used from a thread-local > Context.CURRENT_CONTEXT.get(), > wich is never set by (Context.CURRENT_CONTEXT.set()) for the Context created > in DocBuilder.java:871 -- 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] [Commented] (SOLR-4112) Dataimporting with SolrCloud Fails
[ https://issues.apache.org/jira/browse/SOLR-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541372#comment-13541372 ] Shalin Shekhar Mangar commented on SOLR-4112: - I can take this up and write some tests. Will make sure that it goes into 4.1 > Dataimporting with SolrCloud Fails > -- > > Key: SOLR-4112 > URL: https://issues.apache.org/jira/browse/SOLR-4112 > Project: Solr > Issue Type: Bug >Affects Versions: 5.0 >Reporter: Deniz Durmus >Assignee: James Dyer >Priority: Blocker > Fix For: 4.1, 5.0 > > Attachments: SOLR-4112.patch > > > While trying to import data from db on cloud, it shows this in logs: > SEVERE: Full Import > failed:org.apache.solr.handler.dataimport.DataImportHandlerException: Unable > to PropertyWriter implementation:ZKPropertiesWriter > at > org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:336) > > at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:418) > > at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:487) > at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:468) > Caused by: org.apache.solr.common.cloud.ZooKeeperException: > ZkSolrResourceLoader does not support getConfigDir() - likely, what you are > trying to do is not supported in ZooKeeper mode > at > org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:100) > > at > org.apache.solr.handler.dataimport.SimplePropertiesWriter.init(SimplePropertiesWriter.java:91) > > at > org.apache.solr.handler.dataimport.ZKPropertiesWriter.init(ZKPropertiesWriter.java:45) > > at > org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:334) > > ... 3 more > Exception in thread "Thread-306" java.lang.NullPointerException > at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:427) > > at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:487) > at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:468) -- 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] [Commented] (SOLR-4112) Dataimporting with SolrCloud Fails
[ https://issues.apache.org/jira/browse/SOLR-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541364#comment-13541364 ] Erick Erickson commented on SOLR-4112: -- I _really_ want to insure that this gets into 4.1, or explicitly decide not to as part of the release process... so moving back to blocker. If nothing else, we can commit w/o tests. Honest, I spent some time trying to make some tests, but between not knowing much about either ZK or DIH tests, I got pretty lost. > Dataimporting with SolrCloud Fails > -- > > Key: SOLR-4112 > URL: https://issues.apache.org/jira/browse/SOLR-4112 > Project: Solr > Issue Type: Bug >Affects Versions: 5.0 >Reporter: Deniz Durmus >Assignee: James Dyer >Priority: Blocker > Fix For: 4.1, 5.0 > > Attachments: SOLR-4112.patch > > > While trying to import data from db on cloud, it shows this in logs: > SEVERE: Full Import > failed:org.apache.solr.handler.dataimport.DataImportHandlerException: Unable > to PropertyWriter implementation:ZKPropertiesWriter > at > org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:336) > > at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:418) > > at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:487) > at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:468) > Caused by: org.apache.solr.common.cloud.ZooKeeperException: > ZkSolrResourceLoader does not support getConfigDir() - likely, what you are > trying to do is not supported in ZooKeeper mode > at > org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:100) > > at > org.apache.solr.handler.dataimport.SimplePropertiesWriter.init(SimplePropertiesWriter.java:91) > > at > org.apache.solr.handler.dataimport.ZKPropertiesWriter.init(ZKPropertiesWriter.java:45) > > at > org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:334) > > ... 3 more > Exception in thread "Thread-306" java.lang.NullPointerException > at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:427) > > at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:487) > at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:468) -- 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] [Updated] (SOLR-4112) Dataimporting with SolrCloud Fails
[ https://issues.apache.org/jira/browse/SOLR-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4112: - Priority: Blocker (was: Major) > Dataimporting with SolrCloud Fails > -- > > Key: SOLR-4112 > URL: https://issues.apache.org/jira/browse/SOLR-4112 > Project: Solr > Issue Type: Bug >Affects Versions: 5.0 >Reporter: Deniz Durmus >Assignee: James Dyer >Priority: Blocker > Fix For: 4.1, 5.0 > > Attachments: SOLR-4112.patch > > > While trying to import data from db on cloud, it shows this in logs: > SEVERE: Full Import > failed:org.apache.solr.handler.dataimport.DataImportHandlerException: Unable > to PropertyWriter implementation:ZKPropertiesWriter > at > org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:336) > > at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:418) > > at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:487) > at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:468) > Caused by: org.apache.solr.common.cloud.ZooKeeperException: > ZkSolrResourceLoader does not support getConfigDir() - likely, what you are > trying to do is not supported in ZooKeeper mode > at > org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:100) > > at > org.apache.solr.handler.dataimport.SimplePropertiesWriter.init(SimplePropertiesWriter.java:91) > > at > org.apache.solr.handler.dataimport.ZKPropertiesWriter.init(ZKPropertiesWriter.java:45) > > at > org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:334) > > ... 3 more > Exception in thread "Thread-306" java.lang.NullPointerException > at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:427) > > at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:487) > at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:468) -- 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
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_09) - Build # 3511 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/3511/ Java: 32bit/jdk1.7.0_09 -client -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.solr.handler.dataimport.TestSimplePropertiesWriter.testSimplePropertiesWriter Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([D155D448E61FE89D:55909870895C8228]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:518) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:485) at org.apache.solr.handler.dataimport.TestSimplePropertiesWriter.testSimplePropertiesWriter(TestSimplePropertiesWriter.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.RuntimeException: REQUEST FAILED:
[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor
[
https://issues.apache.org/jira/browse/SOLR-4205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541351#comment-13541351
]
Dawid Weiss commented on SOLR-4205:
---
I said it'd be difficult to make anything sensible under low-memory conditions,
didn't I? Even hotspot goes wild. Try it:
{code}
import java.util.LinkedList;
public class CodeOom {
static LinkedList ohMy = new LinkedList();
public void oomInCode() {
int stringLength = 1024 * 1024 * 5;
while (true) {
try {
ohMy.add(new byte [stringLength]);
} catch (OutOfMemoryError e) {
if (stringLength < 100) {
throw e;
} else {
stringLength /= 2;
}
}
}
}
public static void main(String[] args) {
try {
new CodeOom().oomInCode();
} catch (Throwable t) {
Runtime.getRuntime().halt(/* anything != 0, 1, etc. */ 5);
}
}
}
{code}
This should terminate with exit code 5. So it does, normally. But not when
there's no memory. See for yourself:
{code}
dweiss@ophelia:~/tmp$ java -cp . CodeOom; echo $?
1
{code}
> Clover runs on ASF Jenkins idle dead without a test or any thread running in
> main() loop waiting for file descriptor
>
>
> Key: SOLR-4205
> URL: https://issues.apache.org/jira/browse/SOLR-4205
> Project: Solr
> Issue Type: Bug
> Components: Tests
> Environment: FreeBSD Jenkins
>Reporter: Uwe Schindler
>Assignee: Dawid Weiss
>
> I had to kill ASF Jenkins Clover builds two times after several 10 hours of
> inactivity in a random Solr test. I requested a stack trace before killing
> the only running JVM (clover runs with one JVM only, because clover does not
> like multiple processes writing the same clover metrics file).
> In both cases (4.x and trunk) the stack trace was looking identical after
> sending kill -3...
> https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull
> (yesterday):
> {noformat}
> [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org):
> 2012-12-16T13:01:00, stalled for 28447s at:
> TestFunctionQuery.testBooleanFunctions
> [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org):
> 2012-12-16T13:02:00, stalled for 28507s at:
> TestFunctionQuery.testBooleanFunctions
> [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org):
> 2012-12-16T13:03:00, stalled for 28567s at:
> TestFunctionQuery.testBooleanFunctions
> [junit4:junit4] JVM J0: stdout was not empty, see:
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
> [junit4:junit4] >>> JVM J0: stdout (verbatim)
> [junit4:junit4] 2012-12-16 13:03:49
> [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed
> mode):
> [junit4:junit4]
> [junit4:junit4] "searcherExecutor-2577-thread-1" prio=5
> tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
> [junit4:junit4]java.lang.Thread.State: WAITING (parking)
> [junit4:junit4] at sun.misc.Unsafe.park(Native Method)
> [junit4:junit4] - parking to wait for <0x0008178c9c40> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> [junit4:junit4] at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> [junit4:junit4] at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> [junit4:junit4] at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
> [junit4:junit4] at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
> [junit4:junit4] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
> [junit4:junit4] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> [junit4:junit4] at java.lang.Thread.run(Thread.java:679)
> [junit4:junit4]
> [junit4:junit4] "RMI TCP Accept-0" daemon prio=5 tid=0x000840ce2800
> nid=0x61c0aa2 runnable [0x79496000]
> [junit4:junit4]java.lang.Thread.State: RUNNABLE
> [junit4:junit4] at java.net.PlainSocketImpl.socketAccept(Native Method)
> [junit4:junit4] at
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
> [junit4:junit4] at
> java.net.ServerSocket.implAccept(ServerSocket.java:470)
> [junit4:junit4] at java.net.ServerSocket.accept(ServerSocket.java:438)
> [junit4:junit4] at
> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
> [junit4:junit4] at
> sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
> [
[jira] [Resolved] (SOLR-982) Log based real-time replication with single master
[ https://issues.apache.org/jira/browse/SOLR-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-982. Resolution: Won't Fix Fix Version/s: (was: 4.2) (was: 5.0) Closing this issue because SolrCloud features have made it redundant. > Log based real-time replication with single master > -- > > Key: SOLR-982 > URL: https://issues.apache.org/jira/browse/SOLR-982 > Project: Solr > Issue Type: New Feature > Components: replication (java) >Reporter: Shalin Shekhar Mangar > > This issue aims to add a real-time log based replication. The goal is to have > the slave lag as less as possible after updates to the master by capturing > the update commands in master and re-playing them on slaves. This will also > pave the way for real-time search when Lucene adds those capabilities. -- 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] [Commented] (SOLR-1972) Need additional query stats in admin interface - median, 95th and 99th percentile
[ https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541317#comment-13541317 ] Alan Woodward commented on SOLR-1972: - Sorry, have been away from the internet for the past week. Thanks for reverting, Uwe! I'll try and catch up with the thread. > Need additional query stats in admin interface - median, 95th and 99th > percentile > - > > Key: SOLR-1972 > URL: https://issues.apache.org/jira/browse/SOLR-1972 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 1.4 >Reporter: Shawn Heisey >Assignee: Alan Woodward >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, > elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, leak-closeable.patch, > leak.patch, revert-SOLR-1972.patch, SOLR-1972-branch3x-url_pattern.patch, > SOLR-1972-branch4x.patch, SOLR-1972-branch4x.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, solr1972-metricsregistry-branch4x-failure.log, > SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, > SOLR-1972-url_pattern.patch, stacktraces.tar.gz > > > I would like to see more detailed query statistics from the admin GUI. This > is what you can get now: > requests : 809 > errors : 0 > timeouts : 0 > totalTime : 70053 > avgTimePerRequest : 86.59209 > avgRequestsPerSecond : 0.8148785 > I'd like to see more data on the time per request - median, 95th percentile, > 99th percentile, and any other statistical function that makes sense to > include. In my environment, the first bunch of queries after startup tend to > take several seconds each. I find that the average value tends to be useless > until it has several thousand queries under its belt and the caches are > thoroughly warmed. The statistical functions I have mentioned would quickly > eliminate the influence of those initial slow queries. > The system will have to store individual data about each query. I don't know > if this is something Solr does already. It would be nice to have a > configurable count of how many of the most recent data points are kept, to > control the amount of memory the feature uses. The default value could be > something like 1024 or 4096. -- 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
