[jira] [Updated] (LUCENE-6112) Compile error with FST package example code
[
https://issues.apache.org/jira/browse/LUCENE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-6112:
--
Attachment: LUCENE-6112.patch
Fix for FSTs package.html
> Compile error with FST package example code
> ---
>
> Key: LUCENE-6112
> URL: https://issues.apache.org/jira/browse/LUCENE-6112
> Project: Lucene - Core
> Issue Type: Task
> Components: core/FSTs
>Affects Versions: 4.10.2
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-6112.patch
>
>
> I run the FST construction example guided package.html with lucene 4.10, and
> found a compile error.
> http://lucene.apache.org/core/4_10_2/core/index.html?org/apache/lucene/util/fst/package-summary.html
> javac claimed as below.
> "FSTTest" is my test class, just copied from javadoc's example.
> {code}
> $ javac -cp /opt/lucene-4.10.2/core/lucene-core-4.10.2.jar FSTTest.java
> FSTTest.java:28: error: method toIntsRef in class Util cannot be applied to
> given types;
> builder.add(Util.toIntsRef(scratchBytes, scratchInts), outputValues[i]);
> ^
> required: BytesRef,IntsRefBuilder
> found: BytesRef,IntsRef
> reason: actual argument IntsRef cannot be converted to IntsRefBuilder by
> method invocation conversion
> Note: FSTTest.java uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> 1 error
> {code}
> I modified scratchInts variable type from IntsRef to IntsRefBuilder, it
> worked fine. (I checked o.a.l.u.fst.TestFSTs.java TestCase and my
> modification seems to be correct.)
> Util.toIntsRef() method takes IntsRefBuilder as 2nd argument instead of
> IntsRef since 4.10, so Javadocs also should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6112) Compile error with FST package example code
[
https://issues.apache.org/jira/browse/LUCENE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245844#comment-14245844
]
Tomoko Uchida edited comment on LUCENE-6112 at 12/14/14 6:37 AM:
-
I attached a fix for FSTs package.html
was (Author: tomoko uchida):
Fix for FSTs package.html
> Compile error with FST package example code
> ---
>
> Key: LUCENE-6112
> URL: https://issues.apache.org/jira/browse/LUCENE-6112
> Project: Lucene - Core
> Issue Type: Task
> Components: core/FSTs
>Affects Versions: 4.10.2
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-6112.patch
>
>
> I run the FST construction example guided package.html with lucene 4.10, and
> found a compile error.
> http://lucene.apache.org/core/4_10_2/core/index.html?org/apache/lucene/util/fst/package-summary.html
> javac claimed as below.
> "FSTTest" is my test class, just copied from javadoc's example.
> {code}
> $ javac -cp /opt/lucene-4.10.2/core/lucene-core-4.10.2.jar FSTTest.java
> FSTTest.java:28: error: method toIntsRef in class Util cannot be applied to
> given types;
> builder.add(Util.toIntsRef(scratchBytes, scratchInts), outputValues[i]);
> ^
> required: BytesRef,IntsRefBuilder
> found: BytesRef,IntsRef
> reason: actual argument IntsRef cannot be converted to IntsRefBuilder by
> method invocation conversion
> Note: FSTTest.java uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> 1 error
> {code}
> I modified scratchInts variable type from IntsRef to IntsRefBuilder, it
> worked fine. (I checked o.a.l.u.fst.TestFSTs.java TestCase and my
> modification seems to be correct.)
> Util.toIntsRef() method takes IntsRefBuilder as 2nd argument instead of
> IntsRef since 4.10, so Javadocs also should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6112) Compile error with FST package example code
Tomoko Uchida created LUCENE-6112:
-
Summary: Compile error with FST package example code
Key: LUCENE-6112
URL: https://issues.apache.org/jira/browse/LUCENE-6112
Project: Lucene - Core
Issue Type: Task
Components: core/FSTs
Affects Versions: 4.10.2
Reporter: Tomoko Uchida
Priority: Minor
I run the FST construction example guided package.html with lucene 4.10, and
found a compile error.
http://lucene.apache.org/core/4_10_2/core/index.html?org/apache/lucene/util/fst/package-summary.html
javac claimed as below.
"FSTTest" is my test class, just copied from javadoc's example.
{code}
$ javac -cp /opt/lucene-4.10.2/core/lucene-core-4.10.2.jar FSTTest.java
FSTTest.java:28: error: method toIntsRef in class Util cannot be applied to
given types;
builder.add(Util.toIntsRef(scratchBytes, scratchInts), outputValues[i]);
^
required: BytesRef,IntsRefBuilder
found: BytesRef,IntsRef
reason: actual argument IntsRef cannot be converted to IntsRefBuilder by
method invocation conversion
Note: FSTTest.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
{code}
I modified scratchInts variable type from IntsRef to IntsRefBuilder, it worked
fine. (I checked o.a.l.u.fst.TestFSTs.java TestCase and my modification seems
to be correct.)
Util.toIntsRef() method takes IntsRefBuilder as 2nd argument instead of IntsRef
since 4.10, so Javadocs also should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5735) Faceting for DateRangePrefixTree
[ https://issues.apache.org/jira/browse/LUCENE-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-5735: - Attachment: LUCENE-5735.patch Updated patch to sync with refactors recently committed, and a minor test bug. I think I may commit this to trunk soonish to get Jenkins beating on it... though [~ryantxu] I'd appreciate a look. > Faceting for DateRangePrefixTree > > > Key: LUCENE-5735 > URL: https://issues.apache.org/jira/browse/LUCENE-5735 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/spatial >Reporter: David Smiley >Assignee: David Smiley > Attachments: LUCENE-5735.patch, LUCENE-5735.patch > > > The newly added DateRangePrefixTree (DRPT) encodes terms in a fashion > amenable to faceting by meaningful time buckets. The motivation for this > feature is to efficiently populate a calendar bar chart or > [heat-map|http://bl.ocks.org/mbostock/4063318]. It's not hard if you have > date instances like many do but it's challenging for date ranges. > Internally this is going to iterate over the terms using seek/next with > TermsEnum as appropriate. It should be quite efficient; it won't need any > special caches. I should be able to re-use SPT traversal code in > AbstractVisitingPrefixTreeFilter. If this goes especially well; the > underlying implementation will be re-usable for geospatial heat-map faceting. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6827) DateRangeField: support facet.range, exclusive range, DateMath
[ https://issues.apache.org/jira/browse/SOLR-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-6827. Resolution: Fixed bq. Not sure about this one but perhaps the XML / javabin can return a date instead of a string if the value is a date instance and not a range. I think that has to wait until AbstractSpatialFieldType can be configured to be "pointsOnly" (and in the case of DateRangeField that signified no ranges, just date instances). Until then, I can't because if I get a range I can't express it as a Date. > DateRangeField: support facet.range, exclusive range, DateMath > -- > > Key: SOLR-6827 > URL: https://issues.apache.org/jira/browse/SOLR-6827 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley > Fix For: 5.0 > > Attachments: SOLR-6827.patch > > > DateRangeField can be made to be more compatible with TrieDateField: > * facet.range (thus faceting on date durations and date instances alike) > * exclusive range boundaries > * Solr DateMath syntax > ** stored value should have resolved DateMath > Not sure about this one but perhaps the XML / javabin can return a date > instead of a string if the value is a date instance and not a range. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6827) DateRangeField: support facet.range, exclusive range, DateMath
[ https://issues.apache.org/jira/browse/SOLR-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245818#comment-14245818 ] ASF subversion and git services commented on SOLR-6827: --- Commit 1645384 from [~dsmiley] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1645384 ] SOLR-6827: DateRangeField support for facet.range, exclusive ranges, DateMath > DateRangeField: support facet.range, exclusive range, DateMath > -- > > Key: SOLR-6827 > URL: https://issues.apache.org/jira/browse/SOLR-6827 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley > Fix For: 5.0 > > Attachments: SOLR-6827.patch > > > DateRangeField can be made to be more compatible with TrieDateField: > * facet.range (thus faceting on date durations and date instances alike) > * exclusive range boundaries > * Solr DateMath syntax > ** stored value should have resolved DateMath > Not sure about this one but perhaps the XML / javabin can return a date > instead of a string if the value is a date instance and not a range. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6827) DateRangeField: support facet.range, exclusive range, DateMath
[ https://issues.apache.org/jira/browse/SOLR-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245815#comment-14245815 ] ASF subversion and git services commented on SOLR-6827: --- Commit 1645383 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1645383 ] SOLR-6827: DateRangeField support for facet.range, exclusive ranges, DateMath > DateRangeField: support facet.range, exclusive range, DateMath > -- > > Key: SOLR-6827 > URL: https://issues.apache.org/jira/browse/SOLR-6827 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Assignee: David Smiley > Fix For: 5.0 > > Attachments: SOLR-6827.patch > > > DateRangeField can be made to be more compatible with TrieDateField: > * facet.range (thus faceting on date durations and date instances alike) > * exclusive range boundaries > * Solr DateMath syntax > ** stored value should have resolved DateMath > Not sure about this one but perhaps the XML / javabin can return a date > instead of a string if the value is a date instance and not a range. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5648) Index/search multi-valued time durations
[ https://issues.apache.org/jira/browse/LUCENE-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245812#comment-14245812 ] ASF subversion and git services commented on LUCENE-5648: - Commit 1645382 from [~dsmiley] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1645382 ] LUCENE-5648: spatial NumberRangePrefixTree refactorings, mostly: * rename NRPT.LevelledValue -> UnitNRShape, NRPT.NRShape -> SpanUnitsNRShape, both subclass new NRPT.NRShape marker class; make all 3 public and use these types in method signatures as appropriate. * remove NRPT pass-through convenience methods on NRPTStrategy (not needed; maintenance burden) * re-order some factory/parsing methods in NRPT to keep together at the top * UnitNRShape implements Comparable, and both NRShape implements Cloneable * improve randomized test to pick better random calendars * more docs > Index/search multi-valued time durations > > > Key: LUCENE-5648 > URL: https://issues.apache.org/jira/browse/LUCENE-5648 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/spatial >Reporter: David Smiley >Assignee: David Smiley > Fix For: 5.0, Trunk > > Attachments: LUCENE-5648.patch, LUCENE-5648.patch, LUCENE-5648.patch, > LUCENE-5648.patch > > > If you need to index a date/time duration, then the way to do that is to have > a pair of date fields; one for the start and one for the end -- pretty > straight-forward. But if you need to index a variable number of durations per > document, then the options aren't pretty, ranging from denormalization, to > joins, to using Lucene spatial with 2D as described > [here|http://wiki.apache.org/solr/SpatialForTimeDurations]. Ideally it would > be easier to index durations, and work in a more optimal way. > This issue implements the aforementioned feature using Lucene-spatial with a > new single-dimensional SpatialPrefixTree implementation. Unlike the other two > SPT implementations, it's not based on floating point numbers. It will have a > Date based customization that indexes levels at meaningful quantities like > seconds, minutes, hours, etc. The point of that alignment is to make it > faster to query across meaningful ranges (i.e. [2000 TO 2014]) and to enable > a follow-on issue to facet on the data in a really fast way. > I'll expect to have a working patch up this week. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5648) Index/search multi-valued time durations
[ https://issues.apache.org/jira/browse/LUCENE-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245810#comment-14245810 ] ASF subversion and git services commented on LUCENE-5648: - Commit 1645381 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1645381 ] LUCENE-5648: spatial NumberRangePrefixTree refactorings, mostly: * rename NRPT.LevelledValue -> UnitNRShape, NRPT.NRShape -> SpanUnitsNRShape, both subclass new NRPT.NRShape marker class; make all 3 public and use these types in method signatures as appropriate. * remove NRPT pass-through convenience methods on NRPTStrategy (not needed; maintenance burden) * re-order some factory/parsing methods in NRPT to keep together at the top * UnitNRShape implements Comparable, and both NRShape implements Cloneable * improve randomized test to pick better random calendars * more docs > Index/search multi-valued time durations > > > Key: LUCENE-5648 > URL: https://issues.apache.org/jira/browse/LUCENE-5648 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/spatial >Reporter: David Smiley >Assignee: David Smiley > Fix For: 5.0, Trunk > > Attachments: LUCENE-5648.patch, LUCENE-5648.patch, LUCENE-5648.patch, > LUCENE-5648.patch > > > If you need to index a date/time duration, then the way to do that is to have > a pair of date fields; one for the start and one for the end -- pretty > straight-forward. But if you need to index a variable number of durations per > document, then the options aren't pretty, ranging from denormalization, to > joins, to using Lucene spatial with 2D as described > [here|http://wiki.apache.org/solr/SpatialForTimeDurations]. Ideally it would > be easier to index durations, and work in a more optimal way. > This issue implements the aforementioned feature using Lucene-spatial with a > new single-dimensional SpatialPrefixTree implementation. Unlike the other two > SPT implementations, it's not based on floating point numbers. It will have a > Date based customization that indexes levels at meaningful quantities like > seconds, minutes, hours, etc. The point of that alignment is to make it > faster to query across meaningful ranges (i.e. [2000 TO 2014]) and to enable > a follow-on issue to facet on the data in a really fast way. > I'll expect to have a working patch up this week. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1949 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1949/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseSerialGC (asserts: true) 1 tests failed. FAILED: org.apache.solr.cloud.DeleteShardTest.testDistribSearch Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:57505 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:57505 at __randomizedtesting.SeedInfo.seed([24F4D509E214A07C:A5125B11954BC040]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:579) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.cloud.DeleteShardTest.deleteShard(DeleteShardTest.java:152) at org.apache.solr.cloud.DeleteShardTest.doTest(DeleteShardTest.java:94) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) 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.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:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org
[jira] [Comment Edited] (SOLR-6748) Additional resources to the site to help new Solr users ramp up quicker
[ https://issues.apache.org/jira/browse/SOLR-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245789#comment-14245789 ] Xavier Morera edited comment on SOLR-6748 at 12/14/14 3:16 AM: --- Hi [~steve_rowe], Thanks for your feedback. I will add it there. Two comments: - Even though the training is under a paid site, if you get a trial account you can actually watch the course for free so there is no obligation to pay. That's why I thought it would've been a good fit under Resources page. Also, I've spent hundreds of hours creating material to help non-proficient-in-search-devs get started, delivered it as an online training, then an in person training and now... - I also have a book coming up in the next month on the same subject, focusing on helping people get started with Solr quickly. This one will be 100% free. Being a book, can I come back and submit it to be added to the website with the others? Thanks also for your time to reply. Much appreciated. was (Author: xavier-morera): Hi [~steve_rowe], Thanks for your feedback. I will add it there. Two comments: - Even though the training is under a paid site, if you get a trial account you can actually watch the course for free so there is no obligation to pay. That's why I thought it would've been a good fit under Resources page. Also, I've spent hundreds of hours creating material to help non-proficient-in-search-devs get started, delivered it as an online training, then an in person training and now... - I also have a book coming up in the next month on the same subject, focusing on helping people get started with Solr quickly. This one will be 100% free. Being a book, can I come back and submit it to be added to the website with the others? Thanks also for your time to reply. Much appreciated. Who can I contact to get approved for the Wiki? > Additional resources to the site to help new Solr users ramp up quicker > --- > > Key: SOLR-6748 > URL: https://issues.apache.org/jira/browse/SOLR-6748 > Project: Solr > Issue Type: Sub-task > Components: documentation >Reporter: Xavier Morera > > I would like to request the addition of an online training I created for > Pluralsight called *Getting Started with Enterprise Search using Apache Solr* > in the following page: http://lucene.apache.org/solr/resources.html > It is not exactly a video only, it is an online training so no idea if it > should be added beneath videos or separately. > It aims to take a developer with absolutely no knowledge of Solr or even > search engines, to take them into being able to create a basic POC style > application with Solr in the backend. A few thousand people have watched it > and I have received very positive feedback on how it has helped people get > started very quickly and reduce the entry level barrier. > Is this possible? The url of the training is: > http://www.pluralsight.com/courses/table-of-contents/enterprise-search-using-apache-solr > I believe it will help a lot of people get started quicker. > Here is the full story of how this training came to be: > A while back I was a Solr total rookie, but I knew I needed it for one of my > projects. I had a little bit of a hard time getting started, but I did after > a lot of hard work and working with other pretty good Solr developers. > I then worked and created a system which is doing pretty good now. But I > decided that I wanted to create a resource that will help people with > absolutely no knowledge of Solr or search engines get started as quickly as > possible. And given that I am already a trainer/author at Pluralsight, who > focused mainly on Agile development, I thought this was the right place to > start helping others. > And so I did. I have received positive feedback, and given my background as a > trainer I have also given it as "Solr for the Uninitiated", also for people > with no previous knowledge of Solr. > It has also been received well to the extent that I have been hired to make > it into a book, which I am writing at the moment. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6748) Additional resources to the site to help new Solr users ramp up quicker
[ https://issues.apache.org/jira/browse/SOLR-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245789#comment-14245789 ] Xavier Morera edited comment on SOLR-6748 at 12/14/14 2:59 AM: --- Hi [~steve_rowe], Thanks for your feedback. I will add it there. Two comments: - Even though the training is under a paid site, if you get a trial account you can actually watch the course for free so there is no obligation to pay. That's why I thought it would've been a good fit under Resources page. Also, I've spent hundreds of hours creating material to help non-proficient-in-search-devs get started, delivered it as an online training, then an in person training and now... - I also have a book coming up in the next month on the same subject, focusing on helping people get started with Solr quickly. This one will be 100% free. Being a book, can I come back and submit it to be added to the website with the others? Thanks also for your time to reply. Much appreciated. Who can I contact to get approved for the Wiki? was (Author: xavier-morera): Hi [~steve_rowe], Thanks for your feedback. I will add it there. Two comments: - Even though the training is under a paid site, if you get a trial account you can actually watch the course for free so there is no obligation to pay. That's why I thought it would've been a good fit under Resources page. Also, I've spent hundreds of hours creating material to help non-proficient-in-search-devs get started, delivered it as an online training, then an in person training and now... - I also have a book coming up in the next month on the same subject, focusing on helping people get started with Solr quickly. This one will be 100% free. Being a book, can I come back and submit it to be added to the website with the others? Thanks also for your time to reply. Much appreciated. > Additional resources to the site to help new Solr users ramp up quicker > --- > > Key: SOLR-6748 > URL: https://issues.apache.org/jira/browse/SOLR-6748 > Project: Solr > Issue Type: Sub-task > Components: documentation >Reporter: Xavier Morera > > I would like to request the addition of an online training I created for > Pluralsight called *Getting Started with Enterprise Search using Apache Solr* > in the following page: http://lucene.apache.org/solr/resources.html > It is not exactly a video only, it is an online training so no idea if it > should be added beneath videos or separately. > It aims to take a developer with absolutely no knowledge of Solr or even > search engines, to take them into being able to create a basic POC style > application with Solr in the backend. A few thousand people have watched it > and I have received very positive feedback on how it has helped people get > started very quickly and reduce the entry level barrier. > Is this possible? The url of the training is: > http://www.pluralsight.com/courses/table-of-contents/enterprise-search-using-apache-solr > I believe it will help a lot of people get started quicker. > Here is the full story of how this training came to be: > A while back I was a Solr total rookie, but I knew I needed it for one of my > projects. I had a little bit of a hard time getting started, but I did after > a lot of hard work and working with other pretty good Solr developers. > I then worked and created a system which is doing pretty good now. But I > decided that I wanted to create a resource that will help people with > absolutely no knowledge of Solr or search engines get started as quickly as > possible. And given that I am already a trainer/author at Pluralsight, who > focused mainly on Agile development, I thought this was the right place to > start helping others. > And so I did. I have received positive feedback, and given my background as a > trainer I have also given it as "Solr for the Uninitiated", also for people > with no previous knowledge of Solr. > It has also been received well to the extent that I have been hired to make > it into a book, which I am writing at the moment. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245790#comment-14245790 ] Xavier Morera commented on SOLR-6058: - Thanks for the feedback. I will do as suggested in Solr-6748 > Solr needs a new website > > > Key: SOLR-6058 > URL: https://issues.apache.org/jira/browse/SOLR-6058 > Project: Solr > Issue Type: Task >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, > SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, > Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, > Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf > > > Solr needs a new website: better organization of content, less verbose, more > pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6748) Additional resources to the site to help new Solr users ramp up quicker
[ https://issues.apache.org/jira/browse/SOLR-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245789#comment-14245789 ] Xavier Morera commented on SOLR-6748: - Hi [~steve_rowe], Thanks for your feedback. I will add it there. Two comments: - Even though the training is under a paid site, if you get a trial account you can actually watch the course for free so there is no obligation to pay. That's why I thought it would've been a good fit under Resources page. Also, I've spent hundreds of hours creating material to help non-proficient-in-search-devs get started, delivered it as an online training, then an in person training and now... - I also have a book coming up in the next month on the same subject, focusing on helping people get started with Solr quickly. This one will be 100% free. Being a book, can I come back and submit it to be added to the website with the others? Thanks also for your time to reply. Much appreciated. > Additional resources to the site to help new Solr users ramp up quicker > --- > > Key: SOLR-6748 > URL: https://issues.apache.org/jira/browse/SOLR-6748 > Project: Solr > Issue Type: Sub-task > Components: documentation >Reporter: Xavier Morera > > I would like to request the addition of an online training I created for > Pluralsight called *Getting Started with Enterprise Search using Apache Solr* > in the following page: http://lucene.apache.org/solr/resources.html > It is not exactly a video only, it is an online training so no idea if it > should be added beneath videos or separately. > It aims to take a developer with absolutely no knowledge of Solr or even > search engines, to take them into being able to create a basic POC style > application with Solr in the backend. A few thousand people have watched it > and I have received very positive feedback on how it has helped people get > started very quickly and reduce the entry level barrier. > Is this possible? The url of the training is: > http://www.pluralsight.com/courses/table-of-contents/enterprise-search-using-apache-solr > I believe it will help a lot of people get started quicker. > Here is the full story of how this training came to be: > A while back I was a Solr total rookie, but I knew I needed it for one of my > projects. I had a little bit of a hard time getting started, but I did after > a lot of hard work and working with other pretty good Solr developers. > I then worked and created a system which is doing pretty good now. But I > decided that I wanted to create a resource that will help people with > absolutely no knowledge of Solr or search engines get started as quickly as > possible. And given that I am already a trainer/author at Pluralsight, who > focused mainly on Agile development, I thought this was the right place to > start helping others. > And so I did. I have received positive feedback, and given my background as a > trainer I have also given it as "Solr for the Uninitiated", also for people > with no previous knowledge of Solr. > It has also been received well to the extent that I have been hired to make > it into a book, which I am writing at the moment. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6833) bin/solr -e foo should not use server/solr as the SOLR_HOME
[
https://issues.apache.org/jira/browse/SOLR-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245764#comment-14245764
]
Alexandre Rafalovitch commented on SOLR-6833:
-
I found a cool command I did not see while reading the documentation before
{{solr -i/-info}}. It's mentioned in passing in {{solr stop -help}} but could
be nice to be mentioned in top-level help as well. It's very useful to check
what's running.
> bin/solr -e foo should not use server/solr as the SOLR_HOME
> ---
>
> Key: SOLR-6833
> URL: https://issues.apache.org/jira/browse/SOLR-6833
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Timothy Potter
> Fix For: 5.0
>
> Attachments: SOLR-6833.patch
>
>
> i think it's weird right now that running bin/solr with the "-e" (example)
> option causes it to create example solr instances inside the server directory.
> i think that's fine for running solr "normally" (ie: "start") but if you use
> "-e" that seems like the solr.solr.home for those example should instead be
> created under $SOLR_TIP/example.
> I would even go so far as to suggest that the *log* files created should live
> in that directory as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6666) Dynamic copy fields are considering all dynamic fields, causing a significant performance impact on indexing documents
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245754#comment-14245754
]
Erick Erickson commented on SOLR-:
--
The problem here is that if you add this copyField directive to schema.xml
the schema won't load with the patch. It fails with a message
about the source field needing an asterisk if the destination
has one. Other tests have this pattern and fail BTW, see:
TestFieldCollectionResource, TestManagedSotpFilterFactory
and TestManagedSynonymFileFactory.
The fail_dynamic field "fulfills" this requirement since it is actually a
match for "*_dynamic"
So are you saying that if you have
and a copyField of
that bogus logic happens because
it matches a dynamic field?
Or are your source fields "explicit", but only really instantiated by matching
a
dynamic field so there's no corresponding definition?
If it's the former, then it seems that doing a test way up top similar to this:
if (destSchemaField != null && sourceSchemaField != null) { // Source and
destination are explicit
List copyFieldList = copyFieldsMap.get(source);
if (copyFieldList == null) {
copyFieldList = new ArrayList<>();
copyFieldsMap.put(source, copyFieldList);
}
copyFieldList.add(new CopyField(sourceSchemaField, destSchemaField,
maxChars));
incrementCopyFieldTargetCount(destSchemaField);
return;
}
(and maybe taking this out from the end of the method?) would catch your case.
It's certainly an open question whether this is the way it "should" be of
course. I don't
quite know if there are shortcuts we could take that would satisfy both
situations, i.e.
shortcut non-asterisk source fields in copyField directives that happen to be
instantiations
of dynamic fields while still respecting all the ways a field could get into
the "explicit" field
("fail_dynamic" above).
It's also possible that the test that blows up above is too restrictive, I'm
not prepared
to say one way or another. But I can't commit this without getting a resolution
to that question.
Under any circumstances, it seems that beefing up the IndexSchemaTest would be
a good thing,
on a quick look they aren't all that comprehensive.
> Dynamic copy fields are considering all dynamic fields, causing a significant
> performance impact on indexing documents
> --
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis, update
> Environment: Linux, Solr 4.8, Schema with 70 fields and more than 500
> specific CopyFields for dynamic fields, but without wildcards (the fields are
> dynamic, the copy directive is not)
>Reporter: Liram Vardi
>Assignee: Erick Erickson
> Attachments: SOLR-.patch
>
>
> Result:
> After applying a fix for this issue, tests which we conducted show more than
> 40 percent improvement on our insertion performance.
> Explanation:
> Using JVM profiler, we found a CPU "bottleneck" during Solr indexing process.
> This bottleneck can be found at org.apache.solr.schema.IndexSchema, in the
> following method, "getCopyFieldsList()":
> {code:title=getCopyFieldsList() |borderStyle=solid}
> final List result = new ArrayList<>();
> for (DynamicCopy dynamicCopy : dynamicCopyFields) {
> if (dynamicCopy.matches(sourceField)) {
> result.add(new CopyField(getField(sourceField),
> dynamicCopy.getTargetField(sourceField), dynamicCopy.maxChars));
> }
> }
> List fixedCopyFields = copyFieldsMap.get(sourceField);
> if (null != fixedCopyFields) {
> result.addAll(fixedCopyFields);
> }
> {code}
> This function tries to find for an input source field all its copyFields (All
> its destinations which Solr need to move this field).
> As you can probably note, the first part of the procedure is the procedure
> most “expensive” step (takes O( n ) time while N is the size of the
> "dynamicCopyFields" group).
> The next part is just a simple "hash" extraction, which takes O(1) time.
> Our schema contains over then 500 copyFields but only 70 of then are
> "indexed" fields.
> We also have one dynamic field with a wildcard ( * ), which "catches" the
> rest of the document fields.
> As you can conclude, we have more than 400 copyFields that are based on this
> dynamicField but all, except one, are fixed (i.e. does not contain any
> wildcard).
> From some reason, the copyFields registration procedure defines those 400
> fields as "DynamicCopyField " and then store them in the “dynamicCopyFields”
> array,
> This step makes getCopyFieldsList() very expensive (in CPU terms) without any
> justification: All of th
[jira] [Resolved] (SOLR-6826) fieldType capitalization is not consistent with the rest of case-sensitive field names
[ https://issues.apache.org/jira/browse/SOLR-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-6826. -- Resolution: Fixed Thanks Alexandre! > fieldType capitalization is not consistent with the rest of case-sensitive > field names > -- > > Key: SOLR-6826 > URL: https://issues.apache.org/jira/browse/SOLR-6826 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 5.0 >Reporter: Alexandre Rafalovitch >Assignee: Erick Erickson >Priority: Minor > Labels: beginners, usability > Attachments: SOLR-6826.patch, SOLR-6826.patch > > > For legacy reasons, both fieldtype and fieldType are acceptable in > schema.xml. However, XML is case sensitive and this causes confusion when > people see both fieldtype and fieldType used in official examples. > This causes them to assume that maybe our particular XML is not case > sensitive and then they mis-case other elements, such as dynamicField, which > are then silently ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6826) fieldType capitalization is not consistent with the rest of case-sensitive field names
[ https://issues.apache.org/jira/browse/SOLR-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245750#comment-14245750 ] ASF subversion and git services commented on SOLR-6826: --- Commit 1645373 from [~erickoerickson] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1645373 ] SOLR-6826: fieldType capitalization is not consistent with the rest of case-sensitive field names > fieldType capitalization is not consistent with the rest of case-sensitive > field names > -- > > Key: SOLR-6826 > URL: https://issues.apache.org/jira/browse/SOLR-6826 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 5.0 >Reporter: Alexandre Rafalovitch >Assignee: Erick Erickson >Priority: Minor > Labels: beginners, usability > Attachments: SOLR-6826.patch, SOLR-6826.patch > > > For legacy reasons, both fieldtype and fieldType are acceptable in > schema.xml. However, XML is case sensitive and this causes confusion when > people see both fieldtype and fieldType used in official examples. > This causes them to assume that maybe our particular XML is not case > sensitive and then they mis-case other elements, such as dynamicField, which > are then silently ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6832) Queries be served locally rather than being forwarded to another replica
[ https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245667#comment-14245667 ] Shawn Heisey commented on SOLR-6832: we might even be able to shorten the parameter name to preferLocal, but that will require some further thought. I'd hate to have the shorter version be in use when another preferLocalXXX requirement comes up. > Queries be served locally rather than being forwarded to another replica > > > Key: SOLR-6832 > URL: https://issues.apache.org/jira/browse/SOLR-6832 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.10.2 >Reporter: Sachin Goyal > > Currently, I see that code flow for a query in SolrCloud is as follows: > For distributed query: > SolrCore -> SearchHandler.handleRequestBody() -> HttpShardHandler.submit() > For non-distributed query: > SolrCore -> SearchHandler.handleRequestBody() -> QueryComponent.process() > \\ > \\ > \\ > For a distributed query, the request is always sent to all the shards even if > the originating SolrCore (handling the original distributed query) is a > replica of one of the shards. > If the original Solr-Core can check itself before sending http requests for > any shard, we can probably save some network hopping and gain some > performance. > \\ > \\ > We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit() > to fix this behavior (most likely the former and not the latter). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6832) Queries be served locally rather than being forwarded to another replica
[ https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245665#comment-14245665 ] Shawn Heisey commented on SOLR-6832: CloudSolrServer does load balance, so you do not need an external load balancer. Internally, it uses changes in the zookeeper clusterstate to add and remove URLs on an instance of LBHttpSolrServer, which in turn uses HttpSolrServer for each of those URLs. https://lucene.apache.org/solr/4_10_2/solr-solrj/org/apache/solr/client/solrj/impl/LBHttpSolrServer.html The name preferLocalShards is perfect ... and I think a good case can be made for CloudSolrServer using this for queries (probably via a query URL parameter) by default. > Queries be served locally rather than being forwarded to another replica > > > Key: SOLR-6832 > URL: https://issues.apache.org/jira/browse/SOLR-6832 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.10.2 >Reporter: Sachin Goyal > > Currently, I see that code flow for a query in SolrCloud is as follows: > For distributed query: > SolrCore -> SearchHandler.handleRequestBody() -> HttpShardHandler.submit() > For non-distributed query: > SolrCore -> SearchHandler.handleRequestBody() -> QueryComponent.process() > \\ > \\ > \\ > For a distributed query, the request is always sent to all the shards even if > the originating SolrCore (handling the original distributed query) is a > replica of one of the shards. > If the original Solr-Core can check itself before sending http requests for > any shard, we can probably save some network hopping and gain some > performance. > \\ > \\ > We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit() > to fix this behavior (most likely the former and not the latter). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6832) Queries be served locally rather than being forwarded to another replica
[ https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245587#comment-14245587 ] Ayon Sinha commented on SOLR-6832: -- Our clients actually do use CloudSolrServer (LB SolrJ client). Is there something we should be worrying about there? We are under the impression that the Zk aware CloudSolrServer is doing a round-robin load balancing sending query requests. We only intend to 'preferLocalShards' on the Solr node side only. BTW, how is the name 'preferLocalShards' ? > Queries be served locally rather than being forwarded to another replica > > > Key: SOLR-6832 > URL: https://issues.apache.org/jira/browse/SOLR-6832 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.10.2 >Reporter: Sachin Goyal > > Currently, I see that code flow for a query in SolrCloud is as follows: > For distributed query: > SolrCore -> SearchHandler.handleRequestBody() -> HttpShardHandler.submit() > For non-distributed query: > SolrCore -> SearchHandler.handleRequestBody() -> QueryComponent.process() > \\ > \\ > \\ > For a distributed query, the request is always sent to all the shards even if > the originating SolrCore (handling the original distributed query) is a > replica of one of the shards. > If the original Solr-Core can check itself before sending http requests for > any shard, we can probably save some network hopping and gain some > performance. > \\ > \\ > We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit() > to fix this behavior (most likely the former and not the latter). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2324 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2324/ 1 tests failed. FAILED: org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability Error Message: No live SolrServers available to handle this request Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request at __randomizedtesting.SeedInfo.seed([174F5484CF53E770:D68789C26E3536D9]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:539) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability(TestLBHttpSolrServer.java:223) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) 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.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:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365)
[jira] [Commented] (SOLR-6832) Queries be served locally rather than being forwarded to another replica
[ https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245538#comment-14245538 ] Shawn Heisey commented on SOLR-6832: That sounds like a perfect use-case for this option. In your setup, you have an external load balancer and are not relying on SolrCloud itself or the zookeeper-aware Java client (CloudSolrServer) to do the load balancing for you. For an environment like that, letting SolrCloud forward the request adds a completely unnecessary network hop, along with new Java objects and subsequent garbage that must be collected. This is why I said I didn't want to derail the work. If you have a solution, we should try to get it to a state where it can be committed. It is very clear that it will be an immense help for many users. I just don't want it to become the default. Trying to come up with a useful and descriptive option name that's not horribly long ... that's a challenge. :) Something like handleRequestsLocally may be too generic, but it's a lot shorter than handleShardRequestsLocallyIfPossible! > Queries be served locally rather than being forwarded to another replica > > > Key: SOLR-6832 > URL: https://issues.apache.org/jira/browse/SOLR-6832 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.10.2 >Reporter: Sachin Goyal > > Currently, I see that code flow for a query in SolrCloud is as follows: > For distributed query: > SolrCore -> SearchHandler.handleRequestBody() -> HttpShardHandler.submit() > For non-distributed query: > SolrCore -> SearchHandler.handleRequestBody() -> QueryComponent.process() > \\ > \\ > \\ > For a distributed query, the request is always sent to all the shards even if > the originating SolrCore (handling the original distributed query) is a > replica of one of the shards. > If the original Solr-Core can check itself before sending http requests for > any shard, we can probably save some network hopping and gain some > performance. > \\ > \\ > We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit() > to fix this behavior (most likely the former and not the latter). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6826) fieldType capitalization is not consistent with the rest of case-sensitive field names
[ https://issues.apache.org/jira/browse/SOLR-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-6826: - Attachment: SOLR-6826.patch Alexandre's patch with CHANGES.txt attribution. > fieldType capitalization is not consistent with the rest of case-sensitive > field names > -- > > Key: SOLR-6826 > URL: https://issues.apache.org/jira/browse/SOLR-6826 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 5.0 >Reporter: Alexandre Rafalovitch >Assignee: Erick Erickson >Priority: Minor > Labels: beginners, usability > Attachments: SOLR-6826.patch, SOLR-6826.patch > > > For legacy reasons, both fieldtype and fieldType are acceptable in > schema.xml. However, XML is case sensitive and this causes confusion when > people see both fieldtype and fieldType used in official examples. > This causes them to assume that maybe our particular XML is not case > sensitive and then they mis-case other elements, such as dynamicField, which > are then silently ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6826) fieldType capitalization is not consistent with the rest of case-sensitive field names
[ https://issues.apache.org/jira/browse/SOLR-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245531#comment-14245531 ] ASF subversion and git services commented on SOLR-6826: --- Commit 1645349 from [~erickoerickson] in branch 'dev/trunk' [ https://svn.apache.org/r1645349 ] SOLR-6826: fieldType capitalization is not consistent with the rest of case-sensitive field names > fieldType capitalization is not consistent with the rest of case-sensitive > field names > -- > > Key: SOLR-6826 > URL: https://issues.apache.org/jira/browse/SOLR-6826 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 5.0 >Reporter: Alexandre Rafalovitch >Assignee: Erick Erickson >Priority: Minor > Labels: beginners, usability > Attachments: SOLR-6826.patch, SOLR-6826.patch > > > For legacy reasons, both fieldtype and fieldType are acceptable in > schema.xml. However, XML is case sensitive and this causes confusion when > people see both fieldtype and fieldType used in official examples. > This causes them to assume that maybe our particular XML is not case > sensitive and then they mis-case other elements, such as dynamicField, which > are then silently ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 702 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/702/ 1 tests failed. FAILED: org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability Error Message: No live SolrServers available to handle this request Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request at __randomizedtesting.SeedInfo.seed([C60998D44C24893C:7C14592ED425895]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:539) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability(TestLBHttpSolrServer.java:223) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) 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.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:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365)
[jira] [Commented] (SOLR-6252) A couple of small improvements to UnInvertedField class.
[ https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245503#comment-14245503 ] Mark Miller commented on SOLR-6252: --- Thanks Avishai. Since this is a released issue, do you mind filing a new bug and attaching your patch? We can link that issue to this one. > A couple of small improvements to UnInvertedField class. > > > Key: SOLR-6252 > URL: https://issues.apache.org/jira/browse/SOLR-6252 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: Trunk >Reporter: Vamsee Yarlagadda >Assignee: Mark Miller >Priority: Minor > Fix For: 4.10, Trunk > > Attachments: SOLR-6252-v3.patch, SOLR-6252.patch, SOLR-6252v2.patch, > solr-uninvertedfield-cache.patch > > > Looks like UnInvertedField#getUnInvertedField has implemented a bit > additional synchronization module rather than what is required, and thereby > increasing the complexity. > https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 > As pointed out in the above link, as the synchronization is performed on the > cache variable(which itself will protect the threads from obtaining access to > the cache), we can safely remove all the placeholder flags. As long as > cache.get() is in synchronized block, we can simply populate the cache with > new entries and other threads will be able to see the changes. > This change has been introduced in > https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6252) A couple of small improvements to UnInvertedField class.
[ https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avishai Ish-Shalom updated SOLR-6252: - Attachment: solr-uninvertedfield-cache.patch A patch using a single synchronized block and no .wait() calls. should be free of deadlocks. > A couple of small improvements to UnInvertedField class. > > > Key: SOLR-6252 > URL: https://issues.apache.org/jira/browse/SOLR-6252 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: Trunk >Reporter: Vamsee Yarlagadda >Assignee: Mark Miller >Priority: Minor > Fix For: 4.10, Trunk > > Attachments: SOLR-6252-v3.patch, SOLR-6252.patch, SOLR-6252v2.patch, > solr-uninvertedfield-cache.patch > > > Looks like UnInvertedField#getUnInvertedField has implemented a bit > additional synchronization module rather than what is required, and thereby > increasing the complexity. > https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 > As pointed out in the above link, as the synchronization is performed on the > cache variable(which itself will protect the threads from obtaining access to > the cache), we can safely remove all the placeholder flags. As long as > cache.get() is in synchronized block, we can simply populate the cache with > new entries and other threads will be able to see the changes. > This change has been introduced in > https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6252) A couple of small improvements to UnInvertedField class.
[
https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245473#comment-14245473
]
Avishai Ish-Shalom commented on SOLR-6252:
--
The new code is still vulnerable to deadlock: if a call gets to the 2nd
synchronized block and blocks on {{cache.wait()}} then it will never be
released since {{cache.notifyAll()}} is also inside a synchronized block of the
same monitor object.
> A couple of small improvements to UnInvertedField class.
>
>
> Key: SOLR-6252
> URL: https://issues.apache.org/jira/browse/SOLR-6252
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: Trunk
>Reporter: Vamsee Yarlagadda
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.10, Trunk
>
> Attachments: SOLR-6252-v3.patch, SOLR-6252.patch, SOLR-6252v2.patch
>
>
> Looks like UnInvertedField#getUnInvertedField has implemented a bit
> additional synchronization module rather than what is required, and thereby
> increasing the complexity.
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667
> As pointed out in the above link, as the synchronization is performed on the
> cache variable(which itself will protect the threads from obtaining access to
> the cache), we can safely remove all the placeholder flags. As long as
> cache.get() is in synchronized block, we can simply populate the cache with
> new entries and other threads will be able to see the changes.
> This change has been introduced in
> https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2323 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2323/ 1 tests failed. REGRESSION: org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds Error Message: soft529 wasn't fast enough Stack Trace: java.lang.AssertionError: soft529 wasn't fast enough at __randomizedtesting.SeedInfo.seed([F772DD44458DAE07:A6A624C4F4FE9EA0]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds(SoftAutoCommitTest.java:111) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) 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.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:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 8869 lines...] [junit4] Suite: org.apache.solr.update.SoftAutoCommitTes
[JENKINS-MAVEN] Lucene-Solr-Maven-5.x #786: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/786/ 4 tests failed. FAILED: org.apache.solr.hadoop.MapReduceIndexerToolArgumentParserTest.org.apache.solr.hadoop.MapReduceIndexerToolArgumentParserTest Error Message: null Stack Trace: java.lang.AssertionError: null at __randomizedtesting.SeedInfo.seed([CB01E23A4368E92B]:0) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.before(TestRuleTemporaryFilesCleanup.java:105) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.before(TestRuleAdapter.java:26) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:35) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745) REGRESSION: org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.testDistribSearch Error Message: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://127.0.0.1:12203/collection1 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://127.0.0.1:12203/collection1 at __randomizedtesting.SeedInfo.seed([8364E20280D836F5:2826C1AF78756C9]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:569) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.doTest(MorphlineGoLiveMiniMRTest.java:410) FAILED: org.apache.solr.hadoop.MorphlineBasicMiniMRTest.testPathParts Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([6D0F1AA9C71759FE]:0) FAILED: org.apache.solr.hadoop.MorphlineBasicMiniMRTest.org.apache.solr.hadoop.MorphlineBasicMiniMRTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([6D0F1AA9C71759FE]:0) Build Log: [...truncated 53779 lines...] BUILD FAILED /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:552: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:204: The following error occurred while executing this line: : Java returned: 1 Total time: 383 minutes 47 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6559) Create an endpoint /update/xml/docs endpoint to do custom xml indexing
[ https://issues.apache.org/jira/browse/SOLR-6559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245252#comment-14245252 ] Anurag Sharma edited comment on SOLR-6559 at 12/13/14 2:53 PM: --- Can you review the patch for merge if srcField is not required, Also, would like to know why srcField is not required, is there another api to store raw data? was (Author: anuragsharma): Can you review the patch for merge if srcField is not required, > Create an endpoint /update/xml/docs endpoint to do custom xml indexing > -- > > Key: SOLR-6559 > URL: https://issues.apache.org/jira/browse/SOLR-6559 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-6559.patch, SOLR-6559.patch, SOLR-6559.patch > > > Just the way we have an json end point create an xml end point too. use the > XPathRecordReader in DIH to do the same . The syntax would require slight > tweaking to match the params of /update/json/docs -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 1992 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1992/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC (asserts: true) 1 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.testDistribSearch Error Message: Should have had a good message here Stack Trace: java.lang.AssertionError: Should have had a good message here at __randomizedtesting.SeedInfo.seed([D2DD35915246F37B:533BBB8925199347]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:138) at org.apache.solr.cloud.DeleteReplicaTest.doTest(DeleteReplicaTest.java:89) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) 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.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:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745)
[jira] [Commented] (SOLR-6810) Faster searching limited but high rows across many shards all with many hits
[ https://issues.apache.org/jira/browse/SOLR-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245266#comment-14245266 ] Per Steffensen commented on SOLR-6810: -- Thanks for taking care of SOLR-6795, SOLR-6796 and SOLR-6812 (and SOLR-6813), [~shalinmangar]!!! > Faster searching limited but high rows across many shards all with many hits > > > Key: SOLR-6810 > URL: https://issues.apache.org/jira/browse/SOLR-6810 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Per Steffensen >Assignee: Shalin Shekhar Mangar > Labels: distributed_search, performance > Attachments: branch_5x_rev1642874.patch, branch_5x_rev1642874.patch > > > Searching "limited but high rows across many shards all with many hits" is > slow > E.g. > * Query from outside client: q=something&rows=1000 > * Resulting in sub-requests to each shard something a-la this > ** 1) q=something&rows=1000&fl=id,score > ** 2) Request the full documents with ids in the global-top-1000 found among > the top-1000 from each shard > What does the subject mean > * "limited but high rows" means 1000 in the example above > * "many shards" means 200-1000 in our case > * "all with many hits" means that each of the shards have a significant > number of hits on the query > The problem grows on all three factors above > Doing such a query on our system takes between 5 min to 1 hour - depending on > a lot of things. It ought to be much faster, so lets make it. > Profiling show that the problem is that it takes lots of time to access the > store to get id’s for (up to) 1000 docs (value of rows parameter) per shard. > Having 1000 shards its up to 1 mio ids that has to be fetched. There is > really no good reason to ever read information from store for more than the > overall top-1000 documents, that has to be returned to the client. > For further detail see mail-thread "Slow searching limited but high rows > across many shards all with high hits" started 13/11-2014 on > dev@lucene.apache.org -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6810) Faster searching limited but high rows across many shards all with many hits
[ https://issues.apache.org/jira/browse/SOLR-6810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245264#comment-14245264 ] Per Steffensen commented on SOLR-6810: -- Now that SOLR-6812 has been solved (in a different way than I suggested), my solution to SOLR-6812 should be removed from the patch. > Faster searching limited but high rows across many shards all with many hits > > > Key: SOLR-6810 > URL: https://issues.apache.org/jira/browse/SOLR-6810 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Per Steffensen >Assignee: Shalin Shekhar Mangar > Labels: distributed_search, performance > Attachments: branch_5x_rev1642874.patch, branch_5x_rev1642874.patch > > > Searching "limited but high rows across many shards all with many hits" is > slow > E.g. > * Query from outside client: q=something&rows=1000 > * Resulting in sub-requests to each shard something a-la this > ** 1) q=something&rows=1000&fl=id,score > ** 2) Request the full documents with ids in the global-top-1000 found among > the top-1000 from each shard > What does the subject mean > * "limited but high rows" means 1000 in the example above > * "many shards" means 200-1000 in our case > * "all with many hits" means that each of the shards have a significant > number of hits on the query > The problem grows on all three factors above > Doing such a query on our system takes between 5 min to 1 hour - depending on > a lot of things. It ought to be much faster, so lets make it. > Profiling show that the problem is that it takes lots of time to access the > store to get id’s for (up to) 1000 docs (value of rows parameter) per shard. > Having 1000 shards its up to 1 mio ids that has to be fetched. There is > really no good reason to ever read information from store for more than the > overall top-1000 documents, that has to be returned to the client. > For further detail see mail-thread "Slow searching limited but high rows > across many shards all with high hits" started 13/11-2014 on > dev@lucene.apache.org -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6845) figure out why suggester causes slow startup - even when not used
[
https://issues.apache.org/jira/browse/SOLR-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245257#comment-14245257
]
Varun Thacker commented on SOLR-6845:
-
Excerpt from the logs -
{code}
16160 [coreLoadExecutor-5-thread-2] INFO
org.apache.solr.handler.component.SpellCheckComponent – Initializing spell
checkers
16161 [coreLoadExecutor-5-thread-2] INFO
org.apache.solr.spelling.DirectSolrSpellChecker – init:
{name=default,field=text,classname=solr.DirectSolrSpellChecker,distanceMeasure=internal,accuracy=0.5,maxEdits=2,minPrefix=1,maxInspections=5,minQueryLength=4,maxQueryFrequency=0.01}
16162 [coreLoadExecutor-5-thread-2] INFO
org.apache.solr.handler.component.SpellCheckComponent – No queryConverter
defined, using default converter
16164 [coreLoadExecutor-5-thread-2] INFO
org.apache.solr.handler.component.SuggestComponent – Initializing
SuggestComponent
16164 [coreLoadExecutor-5-thread-2] INFO
org.apache.solr.spelling.suggest.SolrSuggester – init:
{name=mySuggester,lookupImpl=FuzzyLookupFactory,dictionaryImpl=DocumentDictionaryFactory,field=cat,weightField=price,suggestAnalyzerFieldType=string}
16164 [coreLoadExecutor-5-thread-2] INFO
org.apache.solr.spelling.suggest.SolrSuggester – Dictionary loaded with
params:
{name=mySuggester,lookupImpl=FuzzyLookupFactory,dictionaryImpl=DocumentDictionaryFactory,field=cat,weightField=price,suggestAnalyzerFieldType=string}
16164 [coreLoadExecutor-5-thread-2] INFO
org.apache.solr.common.cloud.ZkStateReader – Load collection config
from:/collections/solr6606
16166 [coreLoadExecutor-5-thread-2] INFO
org.apache.solr.common.cloud.ZkStateReader – path=/collections/solr6606
configName=solr6606 specified config exists in ZooKeeper
16186 [coreLoadExecutor-5-thread-2] INFO
org.apache.solr.handler.ReplicationHandler – Commits will be reserved for
1
16187 [searcherExecutor-6-thread-1] INFO org.apache.solr.core.SolrCore –
QuerySenderListener sending requests to
Searcher@6b1b4cac[solr6606_shard1_replica1]
main{StandardDirectoryReader(segments_5q:2567:nrt _9g(4.10.2):C794000
_io(4.10.2):C76 _sf(4.10.2):C796000 _yk(4.10.2):C543000 _ze(4.10.2):C72000
_zf(4.10.2):C1000 _zg(4.10.2):C2000 _zh(4.10.2):C3000 _zi(4.10.2):C3000
_zj(4.10.2):C2121 _zk(4.10.2):C2879 _zl(4.10.2):C3000 _zm(4.10.2):C2000)}
16226 [searcherExecutor-6-thread-1] INFO org.apache.solr.core.SolrCore –
[solr6606_shard1_replica1] webapp=null path=null
params={event=firstSearcher&q=static+firstSearcher+warming+in+solrconfig.xml&distrib=false}
hits=0 status=0 QTime=39
16227 [searcherExecutor-7-thread-1] INFO org.apache.solr.core.SolrCore –
[collection1] webapp=null path=null
params={event=firstSearcher&q=static+firstSearcher+warming+in+solrconfig.xml&distrib=false}
hits=0 status=0 QTime=66
16227 [searcherExecutor-6-thread-1] INFO org.apache.solr.core.SolrCore –
QuerySenderListener done.
16227 [searcherExecutor-7-thread-1] INFO org.apache.solr.core.SolrCore –
QuerySenderListener done.
16227 [searcherExecutor-6-thread-1] INFO
org.apache.solr.handler.component.SpellCheckComponent – Loading spell index
for spellchecker: default
16227 [searcherExecutor-7-thread-1] INFO
org.apache.solr.handler.component.SpellCheckComponent – Loading spell index
for spellchecker: default
16228 [searcherExecutor-6-thread-1] INFO
org.apache.solr.handler.component.SpellCheckComponent – Loading spell index
for spellchecker: wordbreak
16228 [searcherExecutor-7-thread-1] INFO
org.apache.solr.handler.component.SpellCheckComponent – Loading spell index
for spellchecker: wordbreak
16228 [searcherExecutor-6-thread-1] INFO
org.apache.solr.handler.component.SuggestComponent – Loading suggester index
for: mySuggester
16228 [searcherExecutor-7-thread-1] INFO
org.apache.solr.handler.component.SuggestComponent – Loading suggester index
for: mySuggester
16229 [searcherExecutor-7-thread-1] INFO
org.apache.solr.spelling.suggest.SolrSuggester – reload()
16228 [searcherExecutor-6-thread-1] INFO
org.apache.solr.spelling.suggest.SolrSuggester – reload()
16229 [searcherExecutor-6-thread-1] INFO
org.apache.solr.spelling.suggest.SolrSuggester – build()
16229 [searcherExecutor-7-thread-1] INFO
org.apache.solr.spelling.suggest.SolrSuggester – build()
16249 [searcherExecutor-7-thread-1] INFO org.apache.solr.core.SolrCore –
[collection1] Registered new searcher Searcher@2c8633e1[collection1]
main{StandardDirectoryReader(segments_1:1:nrt)}
{code}
The SuggestComponent init's correctly. It's only when the firstSearcher event
gets fired that the spellchecker and the suggester gets built. This is where
the problem lies.
We should just comment out the {{static firstSearcher warming in
solrconfig.xml}} query from the {{firstSearcher}} query list, just as how
the queries are commented out from the {{newSearcher}} event listener.
We should also add a comment here saying that a
[jira] [Commented] (SOLR-6559) Create an endpoint /update/xml/docs endpoint to do custom xml indexing
[ https://issues.apache.org/jira/browse/SOLR-6559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245252#comment-14245252 ] Anurag Sharma commented on SOLR-6559: - Can you review the patch for merge if srcField is not required, > Create an endpoint /update/xml/docs endpoint to do custom xml indexing > -- > > Key: SOLR-6559 > URL: https://issues.apache.org/jira/browse/SOLR-6559 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-6559.patch, SOLR-6559.patch, SOLR-6559.patch > > > Just the way we have an json end point create an xml end point too. use the > XPathRecordReader in DIH to do the same . The syntax would require slight > tweaking to match the params of /update/json/docs -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
