[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1012 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1012/ 12 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:45032 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:45032 at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:617) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:392) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:546) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at
[jira] [Updated] (SOLR-9080) DateMath is broken before the year 1582
[ https://issues.apache.org/jira/browse/SOLR-9080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-9080: --- Attachment: SOLR_9080_DateMath_should_not_use_Calendar_API.patch This patch adds a little more testing and it modified the constructor to not take a Locale, thus affecting some callers. I removed two protected methods in DIH DateFormatEvaluator related to date processing that I don't think are necessary for subclasses to customize. I'll commit this Friday morning and then I'll post a follow-up issue to refine the DateMathParser API a bit to my liking. > DateMath is broken before the year 1582 > --- > > Key: SOLR-9080 > URL: https://issues.apache.org/jira/browse/SOLR-9080 > Project: Solr > Issue Type: Bug >Affects Versions: 6.0 >Reporter: David Smiley >Assignee: David Smiley > Fix For: 6.1 > > Attachments: SOLR_9080_DateMath_should_not_use_Calendar_API.patch, > SOLR_9080_DateMath_should_not_use_Calendar_API.patch > > > In Solr 6.0, dates are parsed using the Java 8 java.time API. It formerly > was parsed using java.util.SimpleDateFormat which uses > java.util.GregorianCalendar. I've learned that the java.time API does _not_ > switch to a different algorithm at the Gregorian Change Date (year 1582) > whereas GregorianCalendar does. A ramification of this is that the > milliseconds before epoch value is different between the APIs for dates prior > to this year. They both round-trip between themselves but not between each > other prior to this date. Thus, anyone indexing historical dates must > re-index when moving to Solr 6. > What was _not_ changed in the parsing code was Solr's date-math logic -- it > still uses the Calendar API. This works for dates after 1582 but before, > it'll introduce discrepancies. Here's an example showing weird behavior: > http://localhost:8983/solr/techproducts/select?facet.range.end=1400-01-01T00:00:00Z=%2B10YEARS=1300-01-01T00:00:00Z/YEAR=manufacturedate_dt=on=on=*:*=0=json > Note that the year 1300 rounded down to the year, becomes 1299 January 8th > (weird in and of itself) and that subsequent gaps start on the 9th. > {noformat} > "counts":[ > "1299-01-08T00:00:00Z",0, > "1309-01-09T00:00:00Z",0, > "1319-01-09T00:00:00Z",0, ... > {noformat} > This weirdness will show itself for units at the year or month level, but not > below that (from what I'm seeing). In other words, if facet.range.gap is at > this amount, or otherwise using the date math syntax to round or add a year > or month, there will be issues like this. Otherwise there doesn't seem to be > an issue. > I think the solution is clearly to switch the date math code to use the > java.time API. -- 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-9055) Make collection backup/restore extensible
[ https://issues.apache.org/jira/browse/SOLR-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281201#comment-15281201 ] Hrishikesh Gadre commented on SOLR-9055: [~markrmil...@gmail.com] I have posted partial patch in SOLR-7374. The primary reason for this split is to keep the patch short and easy to review. I will post the remaining changes as part of this issue soon. Please take a look and let me have your feedback. > Make collection backup/restore extensible > - > > Key: SOLR-9055 > URL: https://issues.apache.org/jira/browse/SOLR-9055 > Project: Solr > Issue Type: Task >Reporter: Hrishikesh Gadre >Assignee: Mark Miller > Attachments: SOLR-9055.patch, SOLR-9055.patch > > > SOLR-5750 implemented backup/restore API for Solr. This JIRA is to track the > code cleanup/refactoring. Specifically following improvements should be made, > - Add Solr/Lucene version to check the compatibility between the backup > version and the version of Solr on which it is being restored. > - Add a backup implementation version to check the compatibility between the > "restore" implementation and backup format. > - Introduce a Strategy interface to define how the Solr index data is backed > up (e.g. using file copy approach). > - Introduce a Repository interface to define the file-system used to store > the backup data. (currently works only with local file system but can be > extended). This should be enhanced to introduce support for "registering" > repositories (e.g. HDFS, S3 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] [Updated] (SOLR-7374) Backup/Restore should provide a param for specifying the directory implementation it should use
[ https://issues.apache.org/jira/browse/SOLR-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hrishikesh Gadre updated SOLR-7374: --- Attachment: SOLR-7374.patch Please find the patch attached. It includes following - A backup repository interface and concrete implementations for local file-system and HDFS - Ability to configure repositories via solr.xml - Refactored the "core" level backup/restore to use this repository interface - Unit test for HDFS integration. > Backup/Restore should provide a param for specifying the directory > implementation it should use > --- > > Key: SOLR-7374 > URL: https://issues.apache.org/jira/browse/SOLR-7374 > Project: Solr > Issue Type: Bug >Reporter: Varun Thacker >Assignee: Varun Thacker > Fix For: 5.2, 6.0 > > Attachments: SOLR-7374.patch > > > Currently when we create a backup we use SimpleFSDirectory to write the > backup indexes. Similarly during a restore we open the index using > FSDirectory.open . > We should provide a param called {{directoryImpl}} or {{type}} which will be > used to specify the Directory implementation to backup the index. > Likewise during a restore you would need to specify the directory impl which > was used during backup so that the index can be opened correctly. > This param will address the problem that currently if a user is running Solr > on HDFS there is no way to use the backup/restore functionality as the > directory is hardcoded. > With this one could be running Solr on a local FS but backup the index on > HDFS 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-8744) Overseer operations need more fine grained mutual exclusion
[ https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281187#comment-15281187 ] Scott Blum commented on SOLR-8744: -- Good plan! > Overseer operations need more fine grained mutual exclusion > --- > > Key: SOLR-8744 > URL: https://issues.apache.org/jira/browse/SOLR-8744 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Scott Blum >Assignee: Noble Paul > Labels: sharding, solrcloud > > SplitShard creates a mutex over the whole collection, but, in practice, this > is a big scaling problem. Multiple split shard operations could happen at > the time time, as long as different shards are being split. In practice, > those shards often reside on different machines, so there's no I/O bottleneck > in those cases, just the mutex in Overseer forcing the operations to be done > serially. > Given that a single split can take many minutes on a large collection, this > is a bottleneck at scale. > Here is the proposed new design > There are various Collection operations performed at Overseer. They may need > exclusive access at various levels. Each operation must define the Access > level at which the access is required. Access level is an enum. > CLUSTER(0) > COLLECTION(1) > SHARD(2) > REPLICA(3) > The Overseer node maintains a tree of these locks. The lock tree would look > as follows. The tree can be created lazily as and when tasks come up. > {code} > Legend: > C1, C2 -> Collections > S1, S2 -> Shards > R1,R2,R3,R4 -> Replicas > Cluster > / \ >/ \ > C1 C2 > / \ / \ > / \ / \ >S1 S2 S1 S2 > R1, R2 R3.R4 R1,R2 R3,R4 > {code} > When the overseer receives a message, it tries to acquire the appropriate > lock from the tree. For example, if an operation needs a lock at a Collection > level and it needs to operate on Collection C1, the node C1 and all child > nodes of C1 must be free. > h2.Lock acquiring logic > Each operation would start from the root of the tree (Level 0 -> Cluster) and > start moving down depending upon the operation. After it reaches the right > node, it checks if all the children are free from a lock. If it fails to > acquire a lock, it remains in the work queue. A scheduler thread waits for > notification from the current set of tasks . Every task would do a > {{notify()}} on the monitor of the scheduler thread. The thread would start > from the head of the queue and check all tasks to see if that task is able to > acquire the right lock. If yes, it is executed, if not, the task is left in > the work queue. > When a new task arrives in the work queue, the schedulerthread wakes and just > try to schedule that task. -- 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-6.x-Solaris (64bit/jdk1.8.0) - Build # 125 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/125/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud Error Message: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestSolrConfigHandlerCloud: 1) Thread[id=4355, name=Thread-1503, state=TIMED_WAITING, group=TGRP-TestSolrConfigHandlerCloud] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101) at org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:333) at org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48) at org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75) at org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108) at org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79) at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:913) at org.apache.solr.core.SolrCore.lambda$getConfListener$6(SolrCore.java:2490) at org.apache.solr.core.SolrCore$$Lambda$42/1331424345.run(Unknown Source) at org.apache.solr.cloud.ZkController$4.run(ZkController.java:2423) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestSolrConfigHandlerCloud: 1) Thread[id=4355, name=Thread-1503, state=TIMED_WAITING, group=TGRP-TestSolrConfigHandlerCloud] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101) at org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:333) at org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48) at org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75) at org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108) at org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79) at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:913) at org.apache.solr.core.SolrCore.lambda$getConfListener$6(SolrCore.java:2490) at org.apache.solr.core.SolrCore$$Lambda$42/1331424345.run(Unknown Source) at org.apache.solr.cloud.ZkController$4.run(ZkController.java:2423) at __randomizedtesting.SeedInfo.seed([23C3907CC22EB4FB]:0) Build Log: [...truncated 10796 lines...] [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerCloud [junit4] 2> Creating dataDir: /export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J1/temp/solr.handler.TestSolrConfigHandlerCloud_23C3907CC22EB4FB-001/init-core-data-001 [junit4] 2> 659101 INFO (SUITE-TestSolrConfigHandlerCloud-seed#[23C3907CC22EB4FB]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) [junit4] 2> 659103 INFO (SUITE-TestSolrConfigHandlerCloud-seed#[23C3907CC22EB4FB]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /kshe/ [junit4] 2> 659105 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[23C3907CC22EB4FB]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 659105 INFO (Thread-1373) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 659105 INFO (Thread-1373) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 659205 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[23C3907CC22EB4FB]) [] o.a.s.c.ZkTestServer start zk server on port:37328 [junit4] 2> 659205 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[23C3907CC22EB4FB]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 659206 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[23C3907CC22EB4FB]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 659208 INFO (zkCallback-500-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@1fd97609 name:ZooKeeperConnection Watcher:127.0.0.1:37328 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 659208 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[23C3907CC22EB4FB]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 659209 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[23C3907CC22EB4FB]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 659209 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[23C3907CC22EB4FB]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2> 659212 INFO (TEST-TestSolrConfigHandlerCloud.test-seed#[23C3907CC22EB4FB]) []
[jira] [Comment Edited] (LUCENE-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0
[ https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281171#comment-15281171 ] Steve Rowe edited comment on LUCENE-6993 at 5/12/16 4:03 AM: - Hi Mike, my review of your latest patch: * All the on-or-after tests in analysis factories should switch to 6.1.0 (since that's where this will likely land) * I agree with Robert that ClassicTokenizer should stay on Unicode 3.0 - you changed it to 7.0. That means it doesn't need version-specific behavior, so the factory changes and the build.xml targets aren't required. * WikipediaTokenizer is in the same boat as ClassicTokenizer - it's essentially a cloned ClassicTokenizer with some modifications for Wiki syntax. I vote for keeping it at Unicode 3.0 and reverting the factory changes and the build.xml targets. Performing an effective upgrade would probably mean cloning the current StandardTokenizer and then re-layering the wiki syntax. * In generateJavaUnicodeWordBreakTest.pl, you added the test for the double quote code point: {{push @tokens, '"'.join('', map \{ $_ ~~ /0022/ ? "\\\"" : "⧹⧹u$\_" } @chars).'"';}} - why use the smartmatch operator here? No recursion required or unknown types here. Just {{/0022/}} instead of {{$_ ~~ /0022/}} would work, right? * TestStandardAnalyzer and TestUAX29URLEmailTokenizer refer to WordBreakTestUnicode_8_0_0, but that should be _7_0_0. * In the run-jflex-and-disable-buffer-expansion target in build.xml, you removed the comment with the link to the relevant JIRA - why? * You said: bq. I looked at the new generated jflex code and I think it takes care of the buffer expansion issue.\ +1 - LGTM * Robert said: bq. TestStandardAnalyzer and TestUAX29URLEmailAnalyzer also have a testBackcompat40 which calls setVersion and ensures it works. but AFAICT you didn't put any backcompat tests in place? * you said: bq. ant jflex-legacy # For some reason this needs to be run separately from the jflex command. I could never figure out why. What happens if you make it a dependency of the jflex target? was (Author: steve_rowe): Hi Mike, my review of your latest patch: * All the on-or-after tests in analysis factories should switch to 6.1.0 (since that's where this will likely land) * I agree with Robert that ClassicTokenizer should stay on Unicode 3.0 - you changed it to 7.0. That means it doesn't need version-specific behavior, so the factory changes and the build.xml targets aren't required. * WikipediaTokenizer is in the same boat as ClassicTokenizer - it's essentially a cloned ClassicTokenizer with some modifications for Wiki syntax. I vote for keeping it at Unicode 3.0 and reverting the factory changes and the build.xml targets. Performing an effective upgrade would probably mean cloning the current StandardTokenizer and then re-layering the wiki syntax. * In generateJavaUnicodeWordBreakTest.pl, you added the test for the double quote code point: {{push @tokens, '"'.join('', map \{ $_ ~~ /0022/ ? "\\\"" : "\ \u$\_" } @chars).'"';}} - why use the smartmatch operator here? No recursion required or unknown types here. Just {{/0022/}} instead of {{$_ ~~ /0022/}} would work, right? * TestStandardAnalyzer and TestUAX29URLEmailTokenizer refer to WordBreakTestUnicode_8_0_0, but that should be _7_0_0. * In the run-jflex-and-disable-buffer-expansion target in build.xml, you removed the comment with the link to the relevant JIRA - why? * You said: bq. I looked at the new generated jflex code and I think it takes care of the buffer expansion issue.\ +1 - LGTM * Robert said: bq. TestStandardAnalyzer and TestUAX29URLEmailAnalyzer also have a testBackcompat40 which calls setVersion and ensures it works. but AFAICT you didn't put any backcompat tests in place? * you said: bq. ant jflex-legacy # For some reason this needs to be run separately from the jflex command. I could never figure out why. What happens if you make it a dependency of the jflex target? > Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all > JFlex-based tokenizers to support Unicode 8.0 > > > Key: LUCENE-6993 > URL: https://issues.apache.org/jira/browse/LUCENE-6993 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Mike Drob >Assignee: Robert Muir > Fix For: 6.x > > Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, > LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, > LUCENE-6993.patch > > > We did this once before in LUCENE-5357, but it might be time to update the > list of TLDs again. Comparing our old list with a new list indicates 800+ new > domains, so it would be nice to include
[jira] [Comment Edited] (SOLR-8744) Overseer operations need more fine grained mutual exclusion
[ https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281175#comment-15281175 ] Noble Paul edited comment on SOLR-8744 at 5/12/16 3:59 AM: --- good question. Starvation is indeed a problem and we must make the best effort to run tasks on a first come first served basis We can address it by making the scheduling itself smarter as follows: As the scheduler thread starts with trying to acquire a lock, it could build a tree of its own with nodes marked 'busy' in a local tree for previously unassignable tasks. The local tree would look as follows. If the Task {{T1}} needs a lock on Collection {{C1}} and it is unable to acquire a lock, The local tree would look as follows {code} Cluster / / C1 {code} When task {{T2}} is taken up, which requires a lock on {{Cluster -> C1 -> S1}} , It would not try to acquire a lock from loct tree because the path {{Cluster ->C1}} is already is marked as 'busy' in the local tree. So {{T2}} would remain in the work queue till {{T1}} is completed. was (Author: noble.paul): good question. Starvation is indeed a problem and we must make the best effort to run tasks on a first come first served basis We can address it by making the scheduling itself smarter as follows: As the scheduler thread starts with trying to acquire a lock, it could build a tree of its own with nodes marked 'busy' in a local tree for previously unassaignable tasks. The local tree would look as follows. If the Task {{T1}} needs a lock on Collection {{C1}} and it is unable to acquire a lock, The local tree would look as follows {code} Cluster / / C1 {code} When task {{T2}} is taken up, which requires a lock on {{Cluster -> C1 -> S1}} , It would not try to acquire a lock from loct tree because the path {{Cluster ->C1}} is already is marked as 'busy' in the local tree. So {{T2}} would remain in the work queue till {{T1}} is completed. > Overseer operations need more fine grained mutual exclusion > --- > > Key: SOLR-8744 > URL: https://issues.apache.org/jira/browse/SOLR-8744 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Scott Blum >Assignee: Noble Paul > Labels: sharding, solrcloud > > SplitShard creates a mutex over the whole collection, but, in practice, this > is a big scaling problem. Multiple split shard operations could happen at > the time time, as long as different shards are being split. In practice, > those shards often reside on different machines, so there's no I/O bottleneck > in those cases, just the mutex in Overseer forcing the operations to be done > serially. > Given that a single split can take many minutes on a large collection, this > is a bottleneck at scale. > Here is the proposed new design > There are various Collection operations performed at Overseer. They may need > exclusive access at various levels. Each operation must define the Access > level at which the access is required. Access level is an enum. > CLUSTER(0) > COLLECTION(1) > SHARD(2) > REPLICA(3) > The Overseer node maintains a tree of these locks. The lock tree would look > as follows. The tree can be created lazily as and when tasks come up. > {code} > Legend: > C1, C2 -> Collections > S1, S2 -> Shards > R1,R2,R3,R4 -> Replicas > Cluster > / \ >/ \ > C1 C2 > / \ / \ > / \ / \ >S1 S2 S1 S2 > R1, R2 R3.R4 R1,R2 R3,R4 > {code} > When the overseer receives a message, it tries to acquire the appropriate > lock from the tree. For example, if an operation needs a lock at a Collection > level and it needs to operate on Collection C1, the node C1 and all child > nodes of C1 must be free. > h2.Lock acquiring logic > Each operation would start from the root of the tree (Level 0 -> Cluster) and > start moving down depending upon the operation. After it reaches the right > node, it checks if all the children are free from a lock. If it fails to > acquire a lock, it remains in the work queue. A scheduler thread waits for > notification from the current set of tasks . Every task would do a > {{notify()}} on the monitor of the scheduler thread. The thread would start > from the head of the queue and check all tasks to see if that task is able to > acquire the right lock. If yes, it is executed, if not, the task is left in > the work queue. > When a new task arrives in the work queue, the schedulerthread wakes and just > try to schedule that task. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SOLR-8744) Overseer operations need more fine grained mutual exclusion
[ https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281175#comment-15281175 ] Noble Paul commented on SOLR-8744: -- good question. Starvation is indeed a problem and we must make the best effort to run tasks on a first come first served basis We can address it by making the scheduling itself smarter as follows: As the scheduler thread starts with trying to acquire a lock, it could build a tree of its own with nodes marked 'busy' in a local tree for previously unassaignable tasks. The local tree would look as follows. If the Task {{T1}} needs a lock on Collection {{C1}} and it is unable to acquire a lock, The local tree would look as follows {code} Cluster / / C1 {code} When task {{T2}} is taken up, which requires a lock on {{Cluster -> C1 -> S1}} , It would not try to acquire a lock from loct tree because the path {{Cluster ->C1}} is already is marked as 'busy' in the local tree. So {{T2}} would remain in the work queue till {{T1}} is completed. > Overseer operations need more fine grained mutual exclusion > --- > > Key: SOLR-8744 > URL: https://issues.apache.org/jira/browse/SOLR-8744 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Scott Blum >Assignee: Noble Paul > Labels: sharding, solrcloud > > SplitShard creates a mutex over the whole collection, but, in practice, this > is a big scaling problem. Multiple split shard operations could happen at > the time time, as long as different shards are being split. In practice, > those shards often reside on different machines, so there's no I/O bottleneck > in those cases, just the mutex in Overseer forcing the operations to be done > serially. > Given that a single split can take many minutes on a large collection, this > is a bottleneck at scale. > Here is the proposed new design > There are various Collection operations performed at Overseer. They may need > exclusive access at various levels. Each operation must define the Access > level at which the access is required. Access level is an enum. > CLUSTER(0) > COLLECTION(1) > SHARD(2) > REPLICA(3) > The Overseer node maintains a tree of these locks. The lock tree would look > as follows. The tree can be created lazily as and when tasks come up. > {code} > Legend: > C1, C2 -> Collections > S1, S2 -> Shards > R1,R2,R3,R4 -> Replicas > Cluster > / \ >/ \ > C1 C2 > / \ / \ > / \ / \ >S1 S2 S1 S2 > R1, R2 R3.R4 R1,R2 R3,R4 > {code} > When the overseer receives a message, it tries to acquire the appropriate > lock from the tree. For example, if an operation needs a lock at a Collection > level and it needs to operate on Collection C1, the node C1 and all child > nodes of C1 must be free. > h2.Lock acquiring logic > Each operation would start from the root of the tree (Level 0 -> Cluster) and > start moving down depending upon the operation. After it reaches the right > node, it checks if all the children are free from a lock. If it fails to > acquire a lock, it remains in the work queue. A scheduler thread waits for > notification from the current set of tasks . Every task would do a > {{notify()}} on the monitor of the scheduler thread. The thread would start > from the head of the queue and check all tasks to see if that task is able to > acquire the right lock. If yes, it is executed, if not, the task is left in > the work queue. > When a new task arrives in the work queue, the schedulerthread wakes and just > try to schedule that task. -- 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-6939) BlendedInfixSuggester to support exponential reciprocal BlenderType
[ https://issues.apache.org/jira/browse/LUCENE-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281172#comment-15281172 ] Erick Erickson commented on LUCENE-6939: Done, but this is all a mystery to me so if I messed it up please let me know. > BlendedInfixSuggester to support exponential reciprocal BlenderType > --- > > Key: LUCENE-6939 > URL: https://issues.apache.org/jira/browse/LUCENE-6939 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spellchecker >Affects Versions: 5.4 >Reporter: Arcadius Ahouansou >Priority: Minor > Labels: suggester > Fix For: 5.5, 6.0 > > Attachments: LUCENE-6939.patch > > > The orignal BlendedInfixSuggester introduced in LUCENE-5354 has support for: > - {{BlenderType.POSITION_LINEAR}} and > - {{BlenderType.POSITION_RECIPROCAL}} . > These are used to score documents based on the position of the matched token > i.e the closer is the matched term to the beginning, the higher score you get. > In some use cases, we need a more aggressive scoring based on the position. > That's where the exponential reciprocal comes into play > i.e > {{coef = 1/Math.pow(position+1, exponent)}} > where the {{exponent}} is a configurable variable. -- 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-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0
[ https://issues.apache.org/jira/browse/LUCENE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281171#comment-15281171 ] Steve Rowe commented on LUCENE-6993: Hi Mike, my review of your latest patch: * All the on-or-after tests in analysis factories should switch to 6.1.0 (since that's where this will likely land) * I agree with Robert that ClassicTokenizer should stay on Unicode 3.0 - you changed it to 7.0. That means it doesn't need version-specific behavior, so the factory changes and the build.xml targets aren't required. * WikipediaTokenizer is in the same boat as ClassicTokenizer - it's essentially a cloned ClassicTokenizer with some modifications for Wiki syntax. I vote for keeping it at Unicode 3.0 and reverting the factory changes and the build.xml targets. Performing an effective upgrade would probably mean cloning the current StandardTokenizer and then re-layering the wiki syntax. * In generateJavaUnicodeWordBreakTest.pl, you added the test for the double quote code point: {{push @tokens, '"'.join('', map \{ $_ ~~ /0022/ ? "\\\"" : "\ \u$\_" } @chars).'"';}} - why use the smartmatch operator here? No recursion required or unknown types here. Just {{/0022/}} instead of {{$_ ~~ /0022/}} would work, right? * TestStandardAnalyzer and TestUAX29URLEmailTokenizer refer to WordBreakTestUnicode_8_0_0, but that should be _7_0_0. * In the run-jflex-and-disable-buffer-expansion target in build.xml, you removed the comment with the link to the relevant JIRA - why? * You said: bq. I looked at the new generated jflex code and I think it takes care of the buffer expansion issue.\ +1 - LGTM * Robert said: bq. TestStandardAnalyzer and TestUAX29URLEmailAnalyzer also have a testBackcompat40 which calls setVersion and ensures it works. but AFAICT you didn't put any backcompat tests in place? * you said: bq. ant jflex-legacy # For some reason this needs to be run separately from the jflex command. I could never figure out why. What happens if you make it a dependency of the jflex target? > Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all > JFlex-based tokenizers to support Unicode 8.0 > > > Key: LUCENE-6993 > URL: https://issues.apache.org/jira/browse/LUCENE-6993 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Mike Drob >Assignee: Robert Muir > Fix For: 6.x > > Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, > LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, > LUCENE-6993.patch > > > We did this once before in LUCENE-5357, but it might be time to update the > list of TLDs again. Comparing our old list with a new list indicates 800+ new > domains, so it would be nice to include them. > Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.0. -- 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
Re: [JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 573 - Failure!
Thanks! I wondered why we were getting a bunch of them all of the sudden... but was too lazy to look. On Wed, May 11, 2016 at 8:46 PM, Joel Bernsteinwrote: > I committed a fix for this. An error message was changed, that was being > used for a test case. > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Wed, May 11, 2016 at 10:43 PM, Policeman Jenkins Server > wrote: >> >> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/573/ >> Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC >> >> 1 tests failed. >> FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation >> >> Error Message: >> >> >> Stack Trace: >> java.lang.AssertionError >> at >> __randomizedtesting.SeedInfo.seed([3FA2DD58307D524B:1C3DBC9200F135F9]:0) >> at org.junit.Assert.fail(Assert.java:92) >> at org.junit.Assert.assertTrue(Assert.java:43) >> at org.junit.Assert.assertTrue(Assert.java:54) >> at >> org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) >> at >> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) >> at >> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) >> at >> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) >> at >> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) >> at >> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) >> at >> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) >> at >> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >> at >> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) >> at >> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) >> at >> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) >> at >> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) >> at >> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >> at >> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) >> at >> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) >> at >> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) >> at >> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) >> at >> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) >> at >> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) >> 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:53) >> at >> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) >> at >> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) >> at >>
[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 628 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/628/ Java: 32bit/jdk1.8.0_92 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.TestReqParamsAPI.test Error Message: Could not get expected value 'P val' for path 'response/params/y/p' full output: { "responseHeader":{ "status":0, "QTime":0}, "response":{ "znodeVersion":2, "params":{ "x":{ "a":"A val", "b":"B val", "":{"v":0}}, "y":{ "c":"CY val modified", "b":"BY val", "i":20, "d":[ "val 1", "val 2"], "e":"EY val", "":{"v":1}, from server: http://127.0.0.1:34017/collection1 Stack Trace: java.lang.AssertionError: Could not get expected value 'P val' for path 'response/params/y/p' full output: { "responseHeader":{ "status":0, "QTime":0}, "response":{ "znodeVersion":2, "params":{ "x":{ "a":"A val", "b":"B val", "":{"v":0}}, "y":{ "c":"CY val modified", "b":"BY val", "i":20, "d":[ "val 1", "val 2"], "e":"EY val", "":{"v":1}, from server: http://127.0.0.1:34017/collection1 at __randomizedtesting.SeedInfo.seed([89C798717ECC8CD6:193A7ABD030E12E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:457) at org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:216) at org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
Re: Contributor access
Thanks Eric! I can see the "comment" button now. Regards Hrishikesh On Wed, May 11, 2016 at 7:51 PM, Erick Ericksonwrote: > Yeah, we had a spam problem so (regretfully) the JIRA had to be locked > down and we have to go through this "add to contributor's group" > hurdle > > I've given you access I think. > > Erick > > > > On Wed, May 11, 2016 at 6:30 PM, Hrishikesh Gadre > wrote: > > Hello, > > > > I am currently working on following Solr JIRA. > > > > https://issues.apache.org/jira/browse/SOLR-9055 > > > > I have prepared a patch. But I am not able to comment due to JIRA > lockdown. > > Would it be possible for me to get "contributor" access ? > > > > Please let me know, > > > > Thanks > > Hrishikesh > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Contributor access
Yeah, we had a spam problem so (regretfully) the JIRA had to be locked down and we have to go through this "add to contributor's group" hurdle I've given you access I think. Erick On Wed, May 11, 2016 at 6:30 PM, Hrishikesh Gadrewrote: > Hello, > > I am currently working on following Solr JIRA. > > https://issues.apache.org/jira/browse/SOLR-9055 > > I have prepared a patch. But I am not able to comment due to JIRA lockdown. > Would it be possible for me to get "contributor" access ? > > Please let me know, > > Thanks > Hrishikesh - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 573 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/573/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([3FA2DD58307D524B:1C3DBC9200F135F9]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 12897 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> Creating dataDir:
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16718 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16718/ Java: 32bit/jdk1.8.0_92 -client -XX:+UseG1GC 2 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication Error Message: expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([52F9AA1A02BBB89:F25C74F966C3146F]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1327) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.schema.TestManagedSchemaAPI.test Error Message: Error from server
[JENKINS] Lucene-Solr-Tests-6.x - Build # 200 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/200/ 1 tests failed. FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([AD753FCD9DAB1E81:8EEA5E07AD277933]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 12908 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build/solr-solrj/test/J2/temp/solr.client.solrj.io.sql.JdbcTest_AD753FCD9DAB1E81-001/init-core-data-001 [junit4] 2> 0INFO
Contributor access
Hello, I am currently working on following Solr JIRA. https://issues.apache.org/jira/browse/SOLR-9055 I have prepared a patch. But I am not able to comment due to JIRA lockdown. Would it be possible for me to get "contributor" access ? Please let me know, Thanks Hrishikesh
[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 131 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/131/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([B6E37B00319D05C2:957C1ACA01116270]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 13028 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> Creating dataDir: /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-solrj/test/J1/temp/solr.client.solrj.io.sql.JdbcTest_B6E37B00319D05C2-001/init-core-data-001
[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 627 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/627/ Java: 32bit/jdk1.8.0_92 -client -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([84A539D7C7B2115F:A73A581DF73E76ED]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 12905 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-solrj/test/J2/temp/solr.client.solrj.io.sql.JdbcTest_84A539D7C7B2115F-001/init-core-data-001 [junit4] 2> 10187
[JENKINS] Lucene-Solr-Tests-master - Build # 1140 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1140/ 1 tests failed. FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([E2E80CF3AB82759C:C1776D399B0E122E]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 13063 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.io.sql.JdbcTest_E2E80CF3AB82759C-001/init-core-data-001 [junit4] 2> 84591 INFO
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3263 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3263/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([BB499F3BAAD675E4:98D6FEF19A5A1256]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 13012 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> Creating dataDir:
[jira] [Commented] (SOLR-9092) Add safety checks to delete replica/shard/collection commands
[ https://issues.apache.org/jira/browse/SOLR-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281005#comment-15281005 ] Anshum Gupta commented on SOLR-9092: Agreed that changing the default of onlyIfLive to true would break back-compat, but we still need to fix this. This could easily spiral into a bigger problem with large clusters. Also, we should fix whatever is returned to the user in terms of failure/success. If it's a failure, the user should have a way to at least retry and clean up whatever cruft was left behind. If we choose to return a success, we should be responsible for returning more information about what was not cleaned up from the disk in a manner that makes it easier to parse and process for the users. > Add safety checks to delete replica/shard/collection commands > - > > Key: SOLR-9092 > URL: https://issues.apache.org/jira/browse/SOLR-9092 > Project: Solr > Issue Type: Improvement >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Minor > > We should verify the delete commands against live_nodes to make sure the API > can atleast be executed correctly > If we have a two node cluster, a collection with 1 shard 2 replica. Call the > delete replica command against for the replica whose node is currently down. > You get an exception: > {code} > > > 0 > 5173 > > >name="192.168.1.101:7574_solr">org.apache.solr.client.solrj.SolrServerException:Server > refused connection at: http://192.168.1.101:7574/solr > > > {code} > At this point the entry for the replica is gone from state.json . The client > application retries since an error was thrown but the delete command will > never succeed now and an error like this will be seen- > {code} > > > 400 > 137 > >org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Invalid replica : core_node3 in shard/collection : shard1/gettingstarted > available replicas are core_node1 > > Invalid replica : core_node3 in shard/collection : > shard1/gettingstarted available replicas are core_node1 > 400 > > > > org.apache.solr.common.SolrException > name="root-error-class">org.apache.solr.common.SolrException > > Invalid replica : core_node3 in shard/collection : > shard1/gettingstarted available replicas are core_node1 > 400 > > > {code} > For create collection/add-replica we check the "createNodeSet" and "node" > params respectively against live_nodes to make sure it has a chance of > succeeding. > We should add a check against live_nodes for the delete commands as well. > Another situation where I saw this can be a problem - A second solr cluster > cloned from the first but the script didn't correctly change the hostnames in > the state.json file. When a delete command was issued against the second > cluster Solr deleted the replica from the first cluster. > In the above case the script was buggy obviously but if we verify against > live_nodes then Solr wouldn't have gone ahead and deleted replicas not > belonging to its cluster. -- 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-6.x - Build # 199 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/199/ 1 tests failed. FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([2E779552A93A2A99:DE8F49899B64D2B]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 13070 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.io.sql.JdbcTest_2E779552A93A2A99-001/init-core-data-001 [junit4] 2> 79311 INFO
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+116) - Build # 16717 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16717/ Java: 64bit/jdk-9-ea+116 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([D88E0831BD2EE564:FB1169FB8DA282D6]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(java.base@9-ea/Thread.java:804) Build Log: [...truncated 12919 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> Creating dataDir:
[jira] [Resolved] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found
[ https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-8970. Resolution: Fixed Assignee: Hoss Man Fix Version/s: master (7.0) 6.1 Current jira spam counter messures are probably preventing gitbot comments... http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/76063648 http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/1d7094c9 > SSLTestConfig behaves really stupid if keystore can't be found > -- > > Key: SOLR-8970 > URL: https://issues.apache.org/jira/browse/SOLR-8970 > Project: Solr > Issue Type: Bug >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 6.1, master (7.0) > > Attachments: SOLR-8970.patch, SOLR-8970.patch, SOLR-8970.patch > > > The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it > wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean > "trySslClientAuth") but it has a hardcoded assumption that the keystore file > it can use (for both the keystore and the truststore) will exist at a fixed > path in the solr install. > when this works, it works fine - but if end users subclass/reuse > SolrTestCaseJ4 in their own projects, they may do so in a way that prevents > the SSLTestConfig keystore assumptions from being true, and yet they won't > get any sort of clear error. -- 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-7963) Suggester context filter query to accept local params query
[ https://issues.apache.org/jira/browse/SOLR-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14993601#comment-14993601 ] Arcadius Ahouansou edited comment on SOLR-7963 at 5/11/16 10:35 PM: Hello [~janhoy]. Yes, I am working on this, but I have been very busy recently... I will get back to it and submit a working patch as soon as time allows. This should address most issues you have raised ... Thanks. was (Author: arcadius): Hello [~janhoy]. Yes, I am working on this, but I have been very busy recently... I will get back to it and submit a working patch as soon as time allows. This should address most issues you have raised ... Thanks. > Suggester context filter query to accept local params query > --- > > Key: SOLR-7963 > URL: https://issues.apache.org/jira/browse/SOLR-7963 > Project: Solr > Issue Type: Improvement > Components: Suggester >Affects Versions: 5.4 >Reporter: Arcadius Ahouansou >Priority: Minor > Labels: suggester > > SOLR-7888 has introduced a new parameter for filtering suggester queries > {code}suggest.cfq=ctx1 OR ctx2{code} > The implementation use the Solr {{StandardQueryParser}} for parsing the cfq > param. > This card is to allow to pass in local param queries such as > {code} > suggest.cfq={!terms f=contextx}ctx1,ctx2 > {code} -- 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-master - Build # 1139 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1139/ 1 tests failed. FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([9491919EEB1BC2F7:B70EF054DB97A545]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 12941 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/solr-solrj/test/J1/temp/solr.client.solrj.io.sql.JdbcTest_9491919EEB1BC2F7-001/init-core-data-001 [junit4] 2> 60509 INFO
[jira] [Updated] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found
[ https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-8970: --- Attachment: SOLR-8970.patch updated patch that goes the direction Joseph suggested, instead of a sys prop override, there's not a copy of the cert in the resources directory that's used so it can always be found. still running full test, but I'm pretty happy with this and plan to move forward as soon as i see precommit pass. > SSLTestConfig behaves really stupid if keystore can't be found > -- > > Key: SOLR-8970 > URL: https://issues.apache.org/jira/browse/SOLR-8970 > Project: Solr > Issue Type: Bug >Reporter: Hoss Man > Attachments: SOLR-8970.patch, SOLR-8970.patch, SOLR-8970.patch > > > The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it > wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean > "trySslClientAuth") but it has a hardcoded assumption that the keystore file > it can use (for both the keystore and the truststore) will exist at a fixed > path in the solr install. > when this works, it works fine - but if end users subclass/reuse > SolrTestCaseJ4 in their own projects, they may do so in a way that prevents > the SSLTestConfig keystore assumptions from being true, and yet they won't > get any sort of clear error. -- 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-6.x-Windows (64bit/jdk1.8.0_92) - Build # 171 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/171/ Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseParallelGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: ObjectTracker found 8 object(s) that were not released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, TransactionLog, TransactionLog, MockDirectoryWrapper] Stack Trace: java.lang.AssertionError: ObjectTracker found 8 object(s) that were not released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, TransactionLog, TransactionLog, MockDirectoryWrapper] at __randomizedtesting.SeedInfo.seed([81830FEF45AE85AD]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_81830FEF45AE85AD-001\tempDir-001\node1\testschemaapi_shard1_replica1\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_81830FEF45AE85AD-001\tempDir-001\node1\testschemaapi_shard1_replica1\data\tlog\tlog.001: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_81830FEF45AE85AD-001\tempDir-001\node1\testschemaapi_shard1_replica1\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_81830FEF45AE85AD-001\tempDir-001\node1\testschemaapi_shard1_replica1\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_81830FEF45AE85AD-001\tempDir-001\node1\testschemaapi_shard1_replica1\data: java.nio.file.DirectoryNotEmptyException:
[jira] [Closed] (SOLR-8945) When numerical field is sent an incorrect data type, exception could be more descriptive.
[ https://issues.apache.org/jira/browse/SOLR-8945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Garth Grimm closed SOLR-8945. - Resolution: Won't Fix > When numerical field is sent an incorrect data type, exception could be more > descriptive. > - > > Key: SOLR-8945 > URL: https://issues.apache.org/jira/browse/SOLR-8945 > Project: Solr > Issue Type: Improvement >Reporter: Garth Grimm >Priority: Minor > > While indexing from a database, solr automatically created some id fields as > `tlong`. These fields could either contain a number or a message like 'Not > Available' if that particular id/number was not present. > In such a case, solr threw an error similar to: > ERROR: [doc=People-139728] Error adding field 'Office_PhoneNo'='603 103' > msg=For input string: "603 103" > In such a case, the intuitive thing would be to throw a NumberFormatException > so that the user can easily figure out that a number field is receiving > non-numeric values. -- 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-6.x-Linux (32bit/jdk1.8.0_92) - Build # 626 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/626/ Java: 32bit/jdk1.8.0_92 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.lucene.search.spans.TestSpanCollection.testOrQuery Error Message: Missing term field:w3 Stack Trace: java.lang.AssertionError: Missing term field:w3 at __randomizedtesting.SeedInfo.seed([D070572A8414F49A:B0141C1F754681D2]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.lucene.search.spans.TestSpanCollection.checkCollectedTerms(TestSpanCollection.java:103) at org.apache.lucene.search.spans.TestSpanCollection.testOrQuery(TestSpanCollection.java:147) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 723 lines...] [junit4] Suite: org.apache.lucene.search.spans.TestSpanCollection [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestSpanCollection -Dtests.method=testOrQuery -Dtests.seed=D070572A8414F49A -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=fi-FI -Dtests.timezone=Pacific/Niue -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [junit4] FAILURE 0.02s J0 | TestSpanCollection.testOrQuery <<< [junit4]> Throwable #1: java.lang.AssertionError: Missing term field:w3 [junit4]>at
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+116) - Build # 16716 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16716/ Java: 64bit/jdk-9-ea+116 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([33766EBBE5F58383:10E90F71D579E431]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.io.sql.JdbcTest.testErrorPropagation(JdbcTest.java:411) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(java.base@9-ea/Thread.java:804) Build Log: [...truncated 13072 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.sql.JdbcTest [junit4] 2> Creating dataDir:
[jira] [Resolved] (SOLR-9105) Fix typos in solr core module
[ https://issues.apache.org/jira/browse/SOLR-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-9105. --- Resolution: Fixed Fix Version/s: master (7.0) > Fix typos in solr core module > - > > Key: SOLR-9105 > URL: https://issues.apache.org/jira/browse/SOLR-9105 > Project: Solr > Issue Type: Bug >Reporter: Bartosz Krasiński >Assignee: Jan Høydahl >Priority: Trivial > Fix For: 6.1, master (7.0) > > > Hello, > I wanted to fix one typo that I've found while reading the code, then I > decided to fix some more and that escalated a bit... > https://github.com/apache/lucene-solr/pull/39 -- 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-master-Windows (32bit/jdk1.8.0_92) - Build # 5834 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5834/ Java: 32bit/jdk1.8.0_92 -client -XX:+UseParallelGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: ObjectTracker found 4 object(s) that were not released!!! [MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 4 object(s) that were not released!!! [MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, TransactionLog] at __randomizedtesting.SeedInfo.seed([33842729C49ADCC8]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255) at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_33842729C49ADCC8-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_33842729C49ADCC8-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog\tlog.001: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_33842729C49ADCC8-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_33842729C49ADCC8-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_33842729C49ADCC8-001\tempDir-001\node1\testschemaapi_shard1_replica2\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_33842729C49ADCC8-001\tempDir-001\node1\testschemaapi_shard1_replica2\data C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_33842729C49ADCC8-001\tempDir-001\node1\testschemaapi_shard1_replica2:
[JENKINS] Lucene-Solr-Tests-master - Build # 1138 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1138/ 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: ObjectTracker found 4 object(s) that were not released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore] Stack Trace: java.lang.AssertionError: ObjectTracker found 4 object(s) that were not released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore] at __randomizedtesting.SeedInfo.seed([69118EF7135E592A]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=12388, name=searcherExecutor-5405-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=12388, name=searcherExecutor-5405-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([69118EF7135E592A]:0) FAILED:
[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+116) - Build # 16715 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16715/ Java: 32bit/jdk-9-ea+116 -server -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.schema.TestManagedSchemaAPI.test Error Message: Error from server at http://127.0.0.1:44614/solr/testschemaapi_shard1_replica1: ERROR: [doc=2] unknown field 'myNewField1' Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at http://127.0.0.1:44614/solr/testschemaapi_shard1_replica1: ERROR: [doc=2] unknown field 'myNewField1' at __randomizedtesting.SeedInfo.seed([5FE783BC16C1465E:D7B3BC66B83D2BA6]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:661) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898) at org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86) at org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at
[jira] [Commented] (SOLR-9105) Fix typos in solr core module
[ https://issues.apache.org/jira/browse/SOLR-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280658#comment-15280658 ] Jan Høydahl commented on SOLR-9105: --- Thank you very much for this thorough proof read. All changes looked sane. Committing to 6.1 and master. > Fix typos in solr core module > - > > Key: SOLR-9105 > URL: https://issues.apache.org/jira/browse/SOLR-9105 > Project: Solr > Issue Type: Bug >Reporter: Bartosz Krasiński >Assignee: Jan Høydahl >Priority: Trivial > Fix For: 6.1 > > > Hello, > I wanted to fix one typo that I've found while reading the code, then I > decided to fix some more and that escalated a bit... > https://github.com/apache/lucene-solr/pull/39 -- 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-9105) Fix typos in solr core module
[ https://issues.apache.org/jira/browse/SOLR-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280657#comment-15280657 ] ASF GitHub Bot commented on SOLR-9105: -- Github user asfgit closed the pull request at: https://github.com/apache/lucene-solr/pull/39 > Fix typos in solr core module > - > > Key: SOLR-9105 > URL: https://issues.apache.org/jira/browse/SOLR-9105 > Project: Solr > Issue Type: Bug >Reporter: Bartosz Krasiński >Assignee: Jan Høydahl >Priority: Trivial > Fix For: 6.1 > > > Hello, > I wanted to fix one typo that I've found while reading the code, then I > decided to fix some more and that escalated a bit... > https://github.com/apache/lucene-solr/pull/39 -- 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
[GitHub] lucene-solr pull request: [SOLR-9105] Fix some typos in solr core ...
Github user asfgit closed the pull request at: https://github.com/apache/lucene-solr/pull/39 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-9105) Fix typos in solr core module
[ https://issues.apache.org/jira/browse/SOLR-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-9105: - Assignee: Jan Høydahl > Fix typos in solr core module > - > > Key: SOLR-9105 > URL: https://issues.apache.org/jira/browse/SOLR-9105 > Project: Solr > Issue Type: Bug >Reporter: Bartosz Krasiński >Assignee: Jan Høydahl >Priority: Trivial > Fix For: 6.1 > > > Hello, > I wanted to fix one typo that I've found while reading the code, then I > decided to fix some more and that escalated a bit... > https://github.com/apache/lucene-solr/pull/39 -- 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-9105) Fix typos in solr core module
[ https://issues.apache.org/jira/browse/SOLR-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-9105: -- Fix Version/s: 6.1 > Fix typos in solr core module > - > > Key: SOLR-9105 > URL: https://issues.apache.org/jira/browse/SOLR-9105 > Project: Solr > Issue Type: Bug >Reporter: Bartosz Krasiński >Assignee: Jan Høydahl >Priority: Trivial > Fix For: 6.1 > > > Hello, > I wanted to fix one typo that I've found while reading the code, then I > decided to fix some more and that escalated a bit... > https://github.com/apache/lucene-solr/pull/39 -- 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-8097) Implement a builder pattern for constructing a Solrj client
[ https://issues.apache.org/jira/browse/SOLR-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280639#comment-15280639 ] Anshum Gupta commented on SOLR-8097: Yes but it was only fixed for 6.1. > Implement a builder pattern for constructing a Solrj client > --- > > Key: SOLR-8097 > URL: https://issues.apache.org/jira/browse/SOLR-8097 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Affects Versions: 6.0 >Reporter: Hrishikesh Gadre >Assignee: Anshum Gupta > Fix For: 6.0, 6.1 > > Attachments: SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, > SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, > SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, > SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch > > > Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors > as follows, > public CloudSolrClient(String zkHost) > public CloudSolrClient(String zkHost, HttpClient httpClient) > public CloudSolrClient(Collection zkHosts, String chroot) > public CloudSolrClient(Collection zkHosts, String chroot, HttpClient > httpClient) > public CloudSolrClient(String zkHost, boolean updatesToLeaders) > public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient > httpClient) > It is kind of problematic while introducing an additional parameters (since > we need to introduce additional constructors). Instead it will be helpful to > provide SolrClient Builder which can provide either default values or support > overriding specific parameter. -- 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-7279) AIOOBE from JapaneseTokenizer
[ https://issues.apache.org/jira/browse/LUCENE-7279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-7279: --- Attachment: LUCENE-7279.patch The bug is that {{unknownWordIndex}} needs to be reset per-parse and not per- input string. > AIOOBE from JapaneseTokenizer > - > > Key: LUCENE-7279 > URL: https://issues.apache.org/jira/browse/LUCENE-7279 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 6.1, master (7.0) > > Attachments: LUCENE-7279.patch > > > On certain Japanese input strings you can hit this: > {noformat} > java.lang.ArrayIndexOutOfBoundsException: -1 > at > __randomizedtesting.SeedInfo.seed([C6752A567B924B1:2B195610610ED60]:0) > at > org.apache.lucene.analysis.ja.JapaneseTokenizer.backtrace(JapaneseTokenizer.java:1607) > at > org.apache.lucene.analysis.ja.JapaneseTokenizer.parse(JapaneseTokenizer.java:902) > at > org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:479) > at > org.apache.lucene.analysis.ja.TestJapaneseTokenizer.testBigDocument(TestJapaneseTokenizer.java:837) > {noformat} > I have a patch with a test case and fix. -- 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-7279) AIOOBE from JapaneseTokenizer
Michael McCandless created LUCENE-7279: -- Summary: AIOOBE from JapaneseTokenizer Key: LUCENE-7279 URL: https://issues.apache.org/jira/browse/LUCENE-7279 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 6.1, master (7.0) On certain Japanese input strings you can hit this: {noformat} java.lang.ArrayIndexOutOfBoundsException: -1 at __randomizedtesting.SeedInfo.seed([C6752A567B924B1:2B195610610ED60]:0) at org.apache.lucene.analysis.ja.JapaneseTokenizer.backtrace(JapaneseTokenizer.java:1607) at org.apache.lucene.analysis.ja.JapaneseTokenizer.parse(JapaneseTokenizer.java:902) at org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:479) at org.apache.lucene.analysis.ja.TestJapaneseTokenizer.testBigDocument(TestJapaneseTokenizer.java:837) {noformat} I have a patch with a test case and fix. -- 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-8323) Add CollectionWatcher API to ZkStateReader
[ https://issues.apache.org/jira/browse/SOLR-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280582#comment-15280582 ] ASF GitHub Bot commented on SOLR-8323: -- Github user dragonsinth commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/32#discussion_r62900842 --- Diff: solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java --- @@ -1069,32 +1100,190 @@ public static String getCollectionPath(String coll) { return COLLECTIONS_ZKNODE+"/"+coll + "/state.json"; } - public void addCollectionWatch(String coll) { -if (interestingCollections.add(coll)) { - LOG.info("addZkWatch [{}]", coll); - new StateWatcher(coll).refreshAndWatch(false); + /** + * Notify this reader that a local Core is a member of a collection, and so that collection + * state should be watched. + * + * Not a public API. This method should only be called from ZkController. + * + * The number of cores per-collection is tracked, and adding multiple cores from the same + * collection does not increase the number of watches. + * + * @param collection the collection that the core is a member of + * + * @see ZkStateReader#unregisterCore(String) + */ + public void registerCore(String collection) { +AtomicBoolean reconstructState = new AtomicBoolean(false); +collectionWatches.compute(collection, (k, v) -> { + if (v == null) { +reconstructState.set(true); +v = new CollectionWatch(); + } + v.coreRefCount++; + return v; +}); +if (reconstructState.get()) { + new StateWatcher(collection).refreshAndWatch(); + synchronized (getUpdateLock()) { +constructState(); + } +} + } + + /** + * Notify this reader that a local core that is a member of a collection has been closed. + * + * Not a public API. This method should only be called from ZkController. + * + * If no cores are registered for a collection, and there are no {@link CollectionStateWatcher}s + * for that collection either, the collection watch will be removed. + * + * @param collection the collection that the core belongs to + */ + public void unregisterCore(String collection) { +AtomicBoolean reconstructState = new AtomicBoolean(false); +collectionWatches.compute(collection, (k, v) -> { + if (v == null) +return null; + if (v.coreRefCount > 0) +v.coreRefCount--; + if (v.canBeRemoved()) { +watchedCollectionStates.remove(collection); +lazyCollectionStates.put(collection, new LazyCollectionRef(collection)); +reconstructState.set(true); +return null; + } + return v; +}); +if (reconstructState.get()) { + synchronized (getUpdateLock()) { +constructState(); + } +} + } + + /** + * Register a CollectionStateWatcher to be called when the state of a collection changes + * + * A given CollectionStateWatcher will be only called once. If you want to have a persistent watcher, + * it should register itself again in its {@link CollectionStateWatcher#onStateChanged(Set, DocCollection)} + * method. + */ + public void registerCollectionStateWatcher(String collection, CollectionStateWatcher stateWatcher) { +AtomicBoolean watchSet = new AtomicBoolean(false); +collectionWatches.compute(collection, (k, v) -> { + if (v == null) { +v = new CollectionWatch(); +watchSet.set(true); + } + v.stateWatchers.add(stateWatcher); + return v; +}); +if (watchSet.get()) { + new StateWatcher(collection).refreshAndWatch(); --- End diff -- ditto, ignore this > Add CollectionWatcher API to ZkStateReader > -- > > Key: SOLR-8323 > URL: https://issues.apache.org/jira/browse/SOLR-8323 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.0 >Reporter: Alan Woodward >Assignee: Alan Woodward > Attachments: SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch, > SOLR-8323.patch > > > An API to watch for changes to collection state would be a generally useful > thing, both internally and for client use. -- 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-8323) Add CollectionWatcher API to ZkStateReader
[ https://issues.apache.org/jira/browse/SOLR-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280580#comment-15280580 ] ASF GitHub Bot commented on SOLR-8323: -- Github user dragonsinth commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/32#discussion_r62900820 --- Diff: solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java --- @@ -1069,32 +1100,190 @@ public static String getCollectionPath(String coll) { return COLLECTIONS_ZKNODE+"/"+coll + "/state.json"; } - public void addCollectionWatch(String coll) { -if (interestingCollections.add(coll)) { - LOG.info("addZkWatch [{}]", coll); - new StateWatcher(coll).refreshAndWatch(false); + /** + * Notify this reader that a local Core is a member of a collection, and so that collection + * state should be watched. + * + * Not a public API. This method should only be called from ZkController. + * + * The number of cores per-collection is tracked, and adding multiple cores from the same + * collection does not increase the number of watches. + * + * @param collection the collection that the core is a member of + * + * @see ZkStateReader#unregisterCore(String) + */ + public void registerCore(String collection) { +AtomicBoolean reconstructState = new AtomicBoolean(false); +collectionWatches.compute(collection, (k, v) -> { + if (v == null) { +reconstructState.set(true); +v = new CollectionWatch(); + } + v.coreRefCount++; + return v; +}); +if (reconstructState.get()) { + new StateWatcher(collection).refreshAndWatch(); --- End diff -- Ignore this, I'm dumb. You want a state watcher either way (the old code did this). > Add CollectionWatcher API to ZkStateReader > -- > > Key: SOLR-8323 > URL: https://issues.apache.org/jira/browse/SOLR-8323 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.0 >Reporter: Alan Woodward >Assignee: Alan Woodward > Attachments: SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch, > SOLR-8323.patch > > > An API to watch for changes to collection state would be a generally useful > thing, both internally and for client use. -- 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
[GitHub] lucene-solr pull request: SOLR-8323
Github user dragonsinth commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/32#discussion_r62900842 --- Diff: solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java --- @@ -1069,32 +1100,190 @@ public static String getCollectionPath(String coll) { return COLLECTIONS_ZKNODE+"/"+coll + "/state.json"; } - public void addCollectionWatch(String coll) { -if (interestingCollections.add(coll)) { - LOG.info("addZkWatch [{}]", coll); - new StateWatcher(coll).refreshAndWatch(false); + /** + * Notify this reader that a local Core is a member of a collection, and so that collection + * state should be watched. + * + * Not a public API. This method should only be called from ZkController. + * + * The number of cores per-collection is tracked, and adding multiple cores from the same + * collection does not increase the number of watches. + * + * @param collection the collection that the core is a member of + * + * @see ZkStateReader#unregisterCore(String) + */ + public void registerCore(String collection) { +AtomicBoolean reconstructState = new AtomicBoolean(false); +collectionWatches.compute(collection, (k, v) -> { + if (v == null) { +reconstructState.set(true); +v = new CollectionWatch(); + } + v.coreRefCount++; + return v; +}); +if (reconstructState.get()) { + new StateWatcher(collection).refreshAndWatch(); + synchronized (getUpdateLock()) { +constructState(); + } +} + } + + /** + * Notify this reader that a local core that is a member of a collection has been closed. + * + * Not a public API. This method should only be called from ZkController. + * + * If no cores are registered for a collection, and there are no {@link CollectionStateWatcher}s + * for that collection either, the collection watch will be removed. + * + * @param collection the collection that the core belongs to + */ + public void unregisterCore(String collection) { +AtomicBoolean reconstructState = new AtomicBoolean(false); +collectionWatches.compute(collection, (k, v) -> { + if (v == null) +return null; + if (v.coreRefCount > 0) +v.coreRefCount--; + if (v.canBeRemoved()) { +watchedCollectionStates.remove(collection); +lazyCollectionStates.put(collection, new LazyCollectionRef(collection)); +reconstructState.set(true); +return null; + } + return v; +}); +if (reconstructState.get()) { + synchronized (getUpdateLock()) { +constructState(); + } +} + } + + /** + * Register a CollectionStateWatcher to be called when the state of a collection changes + * + * A given CollectionStateWatcher will be only called once. If you want to have a persistent watcher, + * it should register itself again in its {@link CollectionStateWatcher#onStateChanged(Set, DocCollection)} + * method. + */ + public void registerCollectionStateWatcher(String collection, CollectionStateWatcher stateWatcher) { +AtomicBoolean watchSet = new AtomicBoolean(false); +collectionWatches.compute(collection, (k, v) -> { + if (v == null) { +v = new CollectionWatch(); +watchSet.set(true); + } + v.stateWatchers.add(stateWatcher); + return v; +}); +if (watchSet.get()) { + new StateWatcher(collection).refreshAndWatch(); --- End diff -- ditto, ignore this --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: SOLR-8323
Github user dragonsinth commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/32#discussion_r62900820 --- Diff: solr/solrj/src/java/org/apache/solr/common/cloud/ZkStateReader.java --- @@ -1069,32 +1100,190 @@ public static String getCollectionPath(String coll) { return COLLECTIONS_ZKNODE+"/"+coll + "/state.json"; } - public void addCollectionWatch(String coll) { -if (interestingCollections.add(coll)) { - LOG.info("addZkWatch [{}]", coll); - new StateWatcher(coll).refreshAndWatch(false); + /** + * Notify this reader that a local Core is a member of a collection, and so that collection + * state should be watched. + * + * Not a public API. This method should only be called from ZkController. + * + * The number of cores per-collection is tracked, and adding multiple cores from the same + * collection does not increase the number of watches. + * + * @param collection the collection that the core is a member of + * + * @see ZkStateReader#unregisterCore(String) + */ + public void registerCore(String collection) { +AtomicBoolean reconstructState = new AtomicBoolean(false); +collectionWatches.compute(collection, (k, v) -> { + if (v == null) { +reconstructState.set(true); +v = new CollectionWatch(); + } + v.coreRefCount++; + return v; +}); +if (reconstructState.get()) { + new StateWatcher(collection).refreshAndWatch(); --- End diff -- Ignore this, I'm dumb. You want a state watcher either way (the old code did this). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8878) Allow the DaemonStream run rate be controlled by the internal stream
[ https://issues.apache.org/jira/browse/SOLR-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280570#comment-15280570 ] Joel Bernstein commented on SOLR-8878: -- Yes, I'll take of it. > Allow the DaemonStream run rate be controlled by the internal stream > > > Key: SOLR-8878 > URL: https://issues.apache.org/jira/browse/SOLR-8878 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein > Fix For: 6.0, master (7.0) > > Attachments: SOLR-8878.patch, SOLR-8878.patch > > > Currently the DaemonStream sleeps for one second and then checks the > runInterval param to determine if it needs to rerun the internal stream. > This setup will work fine if the runInterval is longer then one second and if > it never changes. But with the TopicStream, you want a variable run rate. For > example if the TopicStream's latest run has returned documents, the next run > should be immediate. But if the TopicStream's latest run returned zero > documents then you'd want to sleep for a period of time before starting the > next run. > This ticket allows the internal stream to control the DaemonStream run rate > by adding a *sleepMillis* key-pair to the EOF Tuple. After each run the > DaemonStream will check the EOF Tuple from the internal stream and if the > sleepMillis key-pair is present it will adjust it's run rate accordingly. -- 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-8878) Allow the DaemonStream run rate be controlled by the internal stream
[ https://issues.apache.org/jira/browse/SOLR-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-8878: - Fix Version/s: master (7.0) > Allow the DaemonStream run rate be controlled by the internal stream > > > Key: SOLR-8878 > URL: https://issues.apache.org/jira/browse/SOLR-8878 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein > Fix For: 6.0, master (7.0) > > Attachments: SOLR-8878.patch, SOLR-8878.patch > > > Currently the DaemonStream sleeps for one second and then checks the > runInterval param to determine if it needs to rerun the internal stream. > This setup will work fine if the runInterval is longer then one second and if > it never changes. But with the TopicStream, you want a variable run rate. For > example if the TopicStream's latest run has returned documents, the next run > should be immediate. But if the TopicStream's latest run returned zero > documents then you'd want to sleep for a period of time before starting the > next run. > This ticket allows the internal stream to control the DaemonStream run rate > by adding a *sleepMillis* key-pair to the EOF Tuple. After each run the > DaemonStream will check the EOF Tuple from the internal stream and if the > sleepMillis key-pair is present it will adjust it's run rate accordingly. -- 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-8878) Allow the DaemonStream run rate be controlled by the internal stream
[ https://issues.apache.org/jira/browse/SOLR-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein resolved SOLR-8878. -- Resolution: Implemented > Allow the DaemonStream run rate be controlled by the internal stream > > > Key: SOLR-8878 > URL: https://issues.apache.org/jira/browse/SOLR-8878 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein > Fix For: 6.0 > > Attachments: SOLR-8878.patch, SOLR-8878.patch > > > Currently the DaemonStream sleeps for one second and then checks the > runInterval param to determine if it needs to rerun the internal stream. > This setup will work fine if the runInterval is longer then one second and if > it never changes. But with the TopicStream, you want a variable run rate. For > example if the TopicStream's latest run has returned documents, the next run > should be immediate. But if the TopicStream's latest run returned zero > documents then you'd want to sleep for a period of time before starting the > next run. > This ticket allows the internal stream to control the DaemonStream run rate > by adding a *sleepMillis* key-pair to the EOF Tuple. After each run the > DaemonStream will check the EOF Tuple from the internal stream and if the > sleepMillis key-pair is present it will adjust it's run rate accordingly. -- 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-8744) Overseer operations need more fine grained mutual exclusion
[ https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280534#comment-15280534 ] Scott Blum commented on SOLR-8744: -- Design looks good to me. One think to talk through, this may not be a problem per se, but I could imagine starvation becoming an issue. If a task is trying to lock the cluster it may never get to run if smaller tasks keep acquiring pieces of the lock tree. This may not be an issue in practice. > Overseer operations need more fine grained mutual exclusion > --- > > Key: SOLR-8744 > URL: https://issues.apache.org/jira/browse/SOLR-8744 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Scott Blum >Assignee: Noble Paul > Labels: sharding, solrcloud > > SplitShard creates a mutex over the whole collection, but, in practice, this > is a big scaling problem. Multiple split shard operations could happen at > the time time, as long as different shards are being split. In practice, > those shards often reside on different machines, so there's no I/O bottleneck > in those cases, just the mutex in Overseer forcing the operations to be done > serially. > Given that a single split can take many minutes on a large collection, this > is a bottleneck at scale. > Here is the proposed new design > There are various Collection operations performed at Overseer. They may need > exclusive access at various levels. Each operation must define the Access > level at which the access is required. Access level is an enum. > CLUSTER(0) > COLLECTION(1) > SHARD(2) > REPLICA(3) > The Overseer node maintains a tree of these locks. The lock tree would look > as follows. The tree can be created lazily as and when tasks come up. > {code} > Legend: > C1, C2 -> Collections > S1, S2 -> Shards > R1,R2,R3,R4 -> Replicas > Cluster > / \ >/ \ > C1 C2 > / \ / \ > / \ / \ >S1 S2 S1 S2 > R1, R2 R3.R4 R1,R2 R3,R4 > {code} > When the overseer receives a message, it tries to acquire the appropriate > lock from the tree. For example, if an operation needs a lock at a Collection > level and it needs to operate on Collection C1, the node C1 and all child > nodes of C1 must be free. > h2.Lock acquiring logic > Each operation would start from the root of the tree (Level 0 -> Cluster) and > start moving down depending upon the operation. After it reaches the right > node, it checks if all the children are free from a lock. If it fails to > acquire a lock, it remains in the work queue. A scheduler thread waits for > notification from the current set of tasks . Every task would do a > {{notify()}} on the monitor of the scheduler thread. The thread would start > from the head of the queue and check all tasks to see if that task is able to > acquire the right lock. If yes, it is executed, if not, the task is left in > the work queue. > When a new task arrives in the work queue, the schedulerthread wakes and just > try to schedule that task. -- 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-6.x-Linux (32bit/jdk1.8.0_92) - Build # 624 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/624/ Java: 32bit/jdk1.8.0_92 -server -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.handler.TestReqParamsAPI.test Error Message: Could not get expected value 'f' for path 'params/fixed' full output: { "responseHeader":{ "status":0, "QTime":0}, "params":{ "add":"second", "a":"A val", "fixed":"changeit", "b":"B val", "wt":"json"}, "context":{ "webapp":"/jb_nl/o", "path":"/dump1", "httpMethod":"GET"}}, from server: http://127.0.0.1:40964/jb_nl/o/collection1 Stack Trace: java.lang.AssertionError: Could not get expected value 'f' for path 'params/fixed' full output: { "responseHeader":{ "status":0, "QTime":0}, "params":{ "add":"second", "a":"A val", "fixed":"changeit", "b":"B val", "wt":"json"}, "context":{ "webapp":"/jb_nl/o", "path":"/dump1", "httpMethod":"GET"}}, from server: http://127.0.0.1:40964/jb_nl/o/collection1 at __randomizedtesting.SeedInfo.seed([3ADAA8E1EDBE26EC:B28E973B43424B14]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:457) at org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:242) at org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
Re: Lucene/Solr JIRA Fix Version question
There will be a few false positives for these two JIRA queries (commits that didn't fully fix the issue) but the three I listed above are there: Check for Git commit: project in (SOLR, LUCENE) AND status in (Open) and fixVersion is not empty and text ~ "in lucene-solr's branch refs/heads/" order by updated Check for older SVN commit: project in (SOLR, LUCENE) AND status in (Open) and fixVersion is not empty and text ~ "in branch 'dev/trunk'" order by updated Kevin Risden On Wed, May 11, 2016 at 12:07 PM, Kevin Risdenwrote: > Here are three that I just happened upon and was semi familiar with: > * SOLR-8097 > * SOLR-9058 > * SOLR-8878 > > Looks like they just need to be resolved properly and fix the fixVersion. > > there might be just as many open issues w/o a fixVersion that warrant >> equal review/edits. > > > Yea that is probably true. I The recent work on JIRA and "Street Light > Effect" as you say can be good to get JIRA cleaned up further :) > > I don't plan on putting much effort into it currently but definitely > opened my eyes to what more can be done. > > Kevin Risden > > On Wed, May 11, 2016 at 11:49 AM, Chris Hostetter < > hossman_luc...@fucit.org> wrote: > >> >> : I wasn't suggesting a blanket resolve of issues. There are a few that I >> : looked at that should have been resolved and weren't. This would require >> : some manual effort. >> >> can you give some examples? >> >> I was reading "resolved" as "FIXED" but if you're talking about issues >> that could/should be marked WONT_FIX or CANT_REPRO or DUP then i suspect >> you're just falling for the "Street Light Effect" ... the recent work and >> 6.0 happened to catch your eye, and you notice some of those open 6.0 >> issues could/should be resolved, but that doesn't mean there is anything >> special about open issues with 6.0 set on them ... there might be just as >> many open issues w/o a fixVersion that warrant equal review/edits. >> >> : Since there isn't a problem here that open and fixVersion doesn't mean >> : anything together, I'm fine with just leaving as is. >> >> I don't think there is, and i don't subscribe any meaning to it, but >> that's just my opinion. >> >> if other folks *want* to subscribe meaning to it that will be an uphill >> battle unless some work is done to change our workflow and lock down jira >> to prevent arbitrary fixVersons from bieng added to issues. >> >> >> -Hoss >> http://www.lucidworks.com/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >
[jira] [Commented] (SOLR-8878) Allow the DaemonStream run rate be controlled by the internal stream
[ https://issues.apache.org/jira/browse/SOLR-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280464#comment-15280464 ] Hoss Man commented on SOLR-8878: [~joel.bernstein] - should this be resolved? > Allow the DaemonStream run rate be controlled by the internal stream > > > Key: SOLR-8878 > URL: https://issues.apache.org/jira/browse/SOLR-8878 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein > Fix For: 6.0 > > Attachments: SOLR-8878.patch, SOLR-8878.patch > > > Currently the DaemonStream sleeps for one second and then checks the > runInterval param to determine if it needs to rerun the internal stream. > This setup will work fine if the runInterval is longer then one second and if > it never changes. But with the TopicStream, you want a variable run rate. For > example if the TopicStream's latest run has returned documents, the next run > should be immediate. But if the TopicStream's latest run returned zero > documents then you'd want to sleep for a period of time before starting the > next run. > This ticket allows the internal stream to control the DaemonStream run rate > by adding a *sleepMillis* key-pair to the EOF Tuple. After each run the > DaemonStream will check the EOF Tuple from the internal stream and if the > sleepMillis key-pair is present it will adjust it's run rate accordingly. -- 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-9058) hashJoin does not work when "on" maps fields with "="
[ https://issues.apache.org/jira/browse/SOLR-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280462#comment-15280462 ] Hoss Man commented on SOLR-9058: [~dpgove] - should this be resolved? > hashJoin does not work when "on" maps fields with "=" > - > > Key: SOLR-9058 > URL: https://issues.apache.org/jira/browse/SOLR-9058 > Project: Solr > Issue Type: Bug >Affects Versions: 6.0 >Reporter: Stephan Osthold >Assignee: Dennis Gove >Priority: Minor > Fix For: 6.0, 6.1 > > Attachments: SOLR-9058.patch > > > hashJoin does not work when "on" maps fields with "=" > eg. > hashJoin( > ... > on="field1=field2" > ) > See link for fix. -- 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-8097) Implement a builder pattern for constructing a Solrj client
[ https://issues.apache.org/jira/browse/SOLR-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280444#comment-15280444 ] Hoss Man commented on SOLR-8097: [~anshumg] - shouldn't this issue be resolved? > Implement a builder pattern for constructing a Solrj client > --- > > Key: SOLR-8097 > URL: https://issues.apache.org/jira/browse/SOLR-8097 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Affects Versions: 6.0 >Reporter: Hrishikesh Gadre >Assignee: Anshum Gupta > Fix For: 6.0, 6.1 > > Attachments: SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, > SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, > SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, > SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch > > > Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors > as follows, > public CloudSolrClient(String zkHost) > public CloudSolrClient(String zkHost, HttpClient httpClient) > public CloudSolrClient(Collection zkHosts, String chroot) > public CloudSolrClient(Collection zkHosts, String chroot, HttpClient > httpClient) > public CloudSolrClient(String zkHost, boolean updatesToLeaders) > public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient > httpClient) > It is kind of problematic while introducing an additional parameters (since > we need to introduce additional constructors). Instead it will be helpful to > provide SolrClient Builder which can provide either default values or support > overriding specific parameter. -- 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-8945) When numerical field is sent an incorrect data type, exception could be more descriptive.
[ https://issues.apache.org/jira/browse/SOLR-8945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280443#comment-15280443 ] Binoy Dalal commented on SOLR-8945: --- Garth, I've reviewed this issue from the perpective of changing the code. The exception is thrown by a general catch i.e., {code}catch( Exception ex ){code} in DocumentBuilder.java Since this is a blanket catch for a lot of different runtime exceptions, I don't think that changing this for one particular case makes sense, and the cause is already being thrown. It's just less readble is all. So, I think that you should close this issue. > When numerical field is sent an incorrect data type, exception could be more > descriptive. > - > > Key: SOLR-8945 > URL: https://issues.apache.org/jira/browse/SOLR-8945 > Project: Solr > Issue Type: Improvement >Reporter: Garth Grimm >Priority: Minor > > While indexing from a database, solr automatically created some id fields as > `tlong`. These fields could either contain a number or a message like 'Not > Available' if that particular id/number was not present. > In such a case, solr threw an error similar to: > ERROR: [doc=People-139728] Error adding field 'Office_PhoneNo'='603 103' > msg=For input string: "603 103" > In such a case, the intuitive thing would be to throw a NumberFormatException > so that the user can easily figure out that a number field is receiving > non-numeric values. -- 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
Re: Lucene/Solr JIRA Fix Version question
Here are three that I just happened upon and was semi familiar with: * SOLR-8097 * SOLR-9058 * SOLR-8878 Looks like they just need to be resolved properly and fix the fixVersion. there might be just as many open issues w/o a fixVersion that warrant equal > review/edits. Yea that is probably true. I The recent work on JIRA and "Street Light Effect" as you say can be good to get JIRA cleaned up further :) I don't plan on putting much effort into it currently but definitely opened my eyes to what more can be done. Kevin Risden On Wed, May 11, 2016 at 11:49 AM, Chris Hostetterwrote: > > : I wasn't suggesting a blanket resolve of issues. There are a few that I > : looked at that should have been resolved and weren't. This would require > : some manual effort. > > can you give some examples? > > I was reading "resolved" as "FIXED" but if you're talking about issues > that could/should be marked WONT_FIX or CANT_REPRO or DUP then i suspect > you're just falling for the "Street Light Effect" ... the recent work and > 6.0 happened to catch your eye, and you notice some of those open 6.0 > issues could/should be resolved, but that doesn't mean there is anything > special about open issues with 6.0 set on them ... there might be just as > many open issues w/o a fixVersion that warrant equal review/edits. > > : Since there isn't a problem here that open and fixVersion doesn't mean > : anything together, I'm fine with just leaving as is. > > I don't think there is, and i don't subscribe any meaning to it, but > that's just my opinion. > > if other folks *want* to subscribe meaning to it that will be an uphill > battle unless some work is done to change our workflow and lock down jira > to prevent arbitrary fixVersons from bieng added to issues. > > > -Hoss > http://www.lucidworks.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Updated] (SOLR-9105) Fix typos in solr core module
[ https://issues.apache.org/jira/browse/SOLR-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Krasiński updated SOLR-9105: Issue Type: Bug (was: Improvement) > Fix typos in solr core module > - > > Key: SOLR-9105 > URL: https://issues.apache.org/jira/browse/SOLR-9105 > Project: Solr > Issue Type: Bug >Reporter: Bartosz Krasiński >Priority: Trivial > > Hello, > I wanted to fix one typo that I've found while reading the code, then I > decided to fix some more and that escalated a bit... > https://github.com/apache/lucene-solr/pull/39 -- 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-9105) Fix typos
[ https://issues.apache.org/jira/browse/SOLR-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Krasiński updated SOLR-9105: Description: Hello, I wanted to fix one typo that I've found while reading the code, then I decided to fix some more and that escalated a bit... https://github.com/apache/lucene-solr/pull/39 was: Hello, I wanted to fix one typo that I've found while reading the code, then I decided to fix some more and that escalated a bit... > Fix typos > - > > Key: SOLR-9105 > URL: https://issues.apache.org/jira/browse/SOLR-9105 > Project: Solr > Issue Type: Improvement >Reporter: Bartosz Krasiński >Priority: Trivial > > Hello, > I wanted to fix one typo that I've found while reading the code, then I > decided to fix some more and that escalated a bit... > https://github.com/apache/lucene-solr/pull/39 -- 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-9105) Fix typos in solr core module
[ https://issues.apache.org/jira/browse/SOLR-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Krasiński updated SOLR-9105: Summary: Fix typos in solr core module (was: Fix typos) > Fix typos in solr core module > - > > Key: SOLR-9105 > URL: https://issues.apache.org/jira/browse/SOLR-9105 > Project: Solr > Issue Type: Improvement >Reporter: Bartosz Krasiński >Priority: Trivial > > Hello, > I wanted to fix one typo that I've found while reading the code, then I > decided to fix some more and that escalated a bit... > https://github.com/apache/lucene-solr/pull/39 -- 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-9105) Fix typos
[ https://issues.apache.org/jira/browse/SOLR-9105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280437#comment-15280437 ] ASF GitHub Bot commented on SOLR-9105: -- GitHub user krasinski opened a pull request: https://github.com/apache/lucene-solr/pull/39 [SOLR-9105] Fix some typos in solr core module You can merge this pull request into a Git repository by running: $ git pull https://github.com/krasinski/lucene-solr fix_typos Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/39.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #39 commit 6def4f364d14efb5d97fd15a8fb6b71d0e8eff54 Author: Bartosz KrasińskiDate: 2016-05-11T17:02:07Z [SOLR-9105] Fix some typos in solr core module > Fix typos > - > > Key: SOLR-9105 > URL: https://issues.apache.org/jira/browse/SOLR-9105 > Project: Solr > Issue Type: Improvement >Reporter: Bartosz Krasiński >Priority: Trivial > > Hello, > I wanted to fix one typo that I've found while reading the code, then I > decided to fix some more and that escalated a bit... -- 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
[GitHub] lucene-solr pull request: [SOLR-9105] Fix some typos in solr core ...
GitHub user krasinski opened a pull request: https://github.com/apache/lucene-solr/pull/39 [SOLR-9105] Fix some typos in solr core module You can merge this pull request into a Git repository by running: $ git pull https://github.com/krasinski/lucene-solr fix_typos Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/39.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #39 commit 6def4f364d14efb5d97fd15a8fb6b71d0e8eff54 Author: Bartosz KrasiÅskiDate: 2016-05-11T17:02:07Z [SOLR-9105] Fix some typos in solr core module --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9105) Fix typos
Bartosz Krasiński created SOLR-9105: --- Summary: Fix typos Key: SOLR-9105 URL: https://issues.apache.org/jira/browse/SOLR-9105 Project: Solr Issue Type: Improvement Reporter: Bartosz Krasiński Priority: Trivial Hello, I wanted to fix one typo that I've found while reading the code, then I decided to fix some more and that escalated a bit... -- 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-8940) ArrayIndexOutOfBoundsException in TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0
[ https://issues.apache.org/jira/browse/SOLR-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-8940: - Fix Version/s: (was: 5.5.1) (was: 6.0) > ArrayIndexOutOfBoundsException in > TopGroupsResultTransformer.transformToNativeShardDoc after upgrading to 5.5.0 > --- > > Key: SOLR-8940 > URL: https://issues.apache.org/jira/browse/SOLR-8940 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 5.5 >Reporter: Henrik >Priority: Blocker > Labels: 5.5, arrayindexoutofbounds, exception, query, search > Attachments: schema-types.xml, schema.xml, solr-query-exception.txt, > solrconfig.xml > > > We get an ArrayIndexOutOfBoundsException when searching after upgrading to > solr 5.5. > Here's the query: > {code} > "params":{ > "q":"*:*", > "group.sort":"priceAmount asc,rnd desc", > "indent":"on", > "fl":"priceAmount,flightTripId,brand,slob,cabinType,tripDuration", > "group.limit":"100", > "fq":["searchId:e31a0c58-9056-4297-8d70-049017ba4906", > "doctype:offer", > "flightTripId:(DY6020421-SK2360519 OR DY6020421-SK2600519 OR > DY6020421-SK2620519 OR DY6020421-SK2740519 OR DY6020421-SK2900519 OR > DY6020421-SK2860519 OR DY6040421-SK2380519 OR DY6040421-SK2440519 OR > DY6040421-SK2480519 OR DY6040421-SK2520519 OR DY6040421-SK2600519 OR > DY6040421-SK2620519 OR DY6040421-SK2720519 OR DY6040421-SK2740519 OR > DY6040421-SK2800519 OR DY6040421-SK2840519 OR DY6040421-SK2820519 OR > DY6060421-SK2480519 OR DY6060421-SK2740519 OR DY6060421-SK2800519 OR > DY6060421-SK2840519 OR DY6060421-SK2900519 OR DY6060421-SK2860519 OR > DY6060421-SK2820519 OR DY6080421-SK2440519)", > "maximumLegDuration:[* TO 180]", > "departureAirportLeg1:(OSL)", > "(arrivalAirportLeg2:(OSL) OR (* NOT arrivalAirportLeg2:*))", > "arrivalAirportLeg1:(BGO)", > "(departureAirportLeg2:(BGO) OR (* NOT departureAirportLeg2:*))"], > "group.ngroups":"true", > "wt":"json", > "group.field":"flightTripId", > "group":"true"}} > {code} > And here's the exception: > {code} > ERROR [20160404T104846,333] qtp315138752-3037 > org.apache.solr.servlet.HttpSolrCall - > null:java.lang.ArrayIndexOutOfBoundsException: 1 > at > org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNativeShardDoc(TopGroupsResultTransformer.java:175) > at > org.apache.solr.search.grouping.distributed.shardresultserializer.TopGroupsResultTransformer.transformToNative(TopGroupsResultTransformer.java:137) > at > org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:129) > at > org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:750) > at > org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:733) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:405) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082) > {code} > The exception is thrown at the last line here: > {code} > protected ScoreDoc[] transformToNativeShardDoc(List> documents, Sort groupSort, String shard, > IndexSchema schema) { > [...] > for (NamedList document : documents) { > [...] > Object sortValuesVal = document.get("sortValues"); > if (sortValuesVal != null) { > sortValues = ((List) sortValuesVal).toArray(); > for (int k = 0; k < sortValues.length; k++) { > SchemaField field = groupSort.getSort()[k].getField() != null > ? schema.getFieldOrNull(groupSort.getSort()[k].getField()) : > null; > {code} > It's not obvious to me that {{sortValues.length == > groupSort.getSort().length}}, but I guess there's some logic behind it :) > I have attached the schema and json result. > The problem disappears when rolling back to 5.4.0. -- 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-SmokeRelease-master - Build # 488 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/488/ No tests ran. Build Log: [...truncated 40519 lines...] prepare-release-no-sign: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist [copy] Copying 476 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 245 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.01 sec (18.6 MB/sec) [smoker] check changes HTML... [smoker] download lucene-7.0.0-src.tgz... [smoker] 28.6 MB in 0.03 sec (858.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.0.0.tgz... [smoker] 63.0 MB in 0.06 sec (1058.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-7.0.0.zip... [smoker] 73.5 MB in 0.09 sec (807.6 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-7.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6003 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6003 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-7.0.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 218 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] Releases that don't seem to be tested: [smoker] 5.5.1 [smoker] Traceback (most recent call last): [smoker] File "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py", line 1414, in [smoker] main() [smoker] File "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py", line 1358, in main [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' '.join(c.test_args)) [smoker] File "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py", line 1396, in smokeTest [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % version, gitRevision, version, testArgs, baseURL) [smoker] File "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py", line 590, in unpackAndVerify [smoker] verifyUnpacked(java, project, artifact, unpackPath, gitRevision, version, testArgs, tmpDir, baseURL) [smoker] File "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py", line 736, in verifyUnpacked [smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath) [smoker] File "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py", line 1351, in confirmAllReleasesAreTestedForBackCompat [smoker] raise RuntimeError('some releases are not tested by TestBackwardsCompatibility?') [smoker] RuntimeError: some releases are not tested by TestBackwardsCompatibility? BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/build.xml:536: exec returned: 1 Total time: 31 minutes 30 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene/Solr JIRA Fix Version question
: I wasn't suggesting a blanket resolve of issues. There are a few that I : looked at that should have been resolved and weren't. This would require : some manual effort. can you give some examples? I was reading "resolved" as "FIXED" but if you're talking about issues that could/should be marked WONT_FIX or CANT_REPRO or DUP then i suspect you're just falling for the "Street Light Effect" ... the recent work and 6.0 happened to catch your eye, and you notice some of those open 6.0 issues could/should be resolved, but that doesn't mean there is anything special about open issues with 6.0 set on them ... there might be just as many open issues w/o a fixVersion that warrant equal review/edits. : Since there isn't a problem here that open and fixVersion doesn't mean : anything together, I'm fine with just leaving as is. I don't think there is, and i don't subscribe any meaning to it, but that's just my opinion. if other folks *want* to subscribe meaning to it that will be an uphill battle unless some work is done to change our workflow and lock down jira to prevent arbitrary fixVersons from bieng added to issues. -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene/Solr JIRA Fix Version question
> TLDR: I don't think it's worth any time/effort to worry about fixVersion > for open issues. > Thats fair and your explanation makes a lot of sense. I'm not sure why you think it would be a good idea to blanket resolve > issues with older fix versions -- that seems to be confusing cause with > effect (ie: just because someone set the fixVersion=6.0 doesn't mean the > bug was magically fixed or a feature was magically added) I wasn't suggesting a blanket resolve of issues. There are a few that I looked at that should have been resolved and weren't. This would require some manual effort. The reason I did that search was I saw a bunch of issues now have the fixVersion as 6.0 even when they are still open. I never really took a second look at the issues before since many of them were master and are now fixVersion==6.0. Since there isn't a problem here that open and fixVersion doesn't mean anything together, I'm fine with just leaving as is. Kevin Risden
Re: Lucene/Solr JIRA Fix Version question
TLDR: I don't think it's worth any time/effort to worry about fixVersion for open issues. : project in (SOLR,LUCENE) and status in (Open) and fixVersion IS NOT EMPTY : : Does it make sense that there are so many issues that are open and have a : fixVersion that is not empty? Yes, there are lots of reasons why an Open issue might have a fixVersion set -- it's not really an indication of a problem. When folks resolve issues, that's when it's really important to make sure the fixVersion is set correctly. Typically what happens is... 1) the person who filed the issue ambitiously/optimistically set the fixVersion to a particular X.Y in the *hope* that it would be fixed in that version, and it's never been updated since. OR 2) people actively working on an issue set the fixVersion to help remind themselves, or signal to others, that they intend to backport to particular branches in time for particular releases. ...but it's not really obvious from any particular jira search when/why a bunch of issues have a particular fixVersion, you have to look at individual issues. : I think these issues fall into a few categories (may have missed a few : cases): : : * Fix Version < 6.0 - should either be resolved or have the fix version : removed since < 6.0 was released : * Fix Version == 6.0 - should be resolved or have the fix version removed : (most of the cases due to LUCENE-7271) : * Fix Version == 6.1 - assuming these are currently being worked on or : resolved if committed? : * Fix Version == master (7.0) - resolve or remove fix version? I'm not sure why you think it would be a good idea to blanket resolve issues with older fix versions -- that seems to be confusing cause with effect (ie: just because someone set the fixVersion=6.0 doesn't mean the bug was magically fixed or a feature was magically added) If you are looking to make a bulk change I suppose we could just wipe the fixVersion from all unresolved issues, but that seems like trying to bail out a boat with a massive hole in the bottom using an even more massive bucket -- you might get all the water out today, but there won't be naything to stop the flood of water that comes in on a regular basis. -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8858) SolrIndexSearcher#doc() Completely Ignores Field Filters Unless Lazy Field Loading is Enabled
[ https://issues.apache.org/jira/browse/SOLR-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated SOLR-8858: -- Fix Version/s: (was: 5.5.1) > SolrIndexSearcher#doc() Completely Ignores Field Filters Unless Lazy Field > Loading is Enabled > - > > Key: SOLR-8858 > URL: https://issues.apache.org/jira/browse/SOLR-8858 > Project: Solr > Issue Type: Bug >Affects Versions: 4.6, 4.10, 5.5 >Reporter: Caleb Rackliffe > Labels: easyfix > > If {{enableLazyFieldLoading=false}}, a perfectly valid fields filter will be > ignored, and we'll create a {{DocumentStoredFieldVisitor}} without it. -- 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-8661) Upgrade guava version to 18.0 due to Presto dependency
[ https://issues.apache.org/jira/browse/SOLR-8661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280338#comment-15280338 ] Kevin Risden commented on SOLR-8661: Added a link to SOLR-8661 that has some discussion around upgrading Guava. > Upgrade guava version to 18.0 due to Presto dependency > -- > > Key: SOLR-8661 > URL: https://issues.apache.org/jira/browse/SOLR-8661 > Project: Solr > Issue Type: Task > Components: Parallell SQL >Reporter: Jan Høydahl >Priority: Minor > Labels: sql, streaming_api > > The Presto parser depends on {{com.google.guava/guava 18.0}}, and Solr > currently uses 14.0.1. I have seen a Class not found exception for some > {{com.google.common.base}} classes when playing with Parallell SQL. -- 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-8661) Upgrade guava version to 18.0 due to Presto dependency
[ https://issues.apache.org/jira/browse/SOLR-8661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280338#comment-15280338 ] Kevin Risden edited comment on SOLR-8661 at 5/11/16 4:06 PM: - Added a link to SOLR-5584 that has some discussion around upgrading Guava. was (Author: risdenk): Added a link to SOLR-8661 that has some discussion around upgrading Guava. > Upgrade guava version to 18.0 due to Presto dependency > -- > > Key: SOLR-8661 > URL: https://issues.apache.org/jira/browse/SOLR-8661 > Project: Solr > Issue Type: Task > Components: Parallell SQL >Reporter: Jan Høydahl >Priority: Minor > Labels: sql, streaming_api > > The Presto parser depends on {{com.google.guava/guava 18.0}}, and Solr > currently uses 14.0.1. I have seen a Class not found exception for some > {{com.google.common.base}} classes when playing with Parallell SQL. -- 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] [Closed] (SOLR-5798) Update to Hadoop 2.3.0
[ https://issues.apache.org/jira/browse/SOLR-5798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden closed SOLR-5798. -- Resolution: Duplicate Fix Version/s: (was: 6.0) (was: 4.9) > Update to Hadoop 2.3.0 > -- > > Key: SOLR-5798 > URL: https://issues.apache.org/jira/browse/SOLR-5798 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller > -- 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-6.x-MacOSX (64bit/jdk1.8.0) - Build # 130 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/130/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 53567 lines...] BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:740: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:101: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build.xml:138: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build.xml:480: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:2520: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:209) at java.net.SocketInputStream.read(SocketInputStream.java:141) at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) at sun.security.ssl.InputRecord.read(InputRecord.java:503) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) at org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660) at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579) at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569) Total time: 105 minutes 35 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8593) Integrate Apache Calcite into the SQLHandler
[ https://issues.apache.org/jira/browse/SOLR-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-8593: --- Fix Version/s: (was: 6.0) > Integrate Apache Calcite into the SQLHandler > > > Key: SOLR-8593 > URL: https://issues.apache.org/jira/browse/SOLR-8593 > Project: Solr > Issue Type: Improvement >Reporter: Joel Bernstein > > The Presto SQL Parser was perfect for phase one of the SQLHandler. It was > nicely split off from the larger Presto project and it did everything that > was needed for the initial implementation. > Phase two of the SQL work though will require an optimizer. Here is where > Apache Calcite comes into play. It has a battle tested cost based optimizer > and has been integrated into Apache Drill and Hive. > This work can begin in trunk following the 6.0 release. The final query plans > will continue to be translated to Streaming API objects (TupleStreams), so > continued work on the JDBC driver should plug in nicely with the Calcite work. -- 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-6.x - Build # 196 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/196/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI Error Message: ObjectTracker found 4 object(s) that were not released!!! [MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 4 object(s) that were not released!!! [MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, TransactionLog] at __randomizedtesting.SeedInfo.seed([2A7D33E00EFCF64C]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:256) at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 10840 lines...] [junit4] Suite: org.apache.solr.schema.TestManagedSchemaAPI [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-6.x/solr/build/solr-core/test/J1/temp/solr.schema.TestManagedSchemaAPI_2A7D33E00EFCF64C-001/init-core-data-001 [junit4] 2> 447843 INFO (SUITE-TestManagedSchemaAPI-seed#[2A7D33E00EFCF64C]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) [junit4] 2> 447844 INFO (SUITE-TestManagedSchemaAPI-seed#[2A7D33E00EFCF64C]-worker) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 447844 INFO (Thread-1068) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 447844 INFO (Thread-1068) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 447944 INFO (SUITE-TestManagedSchemaAPI-seed#[2A7D33E00EFCF64C]-worker) [] o.a.s.c.ZkTestServer start zk server on port:37399 [junit4] 2> 447944 INFO (SUITE-TestManagedSchemaAPI-seed#[2A7D33E00EFCF64C]-worker) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 447945 INFO (SUITE-TestManagedSchemaAPI-seed#[2A7D33E00EFCF64C]-worker) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 447947 INFO (zkCallback-582-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@5fd235e8 name:ZooKeeperConnection Watcher:127.0.0.1:37399 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 447947 INFO (SUITE-TestManagedSchemaAPI-seed#[2A7D33E00EFCF64C]-worker) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 447947 INFO (SUITE-TestManagedSchemaAPI-seed#[2A7D33E00EFCF64C]-worker) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2>
[jira] [Updated] (SOLR-8608) Improve SolrJ JDBC testing
[ https://issues.apache.org/jira/browse/SOLR-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-8608: --- Fix Version/s: (was: 6.0) > Improve SolrJ JDBC testing > -- > > Key: SOLR-8608 > URL: https://issues.apache.org/jira/browse/SOLR-8608 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Affects Versions: 6.0 >Reporter: Kevin Risden > > Currently JDBC testing isn't randomized between facet and map_reduce. There > could be a lot done here to improve the JDBC testing. -- 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-8613) SolrJ JDBC - SQL queries with limit do not fail when a bad column is provided
[ https://issues.apache.org/jira/browse/SOLR-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-8613: --- Fix Version/s: (was: 6.0) > SolrJ JDBC - SQL queries with limit do not fail when a bad column is provided > - > > Key: SOLR-8613 > URL: https://issues.apache.org/jira/browse/SOLR-8613 > Project: Solr > Issue Type: Bug > Components: SolrJ >Affects Versions: 6.0 >Reporter: Kevin Risden > > This was found exporting SOLR-8602. Without a limit, the query fails with > unable to read the first tuple due to a bad column being provided. When using > a limit, there is no error and the column is returned as all nulls. -- 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-8806) NPE Exporting request handler
[ https://issues.apache.org/jira/browse/SOLR-8806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-8806: --- Fix Version/s: (was: 6.1) (was: 6.0) > NPE Exporting request handler > - > > Key: SOLR-8806 > URL: https://issues.apache.org/jira/browse/SOLR-8806 > Project: Solr > Issue Type: Bug >Affects Versions: 5.5 >Reporter: Markus Jelsma > > Tried exporting request handler for dumping an entire index (which wasn't > going to work because of docValues not on all fields, too bad). Got two > distinct NPE's in SortingResponseWriter for sort by int and sort by string. > Sort by int: > {code} > o.a.s.s.HttpSolrCall null:java.lang.NullPointerException > at > org.apache.solr.response.SortingResponseWriter$IntValue.setCurrentValue(SortingResponseWriter.java:797) > at > org.apache.solr.response.SortingResponseWriter$SingleValueSortDoc.setValues(SortingResponseWriter.java:472) > at > org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:141) > at > org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:52) > at > org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:743) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:467) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:225) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:183) > {code} > Sort by string, which is a bit different: > {code} > o.a.s.s.HttpSolrCall null:java.io.IOException: java.lang.NullPointerException > at > org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:185) > at > org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:52) > at > org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:743) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:467) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:225) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:183) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:499) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at > org.apache.solr.response.SortingResponseWriter$StringFieldWriter.write(SortingResponseWriter.java:1289) > at > org.apache.solr.response.SortingResponseWriter.writeDoc(SortingResponseWriter.java:222) > at > org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:167) > ... 25 more > {code} -- 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-8462) Improve error reporting for /stream handler
[ https://issues.apache.org/jira/browse/SOLR-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-8462: --- Fix Version/s: (was: 6.0) > Improve error reporting for /stream handler > --- > > Key: SOLR-8462 > URL: https://issues.apache.org/jira/browse/SOLR-8462 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.0 >Reporter: Jason Gerlowski >Assignee: Joel Bernstein >Priority: Trivial > Attachments: SOLR-8462.patch, SOLR-8462.patch > > > Currently, the /stream request handler reports errors by adding an > "EXCEPTION" name/value pair on a tuple in the TupleStream where the error > arose. The "value" in this name/value pair is the message attached to the > exception. > This works well in most instances, however it could be better in a few ways: > 1.) Not all exceptions have messages. For instance, > {{NullPointerExceptions}} and other run time exceptions fall into this > category. This causes the /stream handler to return the relatively unhelpful > value: {"EXCEPTION":null,"EOF":true}. The /stream handler should make sure > the exception has a message, and if not, it should report some other > information about the error (exception class name?). > 2.) There are some common error cases that can arise from mis-use of the API. > For instance, if the 'expr' parameter is missing. Detecting and handling > these cases specifically would allow users to get back clearer, more useful > error messages. -- 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-8969) SQLHandler causes NPE in non-cloud mode
[ https://issues.apache.org/jira/browse/SOLR-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-8969: --- Fix Version/s: (was: 6.0) > SQLHandler causes NPE in non-cloud mode > --- > > Key: SOLR-8969 > URL: https://issues.apache.org/jira/browse/SOLR-8969 > Project: Solr > Issue Type: Bug > Components: Parallell SQL >Affects Versions: 6.0 >Reporter: Markus Jelsma >Priority: Minor > > It should instead throw a proper error message. Stack trace: > {code} > 1233075 INFO (qtp97730845-21) [ x:logs] o.a.s.c.S.Request [logs] > webapp=/solr path=/sql params={stmt=SELECT+uid+FROM+logs} status=0 QTime=18 > 1233095 INFO (qtp97730845-21) [ x:logs] o.a.s.c.c.SolrZkClient Using > default ZkCredentialsProvider > 1233109 ERROR (qtp97730845-21) [ x:logs] o.a.s.c.s.i.s.ExceptionStream > org.apache.solr.common.SolrException: java.lang.NullPointerException > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:169) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115) > at > org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:105) > at > org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:200) > at > org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:466) > at > org.apache.solr.client.solrj.io.SolrClientCache.getCloudSolrClient(SolrClientCache.java:48) > at > org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:237) > at > org.apache.solr.client.solrj.io.stream.SelectStream.open(SelectStream.java:153) > at > org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:47) > at > org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:362) > at > org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:301) > at > org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167) > at > org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183) > at > org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299) > at > org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95) > at > org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60) > at > org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65) > at > org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:725) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:469) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) > at org.eclipse.jetty.server.Server.handle(Server.java:518) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) > at > org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) > at >
[jira] [Commented] (SOLR-8462) Improve error reporting for /stream handler
[ https://issues.apache.org/jira/browse/SOLR-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280311#comment-15280311 ] Kevin Risden commented on SOLR-8462: [~gerlowskija] - Is it possible to add some tests to exercise these cases? I know I have run into some NPEs and other unhelpful messages when developing as well. > Improve error reporting for /stream handler > --- > > Key: SOLR-8462 > URL: https://issues.apache.org/jira/browse/SOLR-8462 > Project: Solr > Issue Type: Improvement >Affects Versions: 6.0 >Reporter: Jason Gerlowski >Assignee: Joel Bernstein >Priority: Trivial > Fix For: 6.0 > > Attachments: SOLR-8462.patch, SOLR-8462.patch > > > Currently, the /stream request handler reports errors by adding an > "EXCEPTION" name/value pair on a tuple in the TupleStream where the error > arose. The "value" in this name/value pair is the message attached to the > exception. > This works well in most instances, however it could be better in a few ways: > 1.) Not all exceptions have messages. For instance, > {{NullPointerExceptions}} and other run time exceptions fall into this > category. This causes the /stream handler to return the relatively unhelpful > value: {"EXCEPTION":null,"EOF":true}. The /stream handler should make sure > the exception has a message, and if not, it should report some other > information about the error (exception class name?). > 2.) There are some common error cases that can arise from mis-use of the API. > For instance, if the 'expr' parameter is missing. Detecting and handling > these cases specifically would allow users to get back clearer, more useful > error messages. -- 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
Lucene/Solr JIRA Fix Version question
I performed the following JIRA search and found ~955 issues: project in (SOLR,LUCENE) and status in (Open) and fixVersion IS NOT EMPTY Does it make sense that there are so many issues that are open and have a fixVersion that is not empty? I think these issues fall into a few categories (may have missed a few cases): * Fix Version < 6.0 - should either be resolved or have the fix version removed since < 6.0 was released * Fix Version == 6.0 - should be resolved or have the fix version removed (most of the cases due to LUCENE-7271) * Fix Version == 6.1 - assuming these are currently being worked on or resolved if committed? * Fix Version == master (7.0) - resolve or remove fix version? Since LUCENE-7271 was completed, I think that it shows the problem a bit more clearly. It looks like previously Fix Version == master was just used arbitrarily to indicate some point in the future. Kevin Risden
[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+116) - Build # 623 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/623/ Java: 32bit/jdk-9-ea+116 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication Error Message: [/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4AF1C607E6281D34-001/solr-instance-014/./collection1/data/index.20160511234702199, /home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4AF1C607E6281D34-001/solr-instance-014/./collection1/data, /home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4AF1C607E6281D34-001/solr-instance-014/./collection1/data/index.20160511234702112] expected:<2> but was:<3> Stack Trace: java.lang.AssertionError: [/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4AF1C607E6281D34-001/solr-instance-014/./collection1/data/index.20160511234702199, /home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4AF1C607E6281D34-001/solr-instance-014/./collection1/data, /home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_4AF1C607E6281D34-001/solr-instance-014/./collection1/data/index.20160511234702112] expected:<2> but was:<3> at __randomizedtesting.SeedInfo.seed([4AF1C607E6281D34:BD82285F20C0B2D2]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:902) at org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1334) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at
[JENKINS] Lucene-Solr-Tests-master - Build # 1136 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1136/ 1 tests failed. FAILED: org.apache.solr.TestDistributedSearch.test Error Message: Error from server at http://127.0.0.1:53388/l/collection1: java.lang.NullPointerException at org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:105) at org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:753) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:736) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:420) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2016) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:465) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:111) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:462) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) at org.eclipse.jetty.server.Server.handle(Server.java:518) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572) at java.lang.Thread.run(Thread.java:745) Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:53388/l/collection1: java.lang.NullPointerException at org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:105) at org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:753) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:736) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:420) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2016) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:465) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:111) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511) at
[jira] [Commented] (LUCENE-6766) Make index sorting a first-class citizen
[ https://issues.apache.org/jira/browse/LUCENE-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280234#comment-15280234 ] Michael McCandless commented on LUCENE-6766: I tried sorting with the 10M wikipedia index. Sort by last-modified-date: {noformat} Indexer: indexing done (900389 msec); total 1000 docs Indexer: force merge done (took 134020 msec) {noformat} Sort by title: {noformat} Indexer: indexing done (907923 msec); total 1000 docs Indexer: force merge done (took 135041 msec) {noformat} vs. no sorting: {noformat} Indexer: indexing done (702761 msec); total 1000 docs Indexer: force merge done (took 65726 msec) {noformat} Index size was about the same in all cases, ~3.1 GB. I also confirmed CheckIndex verifies the sorted indices are OK (it checks the sort order). So ~28% slower with sorting overall... but this uses a single thread, SerialMergeScheduler, and small IW buffer, so it's very merge-heavy. > Make index sorting a first-class citizen > > > Key: LUCENE-6766 > URL: https://issues.apache.org/jira/browse/LUCENE-6766 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-6766.patch, LUCENE-6766.patch, LUCENE-6766.patch > > > Today index sorting is a very expert feature. You need to use a custom merge > policy, custom collectors, etc. I would like to explore making it a > first-class citizen so that: > - the sort order could be configured on IndexWriterConfig > - segments would record the sort order that was used to write them > - IndexSearcher could automatically early terminate when computing top docs > on a sort order that is a prefix of the sort order of a segment (and if the > user is not interested in totalHits). -- 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-9104) NPE in CollapsingQParser when two fq={!collapse} and zero results
[ https://issues.apache.org/jira/browse/SOLR-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-9104: Description: This is a very weird problem that is reproducible on a small production server, but not on the local machine although they run the same 6.0 version., and have an almost identical index. The only minor difference is that production is a SolrCloud with 1 shard and two replica's, just for a bit of redundancy. The following query yields zero results and throws the NPE: {code} select?q=query:seis={!collapse field=query_digest}={!collapse field=result_digest} {code} The next query does yield results and does not throw anything, it just works as it should work: {code} select?q=query:seiz={!collapse field=query_digest}={!collapse field=result_digest} {code} The /select handler used does not add any fancy param other than rows. Here's the NPE: {code} 2016-05-11 14:10:27.666 ERROR (qtp1209271652-3338) [c:suggestions s:shard1 r:core_node1 x:suggestions_shard1_replica1] o.a.s.s.HttpSolrCall null:java.lang.NullPointerException at org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:814) at org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:851) at org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:272) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1794) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1611) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:634) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:529) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:287) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155) {code} was: This is a very weird problem that is reproducible on a small production server, but not on the local machine although they run the same 6.0 version., and have an almost identical index. The only minor difference is that production is a SolrCloud with 1 shard and two replica's, just for a bit of redundancy. The following query yields zero results and then throws the NPE: {code} select?q=query:seis={!collapse field=query_digest}={!collapse field=result_digest} {code} The next query does yield results and does not throw anything, it just works as it should work: {code} select?q=query:seiz={!collapse field=query_digest}={!collapse field=result_digest} {code} The /select handler used does not add and fancy param other than rows. Here's the NPE: {code} 2016-05-11 14:10:27.666 ERROR (qtp1209271652-3338) [c:suggestions s:shard1 r:core_node1 x:suggestions_shard1_replica1] o.a.s.s.HttpSolrCall null:java.lang.NullPointerException at org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:814) at org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:851) at org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:272) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1794) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1611) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:634) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:529) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:287) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155) {code} > NPE in CollapsingQParser when two fq={!collapse} and zero results > - > > Key: SOLR-9104 > URL: https://issues.apache.org/jira/browse/SOLR-9104 > Project: Solr > Issue Type: Bug >Affects Versions: 6.0 >Reporter: Markus Jelsma > Fix For: 6.1, master (7.0) > > > This is a very weird problem that is reproducible on a small production > server, but not on the local machine although they run the same 6.0 version., > and have an almost identical index. The only minor difference is that > production is a SolrCloud with 1 shard and two replica's, just for a bit of > redundancy. > The following query yields zero results and throws the NPE: > {code} > select?q=query:seis={!collapse field=query_digest}={!collapse > field=result_digest} > {code} > The next query does yield results and does not throw anything, it just works > as it should work: > {code} > select?q=query:seiz={!collapse
[jira] [Commented] (SOLR-9093) fix TopGroupsShardResponseProcessor.java:105 NullPointerException
[ https://issues.apache.org/jira/browse/SOLR-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280211#comment-15280211 ] ASF subversion and git services commented on SOLR-9093: --- Commit c4e8673bf06dfffe78796e30fc34373baa85252b in lucene-solr's branch refs/heads/master from [~cpoerschke] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c4e8673 ] SOLR-9093: Fix NullPointerException in TopGroupsShardResponseProcessor. > fix TopGroupsShardResponseProcessor.java:105 NullPointerException > - > > Key: SOLR-9093 > URL: https://issues.apache.org/jira/browse/SOLR-9093 > Project: Solr > Issue Type: Bug >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > > e.g. > http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16693/testReport/junit/org.apache.solr/TestDistributedSearch/test/ > {code} > org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error > from server at http://127.0.0.1:44706//collection1: > java.lang.NullPointerException > at > org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:105) > at > org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:753) > at > org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:736) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:420) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2016) > ... > {code} > A minimalistic fix would be > {code} > - if (t instanceof SolrServerException) { > + if (t instanceof SolrServerException && t.getCause() != null) { > {code} > but perhaps equally valid would be to tweak the logic, similar to the > [SearchHandler.java#L440|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L440] > logic, the difference being cause vs. root-cause for SolrServerException > exceptions and throwable vs. throwable.cause for other exceptions. -- 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-8744) Overseer operations need more fine grained mutual exclusion
[ https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-8744: - Summary: Overseer operations need more fine grained mutual exclusion (was: SplitShard needs finer-grained mutual exclusion) > Overseer operations need more fine grained mutual exclusion > --- > > Key: SOLR-8744 > URL: https://issues.apache.org/jira/browse/SOLR-8744 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Scott Blum >Assignee: Noble Paul > Labels: sharding, solrcloud > > SplitShard creates a mutex over the whole collection, but, in practice, this > is a big scaling problem. Multiple split shard operations could happen at > the time time, as long as different shards are being split. In practice, > those shards often reside on different machines, so there's no I/O bottleneck > in those cases, just the mutex in Overseer forcing the operations to be done > serially. > Given that a single split can take many minutes on a large collection, this > is a bottleneck at scale. > Here is the proposed new design > There are various Collection operations performed at Overseer. They may need > exclusive access at various levels. Each operation must define the Access > level at which the access is required. Access level is an enum. > CLUSTER(0) > COLLECTION(1) > SHARD(2) > REPLICA(3) > The Overseer node maintains a tree of these locks. The lock tree would look > as follows. The tree can be created lazily as and when tasks come up. > {code} > Legend: > C1, C2 -> Collections > S1, S2 -> Shards > R1,R2,R3,R4 -> Replicas > Cluster > / \ >/ \ > C1 C2 > / \ / \ > / \ / \ >S1 S2 S1 S2 > R1, R2 R3.R4 R1,R2 R3,R4 > {code} > When the overseer receives a message, it tries to acquire the appropriate > lock from the tree. For example, if an operation needs a lock at a Collection > level and it needs to operate on Collection C1, the node C1 and all child > nodes of C1 must be free. > h2.Lock acquiring logic > Each operation would start from the root of the tree (Level 0 -> Cluster) and > start moving down depending upon the operation. After it reaches the right > node, it checks if all the children are free from a lock. If it fails to > acquire a lock, it remains in the work queue. A scheduler thread waits for > notification from the current set of tasks . Every task would do a > {{notify()}} on the monitor of the scheduler thread. The thread would start > from the head of the queue and check all tasks to see if that task is able to > acquire the right lock. If yes, it is executed, if not, the task is left in > the work queue. > When a new task arrives in the work queue, the schedulerthread wakes and just > try to schedule that task. -- 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] (SOLR-9104) NPE in CollapsingQParser when two fq={!collapse} and zero results
Markus Jelsma created SOLR-9104: --- Summary: NPE in CollapsingQParser when two fq={!collapse} and zero results Key: SOLR-9104 URL: https://issues.apache.org/jira/browse/SOLR-9104 Project: Solr Issue Type: Bug Affects Versions: 6.0 Reporter: Markus Jelsma Fix For: 6.1, master (7.0) This is a very weird problem that is reproducible on a small production server, but not on the local machine although they run the same 6.0 version., and have an almost identical index. The only minor difference is that production is a SolrCloud with 1 shard and two replica's, just for a bit of redundancy. The following query yields zero results and then throws the NPE: {code} select?q=query:seis={!collapse field=query_digest}={!collapse field=result_digest} {code} The next query does yield results and does not throw anything, it just works as it should work: {code} select?q=query:seiz={!collapse field=query_digest}={!collapse field=result_digest} {code} The /select handler used does not add and fancy param other than rows. Here's the NPE: {code} 2016-05-11 14:10:27.666 ERROR (qtp1209271652-3338) [c:suggestions s:shard1 r:core_node1 x:suggestions_shard1_replica1] o.a.s.s.HttpSolrCall null:java.lang.NullPointerException at org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:814) at org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:851) at org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:272) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1794) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1611) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:634) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:529) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:287) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155) {code} -- 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-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+116) - Build # 16713 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16713/ Java: 64bit/jdk-9-ea+116 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.DistribCursorPagingTest.test Error Message: Error from server at https://127.0.0.1:35375/collection1: Expected mime type application/octet-stream but got text/html.Error 500HTTP ERROR: 500 Problem accessing /collection1/update. Reason: java.lang.OutOfMemoryError: Java heap space http://eclipse.org/jetty;>Powered by Jetty:// 9.3.8.v20160314 Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at https://127.0.0.1:35375/collection1: Expected mime type application/octet-stream but got text/html. Error 500 HTTP ERROR: 500 Problem accessing /collection1/update. Reason: java.lang.OutOfMemoryError: Java heap space http://eclipse.org/jetty;>Powered by Jetty:// 9.3.8.v20160314 at __randomizedtesting.SeedInfo.seed([85F244DC3CB9F0C5:DA67B0692459D3D]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:661) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.indexDoc(AbstractFullDistribZkTestBase.java:792) at org.apache.solr.cloud.DistribCursorPagingTest.doRandomSortsOnLargeIndex(DistribCursorPagingTest.java:582) at org.apache.solr.cloud.DistribCursorPagingTest.test(DistribCursorPagingTest.java:94) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[jira] [Commented] (SOLR-9102) Add get() and transactional put() Streaming Expressions
[ https://issues.apache.org/jira/browse/SOLR-9102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280125#comment-15280125 ] Joel Bernstein commented on SOLR-9102: -- I believe the key thing that needs to be done to support a transactional put() is to support that ability to rollback / abort. I think the best approach for adding rollback / abort capabilities to SolrCloud, is to add an *undo log* that works with the existing redo log. > Add get() and transactional put() Streaming Expressions > --- > > Key: SOLR-9102 > URL: https://issues.apache.org/jira/browse/SOLR-9102 > Project: Solr > Issue Type: New Feature >Reporter: Joel Bernstein >Assignee: Joel Bernstein > > It would be useful to add *get()* and *put()* Streaming Expressions that > allows SolrCloud to be behave like a transactional distributed key/value > store. This will allow Solr's real-time get and multi-get capabilities to be > easily combined with other expressions. > Sample get syntax: > {code} > get(collection, ids="a,b,c") > {code} > This ticket will also explore the possibility of adding a *transactional* > put. Different transaction schemes will be explored. > {code} > put(collection, id="a", fieldA="aaab", fieldC="blah blah") > {code} -- 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-8744) SplitShard needs finer-grained mutual exclusion
[ https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-8744: - Description: SplitShard creates a mutex over the whole collection, but, in practice, this is a big scaling problem. Multiple split shard operations could happen at the time time, as long as different shards are being split. In practice, those shards often reside on different machines, so there's no I/O bottleneck in those cases, just the mutex in Overseer forcing the operations to be done serially. Given that a single split can take many minutes on a large collection, this is a bottleneck at scale. Here is the proposed new design There are various Collection operations performed at Overseer. They may need exclusive access at various levels. Each operation must define the Access level at which the access is required. Access level is an enum. CLUSTER(0) COLLECTION(1) SHARD(2) REPLICA(3) The Overseer node maintains a tree of these locks. The lock tree would look as follows. The tree can be created lazily as and when tasks come up. {code} Legend: C1, C2 -> Collections S1, S2 -> Shards R1,R2,R3,R4 -> Replicas Cluster / \ / \ C1 C2 / \ / \ / \ / \ S1 S2 S1 S2 R1, R2 R3.R4 R1,R2 R3,R4 {code} When the overseer receives a message, it tries to acquire the appropriate lock from the tree. For example, if an operation needs a lock at a Collection level and it needs to operate on Collection C1, the node C1 and all child nodes of C1 must be free. h2.Lock acquiring logic Each operation would start from the root of the tree (Level 0 -> Cluster) and start moving down depending upon the operation. After it reaches the right node, it checks if all the children are free from a lock. If it fails to acquire a lock, it remains in the work queue. A scheduler thread waits for notification from the current set of tasks . Every task would do a {{notify()}} on the monitor of the scheduler thread. The thread would start from the head of the queue and check all tasks to see if that task is able to acquire the right lock. If yes, it is executed, if not, the task is left in the work queue. When a new task arrives in the work queue, the schedulerthread wakes and just try to schedule that task. was: SplitShard creates a mutex over the whole collection, but in practice this is a big scaling problem. Multiple split shard operations could happen at the time time, as long as different shards are being split. In practice, those shards often reside on different machines, so there's no I/O bottleneck in those cases, just the mutex in Overseer forcing the operations to be done serially. Given that a single split can take many minutes on a large collection, this is a bottleneck at scale. Here is the proposed new design There are various Collection operations performed at Overseer. They may need exclusive access at various levels. Each operation must define the Access level at which the access is required. Access level is an enum. CLUSTER(0) COLLECTION(1) SHARD(2) REPLICA(3) The Overseer node maintains a tree of these locks. The lock tree would look as follows. The tree can be created lazily as and when tasks come up. Legend: C1, C2 -> Collections S1, S2 -> Shards R1,R2,R3,R4 -> Replicas {code} Cluster / \ / \ C1 C2 / \ / \ / \ / \ S1 S2 S1 S2 R1, R2 R3.R4 R1,R2 R3,R4 {code} When the overseer receives a message, it tries to acquire the appropriate lock from the tree. For example, if an operation needs a lock at a Collection level and it needs to operate on Collection C1, the node C1 and all child nodes of C1 must be free. h2.Lock acquiring logic Each operation would start from the root of the tree (Level 0 -> Cluster) and start moving down depending upon the operation. After it reaches the right node, it checks if all the children are free from lock. If it fails to acquire a lock, it remains in the work queue. A scheduler thread waits for notification from current set of tasks . Every task would do a notify() on the monitor of the scheduler thread. The thread would start from the head of the queue and check all tasks to see if that task is able to acquire the right lock. If yes, it is executed, if not, the task is left in the work queue. When a new task arrives in the work queue, the schedulerthread wakes and just try to schedule that task. > SplitShard needs finer-grained mutual exclusion > --- > > Key: SOLR-8744 > URL:
[jira] [Updated] (SOLR-8744) SplitShard needs finer-grained mutual exclusion
[ https://issues.apache.org/jira/browse/SOLR-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-8744: - Description: SplitShard creates a mutex over the whole collection, but in practice this is a big scaling problem. Multiple split shard operations could happen at the time time, as long as different shards are being split. In practice, those shards often reside on different machines, so there's no I/O bottleneck in those cases, just the mutex in Overseer forcing the operations to be done serially. Given that a single split can take many minutes on a large collection, this is a bottleneck at scale. Here is the proposed new design There are various Collection operations performed at Overseer. They may need exclusive access at various levels. Each operation must define the Access level at which the access is required. Access level is an enum. CLUSTER(0) COLLECTION(1) SHARD(2) REPLICA(3) The Overseer node maintains a tree of these locks. The lock tree would look as follows. The tree can be created lazily as and when tasks come up. Legend: C1, C2 -> Collections S1, S2 -> Shards R1,R2,R3,R4 -> Replicas {code} Cluster / \ / \ C1 C2 / \ / \ / \ / \ S1 S2 S1 S2 R1, R2 R3.R4 R1,R2 R3,R4 {code} When the overseer receives a message, it tries to acquire the appropriate lock from the tree. For example, if an operation needs a lock at a Collection level and it needs to operate on Collection C1, the node C1 and all child nodes of C1 must be free. h2.Lock acquiring logic Each operation would start from the root of the tree (Level 0 -> Cluster) and start moving down depending upon the operation. After it reaches the right node, it checks if all the children are free from lock. If it fails to acquire a lock, it remains in the work queue. A scheduler thread waits for notification from current set of tasks . Every task would do a notify() on the monitor of the scheduler thread. The thread would start from the head of the queue and check all tasks to see if that task is able to acquire the right lock. If yes, it is executed, if not, the task is left in the work queue. When a new task arrives in the work queue, the schedulerthread wakes and just try to schedule that task. was: SplitShard creates a mutex over the whole collection, but in practice this is a big scaling problem. Multiple split shard operations could happen at the time time, as long as different shards are being split. In practice, those shards often reside on different machines, so there's no I/O bottleneck in those cases, just the mutex in Overseer forcing the operations to be done serially. Given that a single split can take many minutes on a large collection, this is a bottleneck at scale. > SplitShard needs finer-grained mutual exclusion > --- > > Key: SOLR-8744 > URL: https://issues.apache.org/jira/browse/SOLR-8744 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.4.1 >Reporter: Scott Blum >Assignee: Noble Paul > Labels: sharding, solrcloud > > SplitShard creates a mutex over the whole collection, but in practice this is > a big scaling problem. Multiple split shard operations could happen at the > time time, as long as different shards are being split. In practice, those > shards often reside on different machines, so there's no I/O bottleneck in > those cases, just the mutex in Overseer forcing the operations to be done > serially. > Given that a single split can take many minutes on a large collection, this > is a bottleneck at scale. > Here is the proposed new design > There are various Collection operations performed at Overseer. They may need > exclusive access at various levels. Each operation must define the Access > level at which the access is required. Access level is an enum. > CLUSTER(0) > COLLECTION(1) > SHARD(2) > REPLICA(3) > The Overseer node maintains a tree of these locks. The lock tree would look > as follows. The tree can be created lazily as and when tasks come up. > Legend: > C1, C2 -> Collections > S1, S2 -> Shards > R1,R2,R3,R4 -> Replicas > {code} > Cluster > / \ >/ \ > C1 C2 > / \ / \ > / \ / \ >S1 S2 S1 S2 > R1, R2 R3.R4 R1,R2 R3,R4 > {code} > When the overseer receives a message, it tries to acquire the appropriate > lock from the tree. For example, if an operation needs a lock at a Collection > level and it needs to operate on
[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 62 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/62/ 3 tests failed. FAILED: org.apache.solr.hadoop.MorphlineBasicMiniMRTest.mrRun Error Message: Failed on local exception: java.io.IOException: Broken pipe; Host Details : local host is: "lucene1-us-west/10.41.0.5"; destination host is: "lucene1-us-west.apache.org":41749; Stack Trace: java.io.IOException: Failed on local exception: java.io.IOException: Broken pipe; Host Details : local host is: "lucene1-us-west/10.41.0.5"; destination host is: "lucene1-us-west.apache.org":41749; at __randomizedtesting.SeedInfo.seed([898818BB2E65B20E:87DAACB52FF38001]:0) at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:772) at org.apache.hadoop.ipc.Client.call(Client.java:1472) at org.apache.hadoop.ipc.Client.call(Client.java:1399) at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232) at com.sun.proxy.$Proxy110.getClusterMetrics(Unknown Source) at org.apache.hadoop.yarn.api.impl.pb.client.ApplicationClientProtocolPBClientImpl.getClusterMetrics(ApplicationClientProtocolPBClientImpl.java:202) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187) at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102) at com.sun.proxy.$Proxy111.getClusterMetrics(Unknown Source) at org.apache.hadoop.yarn.client.api.impl.YarnClientImpl.getYarnClusterMetrics(YarnClientImpl.java:461) at org.apache.hadoop.mapred.ResourceMgrDelegate.getClusterMetrics(ResourceMgrDelegate.java:151) at org.apache.hadoop.mapred.YARNRunner.getClusterMetrics(YARNRunner.java:179) at org.apache.hadoop.mapreduce.Cluster.getClusterStatus(Cluster.java:246) at org.apache.hadoop.mapred.JobClient$3.run(JobClient.java:719) at org.apache.hadoop.mapred.JobClient$3.run(JobClient.java:717) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628) at org.apache.hadoop.mapred.JobClient.getClusterStatus(JobClient.java:717) at org.apache.solr.hadoop.MapReduceIndexerTool.run(MapReduceIndexerTool.java:645) at org.apache.solr.hadoop.MapReduceIndexerTool.run(MapReduceIndexerTool.java:608) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) at org.apache.solr.hadoop.MorphlineBasicMiniMRTest.mrRun(MorphlineBasicMiniMRTest.java:364) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16712 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16712/ Java: 32bit/jdk1.8.0_92 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.schema.TestManagedSchemaAPI.test Error Message: Error from server at http://127.0.0.1:36948/solr/testschemaapi_shard1_replica1: ERROR: [doc=2] unknown field 'myNewField1' Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at http://127.0.0.1:36948/solr/testschemaapi_shard1_replica1: ERROR: [doc=2] unknown field 'myNewField1' at __randomizedtesting.SeedInfo.seed([5994D9956D52BF17:D1C0E64FC3AED2EF]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:661) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898) at org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86) at org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5833 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5833/ Java: 32bit/jdk1.8.0_92 -client -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [InternalHttpClient] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [InternalHttpClient] at __randomizedtesting.SeedInfo.seed([EF1A13156D6A5661]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255) at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 11932 lines...] [junit4] Suite: org.apache.solr.cloud.CdcrVersionReplicationTest [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.CdcrVersionReplicationTest_EF1A13156D6A5661-001\init-core-data-001 [junit4] 2> 2281545 INFO (SUITE-CdcrVersionReplicationTest-seed#[EF1A13156D6A5661]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) [junit4] 2> 2281545 INFO (SUITE-CdcrVersionReplicationTest-seed#[EF1A13156D6A5661]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 2281550 INFO (TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[EF1A13156D6A5661]) [ ] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 2281551 INFO (Thread-5660) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 2281551 INFO (Thread-5660) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 2281651 INFO (TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[EF1A13156D6A5661]) [ ] o.a.s.c.ZkTestServer start zk server on port:61034 [junit4] 2> 2281651 INFO (TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[EF1A13156D6A5661]) [ ] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 2281653 INFO (TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[EF1A13156D6A5661]) [ ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 2281656 INFO (zkCallback-8904-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@bbe37 name:ZooKeeperConnection Watcher:127.0.0.1:61034 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 2281656 INFO (TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[EF1A13156D6A5661]) [ ]