Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing
I think this exception should be thrown only when the bytes land in the Directory. I think that in general we buffer bytes before sending them to the actual IndexOutput? I don't know if this is done with RAMDir too i.e. that there isn't code out there that buffers its writes to any IndexOutput, not caring if it's RAMFile or not. And technically, if you have a buffer of 16K, but can only write 2K to the underlying Directory, you shouldn't hit the exception until you actually flush the bytes? Adrien, not in front of the code now, but if writeBytes applies the limit, why do we need any special logic in MDW.flush? Shai On Thu, May 16, 2013 at 3:45 PM, Adrien Grand jpou...@gmail.com wrote: On Thu, May 16, 2013 at 1:58 PM, Robert Muir rcm...@gmail.com wrote: I dont get it. MDW wraps its IndexOutput so it knows... sounds like the counting is off. The problem is that RAMDirectory delays the counting. MockDirectoryWrapper.getRecomputedActualSizeInBytes sums all the lengths of the existing RAMFiles to get the actual size, but RAMFile.length is only updated after a RAMOutputStream seek or flush. This means that if you write 5 bytes, then 3 bytes, RAMFile.length will still be 0 and then suddenly upon flush it will become 5+3=8. Using the Mock IndexOutput to track bytes is an option, but I was thinking it could be interesting too to see what happens with directories that buffer content so that the disk full exception happens in flush instead of writeBytes? -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing
On Thu, May 16, 2013 at 8:45 AM, Adrien Grand jpou...@gmail.com wrote: Using the Mock IndexOutput to track bytes is an option, but I was thinking it could be interesting too to see what happens with directories that buffer content so that the disk full exception happens in flush instead of writeBytes? But it can easily happen in both places... - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4773) New discovery mode needs to ensure that instanceDir is correct
[ https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659676#comment-13659676 ] Shawn Heisey commented on SOLR-4773: [~andyfowler] - I finally found some time and looked into this more deeply in relation to 4.3.0. The patch for this issue does not fix the problem with relative dataDirs in the released version. The patch as-is won't apply to 4.3.0 because the code in branch_4x was significantly refactored, but I found the right place to apply the change from getPath to getCanonicalPath, and it didn't help. It did fix an exception during startup (solrconfig.xml couldn't be found) when I followed your simple instructions for running the multicore example with discovery, but only core0 started, core1 didn't, because it had the same dataDir as core0. [~markrmil...@gmail.com] - Do you happen to know how we can fix the problem with relative or missing dataDir properties in the 4.3 branch? Would the change be trivial enough to make it to 4.3.1? Discovery mode is essentially broken at the moment in the 4.3.0 release unless you have full absolute paths that are explicitly declared in the properties file. This is not how I want things to work in my own setup. New discovery mode needs to ensure that instanceDir is correct -- Key: SOLR-4773 URL: https://issues.apache.org/jira/browse/SOLR-4773 Project: Solr Issue Type: Bug Components: Schema and Analysis Affects Versions: 5.0, 4.4 Reporter: Erick Erickson Assignee: Mark Miller Fix For: 5.0, 4.4 Attachments: SOLR-4773.patch, SOLR-4773.patch Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example fails because we can't find solrconfig. The construction of the instanceDir in SolrCoreDiscoverer constructs a path with an extra solr (e.g. solr/solr/core). I'll attach a patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4829) transaction log reference leak
[ https://issues.apache.org/jira/browse/SOLR-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-4829: --- Attachment: SOLR-4829.patch Here's another version that cleans up tlog references during tlog recovery in the event an unexpected exception (like a commit throwing something other than IOException). Aside: we should keep in mind that when index corruption happens, lucene can throw exceptions other than IOException. transaction log reference leak -- Key: SOLR-4829 URL: https://issues.apache.org/jira/browse/SOLR-4829 Project: Solr Issue Type: Bug Affects Versions: 4.1 Reporter: Yonik Seeley Assignee: Yonik Seeley Fix For: 5.0, 4.3.1 Attachments: SOLR-4829.patch, SOLR-4829.patch, SOLR-4829.patch Failure to dereference tlogs or RecentUpdates can cause old transaction logs to never be closed deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.6.0) - Build # 458 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/458/
Java: 64bit/jdk1.6.0 -XX:-UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 1523 lines...]
[javac] Compiling 392 source files to
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/analysis/common/classes/java
[javac]
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/analysis/common/src/java/org/apache/lucene/analysis/position/PositionFilter.java:25:
package org.apache.lucene.queryparser.classic does not exist
[javac] import org.apache.lucene.queryparser.classic.QueryParser;
[javac] ^
[javac]
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/analysis/common/src/java/org/apache/lucene/analysis/synonym/SynonymFilterFactory.java:86:
warning: [dep-ann] deprecated item is not annotated with @Deprecated
[javac] TokenFilterFactory getDelegator() {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 error
[...truncated 1 lines...]
BUILD FAILED
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/build.xml:383:
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/build.xml:363:
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/build.xml:39: The
following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build.xml:549:
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/common-build.xml:1827:
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/analysis/build.xml:99:
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/analysis/build.xml:38:
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/module-build.xml:58:
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/common-build.xml:489:
The following error occurred while executing this line:
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/common-build.xml:1626:
Compile failed; see the compiler error output for details.
Total time: 19 minutes 33 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.6.0 -XX:-UseCompressedOops -XX:+UseParallelGC
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1621 - Still Failing
: (b) is unlikely. Dump the allocation tree and see what's the major : contributor to the size. Right, see rmuir's response and the subsequent collection of aggregation of info in my comment on SOLR-4825... https://issues.apache.org/jira/browse/SOLR-4825#comment-13659117 -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-4.x #328: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/328/ 1 tests failed. REGRESSION: org.apache.solr.cloud.ShardSplitTest.testDistribSearch Error Message: Wrong doc count on shard1_0 expected:125 but was:124 Stack Trace: java.lang.AssertionError: Wrong doc count on shard1_0 expected:125 but was:124 at __randomizedtesting.SeedInfo.seed([7C6CF0CF6C540501:FD8A7ED71B0B653D]: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.cloud.ShardSplitTest.checkDocCountsAndShardStates(ShardSplitTest.java:166) at org.apache.solr.cloud.ShardSplitTest.doTest(ShardSplitTest.java:142) Build Log: [...truncated 23900 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1621 - Still Failing
My suspicion is that its that map key'ed on solrcore. in this case it would be holding references to SolrCores from previous tests. Because test order and other things are randomized, it would explain the huge size fluctuations. On Thu, May 16, 2013 at 12:35 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : (b) is unlikely. Dump the allocation tree and see what's the major : contributor to the size. Right, see rmuir's response and the subsequent collection of aggregation of info in my comment on SOLR-4825... https://issues.apache.org/jira/browse/SOLR-4825#comment-13659117 -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.6.0_45) - Build # 5623 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5623/
Java: 32bit/jdk1.6.0_45 -client -XX:+UseSerialGC
All tests passed
Build Log:
[...truncated 1574 lines...]
[javac] Compiling 392 source files to
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/common/classes/java
[javac]
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/common/src/java/org/apache/lucene/analysis/position/PositionFilter.java:25:
package org.apache.lucene.queryparser.classic does not exist
[javac] import org.apache.lucene.queryparser.classic.QueryParser;
[javac] ^
[javac]
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/common/src/java/org/apache/lucene/analysis/synonym/SynonymFilterFactory.java:86:
warning: [dep-ann] deprecated item is not annotated with @Deprecated
[javac] TokenFilterFactory getDelegator() {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 error
[...truncated 1 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:383: The following
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:363: The following
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:39: The following
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build.xml:549: The
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1827:
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/build.xml:99:
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/build.xml:38:
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/module-build.xml:58:
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:489:
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1626:
Compile failed; see the compiler error output for details.
Total time: 8 minutes 31 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 32bit/jdk1.6.0_45 -client -XX:+UseSerialGC
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4773) New discovery mode needs to ensure that instanceDir is correct
[ https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659699#comment-13659699 ] Mark Miller commented on SOLR-4773: --- I don't know that it would be that easy - I honestly think it could involve multiple bugs - I fixed many little things in this area in 4x and I think erick has as well. With all the refactoring and all the bugs (there is still a critical outstanding one around persistence if I remember right), as I've said elsewhere, I don't consider the new solr.xml format to be usable for 4.3 and I don't think I can confidently make it solid for 4.3.1 - I've dedicated what time I can to make it solid for 4.4 (and I know there is still work to do and work I've done but not put up yet), which shouldn't be too far out. I reccomended keeping this stuff in 5x and changing the tests and example to use it before pushing it out in a release - as I said, it didn't actually bake in 5x by sitting there, essentially hidden from dev use and wide testing for a couple weeks - I pushed back a bit multiple times - because I was worried this would be the result, but at this point, we are where we are, and I can only offer to help make things usable for 4.4 at best. New discovery mode needs to ensure that instanceDir is correct -- Key: SOLR-4773 URL: https://issues.apache.org/jira/browse/SOLR-4773 Project: Solr Issue Type: Bug Components: Schema and Analysis Affects Versions: 5.0, 4.4 Reporter: Erick Erickson Assignee: Mark Miller Fix For: 5.0, 4.4 Attachments: SOLR-4773.patch, SOLR-4773.patch Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example fails because we can't find solrconfig. The construction of the instanceDir in SolrCoreDiscoverer constructs a path with an extra solr (e.g. solr/solr/core). I'll attach a patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4773) New discovery mode needs to ensure that instanceDir is correct
[ https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659703#comment-13659703 ] Shawn Heisey commented on SOLR-4773: bq. at this point, we are where we are, and I can only offer to help make things usable for 4.4 at best. Thanks, Mark. I thought that might be the case, just wanted to nail it down. Now I know what to tell users! New discovery mode needs to ensure that instanceDir is correct -- Key: SOLR-4773 URL: https://issues.apache.org/jira/browse/SOLR-4773 Project: Solr Issue Type: Bug Components: Schema and Analysis Affects Versions: 5.0, 4.4 Reporter: Erick Erickson Assignee: Mark Miller Fix For: 5.0, 4.4 Attachments: SOLR-4773.patch, SOLR-4773.patch Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example fails because we can't find solrconfig. The construction of the instanceDir in SolrCoreDiscoverer constructs a path with an extra solr (e.g. solr/solr/core). I'll attach a patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1621 - Still Failing
What's a little odd is that this should work exactly as it did before we used log4j - I just pure copied the code from a Formatter to a Layout. I originally suspected that the Layout is holding onto stuff, but thought perhaps that had something to do with java util logging vs log4j, since this didn't seem to previously show up as an issue. Perhaps we have added enough tests to cross a threshold while this was not in use. In any case, it seems likely we can improve the Layout - I can take a look. - Mark On May 16, 2013, at 12:44 PM, Robert Muir rcm...@gmail.com wrote: My suspicion is that its that map key'ed on solrcore. in this case it would be holding references to SolrCores from previous tests. Because test order and other things are randomized, it would explain the huge size fluctuations. On Thu, May 16, 2013 at 12:35 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : (b) is unlikely. Dump the allocation tree and see what's the major : contributor to the size. Right, see rmuir's response and the subsequent collection of aggregation of info in my comment on SOLR-4825... https://issues.apache.org/jira/browse/SOLR-4825#comment-13659117 -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing
Looking at the code, I think that today flush() cannot throw diskFullEx? MockIO checks for diskFull in writeBytes and copyBytes, using dir.sizeInBytes. So I think if you limit maxSize=5 and write 4 + 4 bytes, to a Directory with a buffer of 20 bytes, then both writeBytes will succeed (as dir.sizeInBytes = 0). flush() will also succeed since it only calls delegate.flush(). So I think either MDW should track its size, or MockIO track the num written bytes? Shai On Thu, May 16, 2013 at 7:08 PM, Robert Muir rcm...@gmail.com wrote: On Thu, May 16, 2013 at 8:45 AM, Adrien Grand jpou...@gmail.com wrote: Using the Mock IndexOutput to track bytes is an option, but I was thinking it could be interesting too to see what happens with directories that buffer content so that the disk full exception happens in flush instead of writeBytes? But it can easily happen in both places... - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1621 - Still Failing
On May 16, 2013, at 12:59 PM, Mark Miller markrmil...@gmail.com wrote: In any case, it seems likely we can improve the Layout - I can take a look. Seems like we could get away with just using SolrCore#hashCode rather than keying by the SolrCore. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4833) All(most all) Logger instances should be made static
Hoss Man created SOLR-4833: -- Summary: All(most all) Logger instances should be made static Key: SOLR-4833 URL: https://issues.apache.org/jira/browse/SOLR-4833 Project: Solr Issue Type: Improvement Reporter: Hoss Man The majority of Logger usage in Solr is via static variables, but there are a few places where this pattern does not hold true - i think we should fix that and be completley consistent. if there is any specific cases where a non-static variable really makes a lot of sense, then it should be heavily commented as to why. The SLF4J FAQ has a list of pros and cons for why Logger variables should/shouldn't be static... http://slf4j.org/faq.html#declared_static ...the majority of the pros for non-static usage don't really apply to Solr, while the pros for static usage due. Another lucene/solr specific pro in favor of static variables for loggers is the way our test framework looks for memory leaks in tests. Having a simple test that does not null out a static reference to what seems like a small object is typically fine -- but if that small object has an explicit (non-static) reference to a Logger, all of the state in that Logger is counted as part of the size of that small object leading to confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 259 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/259/
All tests passed
Build Log:
[...truncated 1578 lines...]
[javac] Compiling 392 source files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/build/analysis/common/classes/java
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/common/src/java/org/apache/lucene/analysis/position/PositionFilter.java:25:
package org.apache.lucene.queryparser.classic does not exist
[javac] import org.apache.lucene.queryparser.classic.QueryParser;
[javac] ^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/common/src/java/org/apache/lucene/analysis/synonym/SynonymFilterFactory.java:86:
warning: [dep-ann] deprecated item is not annotated with @Deprecated
[javac] TokenFilterFactory getDelegator() {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 error
[...truncated 1 lines...]
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:390:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:363:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:39:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/build.xml:549:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:1827:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/build.xml:99:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/build.xml:38:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/module-build.xml:58:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:489:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:1626:
Compile failed; see the compiler error output for details.
Total time: 36 minutes 7 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1621 - Still Failing
: What's a little odd is that this should work exactly as it did before we It just occured to me that one thing rmuir and i noticed in IRC never made it into email or my jira comments: the Logger used by SolrRequestParsers is not static, so the mem estimator would count that as ram used by the object itself. I opened SOLR-4833 to audit all non-static Logger usage to try and mitigate this type of failure in the future -- but that's still just addressing the visible symptom that alerted us to (what i consider) the more alarming problem: how big the Logger can get. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-ea-b89) - Build # 5624 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5624/
Java: 32bit/jdk1.8.0-ea-b89 -client -XX:+UseG1GC
All tests passed
Build Log:
[...truncated 1435 lines...]
[javac] Compiling 392 source files to
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/common/classes/java
[javac]
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/common/src/java/org/apache/lucene/analysis/position/PositionFilter.java:25:
error: package org.apache.lucene.queryparser.classic does not exist
[javac] import org.apache.lucene.queryparser.classic.QueryParser;
[javac] ^
[javac]
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/common/src/java/org/apache/lucene/analysis/nl/DutchStemmer.java:42:
warning: [rawtypes] found raw type: Map
[javac] private Map _stemDict;
[javac] ^
[javac] missing type arguments for generic class MapK,V
[javac] where K,V are type-variables:
[javac] K extends Object declared in interface Map
[javac] V extends Object declared in interface Map
[javac]
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/common/src/java/org/apache/lucene/analysis/nl/DutchStemmer.java:408:
warning: [rawtypes] found raw type: Map
[javac] void setStemDictionary(Map dict) {
[javac] ^
[javac] missing type arguments for generic class MapK,V
[javac] where K,V are type-variables:
[javac] K extends Object declared in interface Map
[javac] V extends Object declared in interface Map
[javac]
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/common/src/java/org/tartarus/snowball/Among.java:46:
warning: [rawtypes] found raw type: Class
[javac] private static final Class?[] EMPTY_PARAMS = new Class[0];
[javac] ^
[javac] missing type arguments for generic class ClassT
[javac] where T is a type-variable:
[javac] T extends Object declared in class Class
[javac]
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/common/src/java/org/apache/lucene/analysis/synonym/SynonymFilterFactory.java:86:
warning: [dep-ann] deprecated item is not annotated with @Deprecated
[javac] TokenFilterFactory getDelegator() {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 error
[...truncated 1 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:383: The following
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:363: The following
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:39: The following
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build.xml:549: The
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1827:
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/build.xml:99:
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/build.xml:38:
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/module-build.xml:58:
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:489:
The following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1626:
Compile failed; see the compiler error output for details.
Total time: 9 minutes 42 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 32bit/jdk1.8.0-ea-b89 -client -XX:+UseG1GC
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 259 - Failure
These look like serious problems? Looks like the build is broken such
that analyzers is trying to pull in queryparser
On Thu, May 16, 2013 at 1:27 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/259/
All tests passed
Build Log:
[...truncated 1578 lines...]
[javac] Compiling 392 source files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/build/analysis/common/classes/java
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/common/src/java/org/apache/lucene/analysis/position/PositionFilter.java:25:
package org.apache.lucene.queryparser.classic does not exist
[javac] import org.apache.lucene.queryparser.classic.QueryParser;
[javac] ^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/common/src/java/org/apache/lucene/analysis/synonym/SynonymFilterFactory.java:86:
warning: [dep-ann] deprecated item is not annotated with @Deprecated
[javac] TokenFilterFactory getDelegator() {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 error
[...truncated 1 lines...]
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:390:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:363:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:39:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/build.xml:549:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:1827:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/build.xml:99:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/build.xml:38:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/module-build.xml:58:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:489:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:1626:
Compile failed; see the compiler error output for details.
Total time: 36 minutes 7 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 259 - Failure
I'm testing a patch right now and then i'll commit. the trick here is
to instead use a link like this:
a href={@docRoot}/../queryparser/overview-summary.htmlQueryParser/a
(since it really applies to all queryparsers anyway).
and its ok because if something is wrong our python linkchecker will
detect it.
On Thu, May 16, 2013 at 1:43 PM, Robert Muir rcm...@gmail.com wrote:
These look like serious problems? Looks like the build is broken such
that analyzers is trying to pull in queryparser
On Thu, May 16, 2013 at 1:27 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/259/
All tests passed
Build Log:
[...truncated 1578 lines...]
[javac] Compiling 392 source files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/build/analysis/common/classes/java
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/common/src/java/org/apache/lucene/analysis/position/PositionFilter.java:25:
package org.apache.lucene.queryparser.classic does not exist
[javac] import org.apache.lucene.queryparser.classic.QueryParser;
[javac] ^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/common/src/java/org/apache/lucene/analysis/synonym/SynonymFilterFactory.java:86:
warning: [dep-ann] deprecated item is not annotated with @Deprecated
[javac] TokenFilterFactory getDelegator() {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 error
[...truncated 1 lines...]
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:390:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:363:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:39:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/build.xml:549:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:1827:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/build.xml:99:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/build.xml:38:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/module-build.xml:58:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:489:
The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:1626:
Compile failed; see the compiler error output for details.
Total time: 36 minutes 7 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 259 - Failure
: I'm testing a patch right now and then i'll commit. the trick here is
: to instead use a link like this:
i just commited a change to not use a jdoc link at all actually
that's consistent with how FilteringTokenFilter refers to the same method
:
: a href={@docRoot}/../queryparser/overview-summary.htmlQueryParser/a
:
: (since it really applies to all queryparsers anyway).
:
: and its ok because if something is wrong our python linkchecker will
: detect it.
:
: On Thu, May 16, 2013 at 1:43 PM, Robert Muir rcm...@gmail.com wrote:
: These look like serious problems? Looks like the build is broken such
: that analyzers is trying to pull in queryparser
:
: On Thu, May 16, 2013 at 1:27 PM, Apache Jenkins Server
: jenk...@builds.apache.org wrote:
: Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/259/
:
: All tests passed
:
: Build Log:
: [...truncated 1578 lines...]
: [javac] Compiling 392 source files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/build/analysis/common/classes/java
: [javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/common/src/java/org/apache/lucene/analysis/position/PositionFilter.java:25:
package org.apache.lucene.queryparser.classic does not exist
: [javac] import org.apache.lucene.queryparser.classic.QueryParser;
: [javac] ^
: [javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/common/src/java/org/apache/lucene/analysis/synonym/SynonymFilterFactory.java:86:
warning: [dep-ann] deprecated item is not annotated with @Deprecated
: [javac] TokenFilterFactory getDelegator() {
: [javac] ^
: [javac] Note: Some input files use or override a deprecated API.
: [javac] Note: Recompile with -Xlint:deprecation for details.
: [javac] 1 error
:
: [...truncated 1 lines...]
: BUILD FAILED
:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:390:
The following error occurred while executing this line:
:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:363:
The following error occurred while executing this line:
:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/build.xml:39:
The following error occurred while executing this line:
:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/build.xml:549:
The following error occurred while executing this line:
:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:1827:
The following error occurred while executing this line:
:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/build.xml:99:
The following error occurred while executing this line:
:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/analysis/build.xml:38:
The following error occurred while executing this line:
:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/module-build.xml:58:
The following error occurred while executing this line:
:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:489:
The following error occurred while executing this line:
:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/common-build.xml:1626:
Compile failed; see the compiler error output for details.
:
: Total time: 36 minutes 7 seconds
: Build step 'Invoke Ant' marked build as failure
: Archiving artifacts
: Recording test results
: Email was triggered for: Failure
: Sending email for trigger: Failure
:
:
:
:
: -
: To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: For additional commands, e-mail: dev-h...@lucene.apache.org
:
: -
: To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: For additional commands, e-mail: dev-h...@lucene.apache.org
:
:
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
documentation-lint warning
FYI we currently have: [exec] Crawl/parse... [exec] [exec] file:///build/docs/analyzers-common/org/apache/lucene/analysis/util/FilteringTokenFilter.html [exec] WARNING: anchor version appears more than once I forget why this is a warning and not a hard fail, but we should probably investigate: it seems wrong. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 259 - Failure
On Thu, May 16, 2013 at 1:53 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : I'm testing a patch right now and then i'll commit. the trick here is : to instead use a link like this: i just commited a change to not use a jdoc link at all actually that's consistent with how FilteringTokenFilter refers to the same method ok, you can remove my link if you want. at least i fixed the method name to be the right one :) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1483459 - /lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py
Thanks Mike!
I had arrived at the same fix, but didnt' commit because the smoke tester was
also complaining (after running for 30 minutes) about Solr's NOTICE.txt not
having a verbatim copy of Lucene's NOTICE.txt - this is as a result of my
changing the text in Lucene's NOTICE.txt about servlet-api.jar to include
javax.servlet-*.jar.
Tracking down why this was still true after copy/pasting Lucene's into Solr's
took a while - after I had the smoke tester print out the things it was
comparing, I realized that it wasn't comparing my local changes, but rather the
committed changes…
Anyway, I've committed a change to Solr's NOTICE.txt to make it a verbatim copy
of Lucene's NOTICE.txt, and I'm running the smoke tester again after committing.
Steve
On May 16, 2013, at 1:19 PM, mikemcc...@apache.org wrote:
Author: mikemccand
Date: Thu May 16 17:18:59 2013
New Revision: 1483459
URL: http://svn.apache.org/r1483459
Log:
allow javax.servlet exception in lucene/replicator
Modified:
lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py
Modified: lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py
URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py?rev=1483459r1=1483458r2=1483459view=diff
==
--- lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py (original)
+++ lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py Thu May 16
17:18:59 2013
@@ -265,6 +265,9 @@ def checkAllJARs(topDir, project, svnRev
if normRoot.endswith('/contrib/dataimporthandler/lib') and
(file.startswith('mail-') or file.startswith('activation-')):
print(' **WARNING**: skipping check of %s/%s: it has javax.*
classes' % (root, file))
continue
+else:
+ if normRoot.endswith('/replicator/lib') and
file.startswith('javax.servlet'):
+continue
fullPath = '%s/%s' % (root, file)
noJavaPackageClasses('JAR file %s' % fullPath, fullPath)
if file.lower().find('lucene') != -1 or file.lower().find('solr') !=
-1:
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4989) Hanging on DocumentsWriterStallControl.waitIfStalled forever
[
https://issues.apache.org/jira/browse/LUCENE-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659825#comment-13659825
]
Jessica Cheng commented on LUCENE-4989:
---
Thanks for the quick replies guys. Simon, no, there wasn't any blocked threads
(it would have made tracking the problem down easier :)).
Hanging on DocumentsWriterStallControl.waitIfStalled forever
Key: LUCENE-4989
URL: https://issues.apache.org/jira/browse/LUCENE-4989
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.1
Environment: Linux 2.6.32
Reporter: Jessica Cheng
Labels: hang
Fix For: 5.0, 4.3.1
In an environment where our underlying storage was timing out on various
operations, we find all of our indexing threads eventually stuck in the
following state (so far for 4 days):
Thread-0 daemon prio=5 Thread id=556 WAITING
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:503)
at
org.apache.lucene.index.DocumentsWriterStallControl.waitIfStalled(DocumentsWriterStallControl.java:74)
at
org.apache.lucene.index.DocumentsWriterFlushControl.waitIfStalled(DocumentsWriterFlushControl.java:676)
at
org.apache.lucene.index.DocumentsWriter.preUpdate(DocumentsWriter.java:301)
at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:361)
at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1484)
at ...
I have not yet enabled detail logging and tried to reproduce yet, but looking
at the code, I see that DWFC.abortPendingFlushes does
try {
dwpt.abort();
doAfterFlush(dwpt);
} catch (Throwable ex) {
// ignore - keep on aborting the flush queue
}
(and the same for the blocked ones). Since the throwable is ignored, I can't
say for sure, but I've seen DWPT.abort thrown in other cases, so if it does
throw, we'd fail to call doAfterFlush and properly decrement flushBytes. This
can be a problem, right? Is it possible to do this instead:
try {
dwpt.abort();
} catch (Throwable ex) {
// ignore - keep on aborting the flush queue
} finally {
try {
doAfterFlush(dwpt);
} catch (Throwable ex2) {
// ignore - keep on aborting the flush queue
}
}
It's ugly but safer. Otherwise, maybe at least add logging for the throwable
just to make sure this is/isn't happening.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1483459 - /lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py
BUILD SUCCESSFUL on branch_4x for me - hopefully these javax.servlet issues are
all cleared up now. - Steve
On May 16, 2013, at 2:34 PM, Steve Rowe sar...@gmail.com wrote:
Thanks Mike!
I had arrived at the same fix, but didnt' commit because the smoke tester was
also complaining (after running for 30 minutes) about Solr's NOTICE.txt not
having a verbatim copy of Lucene's NOTICE.txt - this is as a result of my
changing the text in Lucene's NOTICE.txt about servlet-api.jar to include
javax.servlet-*.jar.
Tracking down why this was still true after copy/pasting Lucene's into Solr's
took a while - after I had the smoke tester print out the things it was
comparing, I realized that it wasn't comparing my local changes, but rather
the committed changes…
Anyway, I've committed a change to Solr's NOTICE.txt to make it a verbatim
copy of Lucene's NOTICE.txt, and I'm running the smoke tester again after
committing.
Steve
On May 16, 2013, at 1:19 PM, mikemcc...@apache.org wrote:
Author: mikemccand
Date: Thu May 16 17:18:59 2013
New Revision: 1483459
URL: http://svn.apache.org/r1483459
Log:
allow javax.servlet exception in lucene/replicator
Modified:
lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py
Modified: lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py
URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py?rev=1483459r1=1483458r2=1483459view=diff
==
--- lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py (original)
+++ lucene/dev/trunk/dev-tools/scripts/smokeTestRelease.py Thu May 16
17:18:59 2013
@@ -265,6 +265,9 @@ def checkAllJARs(topDir, project, svnRev
if normRoot.endswith('/contrib/dataimporthandler/lib') and
(file.startswith('mail-') or file.startswith('activation-')):
print(' **WARNING**: skipping check of %s/%s: it has javax.*
classes' % (root, file))
continue
+else:
+ if normRoot.endswith('/replicator/lib') and
file.startswith('javax.servlet'):
+continue
fullPath = '%s/%s' % (root, file)
noJavaPackageClasses('JAR file %s' % fullPath, fullPath)
if file.lower().find('lucene') != -1 or file.lower().find('solr') !=
-1:
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 472 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/472/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 9133 lines...] [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre/bin/java -XX:-UseCompressedOops -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/heapdumps -Dtests.prefix=tests -Dtests.seed=CEB10A8207D7EFB0 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/temp -Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/tests.policy -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Dfile.encoding=UTF-8 -classpath
Implementing a reader over Accumulo and FieldNorms type?
I'm experimenting with an IndexReader design over Accumulo and am wondering what valid DocValues types are for norms in the FieldInfo constructor. The actual fieldNorms method returns a numericDocValues, and norms have historically always been numeric values. Is numeric the only valid type here or are there other valid types? What is the point of this option?
[jira] [Commented] (SOLR-1093) A RequestHandler to run multiple queries in a batch
[
https://issues.apache.org/jira/browse/SOLR-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659915#comment-13659915
]
yuanyun.cn commented on SOLR-1093:
--
Just found one small issue in the code.
If we put several fq for one query, only one will be used, for example:
1.fq=datatype:41.fq=filetype:pdf.
To fix this, just need change code below:
org.apache.solr.handler.component.MultiSearchHandler.initRequestParams(SolrQueryRequest,
VectorSimpleOrderedMapObject, SimpleOrderedMapObject)
+int startPos = paramName.indexOf('.') + 1;
+localRequestParams.elementAt(queryId - 1).add(
+paramName.substring(startPos), reqParams.get(paramName));
Should be changed to:
int startPos = paramName.indexOf('.') + 1;
String[] paramsValues = reqParams.getParams(paramName);
if(paramsValues!=null)
{
for(String value: paramsValues)
{
localRequestParams.elementAt(queryId - 1).add(
paramName.substring(startPos),value);
}
A RequestHandler to run multiple queries in a batch
---
Key: SOLR-1093
URL: https://issues.apache.org/jira/browse/SOLR-1093
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Noble Paul
Assignee: Simon Willnauer
Attachments: SOLR-1093.patch
It is a common requirement that a single page requires to fire multiple
queries .In cases where these queries are independent of each other. If there
is a handler which can take in multiple queries , run them in paralll and
send the response as one big chunk it would be useful
Let us say the handler is MultiRequestHandler
{code}
requestHandler name=/multi class=solr.MultiRequestHandler/
{code}
h2.Query Syntax
The request must specify the no:of queries as count=n
Each request parameter must be prefixed with a number which denotes the query
index.optionally ,it may can also specify the handler name.
example
{code}
/multi?count=21.handler=/select1.q=a:b2.handler=/select2.q=a:c
{code}
default handler can be '/select' so the equivalent can be
{code}
/multi?count=21.q=a:b2.q=a:c
{code}
h2.The response
The response will be a ListNamedList where each NamedList will be a
response to a query.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4816) Change CloudSolrServer to send updates to the correct shard
[ https://issues.apache.org/jira/browse/SOLR-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-4816: - Attachment: SOLR-4816.patch To get the existing tests to run I needed to limit the directUpdates to only UpdateRequests that have document lists. All other requests bypass the directUpdates method and follow the main flow. Currently UpdateRequestExt also bypasses the directUpdates method and follows the main flow. There is a TODO in the UpdateRequestExt class to bake it into the UpdateRequest class. This would be a cleaner approach to getting UpdateRequestExt to work with directUpdates. Change CloudSolrServer to send updates to the correct shard --- Key: SOLR-4816 URL: https://issues.apache.org/jira/browse/SOLR-4816 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3 Reporter: Joel Bernstein Priority: Minor Attachments: SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816-sriesenberg.patch This issue changes CloudSolrServer so it routes update requests to the correct shard. This would be a nice feature to have to eliminate the document routing overhead on the Solr servers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4831) Transaction logs are leaking
[ https://issues.apache.org/jira/browse/SOLR-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Bower resolved SOLR-4831. Resolution: Duplicate Transaction logs are leaking Key: SOLR-4831 URL: https://issues.apache.org/jira/browse/SOLR-4831 Project: Solr Issue Type: Bug Reporter: Steven Bower We have a system in which a client is sending 1 record at a time (via REST) followed by a commit. This has produced ~65k tlog files and the JVM has run out of file descriptors... I grabbed a heap dump from the JVM and I can see ~52k unreachable FileDescriptors... This leads me to believe that the TransactionLog is not properly closing all of it's files before getting rid of the object... I've verified with lsof that indeed there are ~60k tlog files that are open currently.. This is Solr 4.3.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4829) transaction log reference leak
[ https://issues.apache.org/jira/browse/SOLR-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659947#comment-13659947 ] Steven Bower commented on SOLR-4829: I patched my 4.3.0 install with the attached patch on a solr instance with my broken index that was causing this issue to begin with and i see that the tlog files are limited to 10 files properly and I am not building up orphaned FileDescriptors any more. Additionally I've verified with lsof that the tlog isn't leaking open file... transaction log reference leak -- Key: SOLR-4829 URL: https://issues.apache.org/jira/browse/SOLR-4829 Project: Solr Issue Type: Bug Affects Versions: 4.1 Reporter: Yonik Seeley Assignee: Yonik Seeley Fix For: 5.0, 4.3.1 Attachments: SOLR-4829.patch, SOLR-4829.patch, SOLR-4829.patch Failure to dereference tlogs or RecentUpdates can cause old transaction logs to never be closed deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4816) Change CloudSolrServer to send updates to the correct shard
[ https://issues.apache.org/jira/browse/SOLR-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659950#comment-13659950 ] Joel Bernstein commented on SOLR-4816: -- Existing tests now run with latest patch. Still need to add tests for the new directUpdate functionality. Change CloudSolrServer to send updates to the correct shard --- Key: SOLR-4816 URL: https://issues.apache.org/jira/browse/SOLR-4816 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3 Reporter: Joel Bernstein Priority: Minor Attachments: SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816-sriesenberg.patch This issue changes CloudSolrServer so it routes update requests to the correct shard. This would be a nice feature to have to eliminate the document routing overhead on the Solr servers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4823) Split LBHttpSolrServer into two classes one for the solrj use case and one for the solr cloud use case
[ https://issues.apache.org/jira/browse/SOLR-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659604#comment-13659604 ] philip hoy edited comment on SOLR-4823 at 5/16/13 8:40 PM: --- Here is a first stab at a refactoring, it is without any additional test coverage at present and may well be a bit too much to swallow. However I am happy to revisit it. Interestingly moving the cloud load balancing code out of LBHttpSolrServer did not affect any tests so perhaps that use case could do with some extra test coverage regardless of this patch. was (Author: phloy): Here is a first stab at a refactoring, it is without any additional test coverage at present and may well be a bit too much to swallow. However I am happy to revisit it. Interestingly moving the cloud load balancing code out of LBHttpSolrServer did not affect any tests so perhaps that use case could do with some extra test coverage. Split LBHttpSolrServer into two classes one for the solrj use case and one for the solr cloud use case -- Key: SOLR-4823 URL: https://issues.apache.org/jira/browse/SOLR-4823 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: philip hoy Priority: Minor Attachments: SOLR-4823.patch The LBHttpSolrServer has too many responsibilities. It could perhaps be broken into two classes, one in solrj to be used in the place of an external load balancer that balances across a known set of solr servers defined at construction time and one in solr core to be used by the solr cloud components that balances across servers dependant on the request. To save code duplication, if much arises an abstract bass class could be introduced in to solrj. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.6.0) - Build # 459 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/459/ Java: 64bit/jdk1.6.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic Error Message: Connection to http://localhost:49252 refused Stack Trace: org.apache.http.conn.HttpHostConnectException: Connection to http://localhost:49252 refused at __randomizedtesting.SeedInfo.seed([1FE42A255BC02A46:B41E3730841CAC68]:0) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:190) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.lucene.replicator.http.HttpClientBase.executeGET(HttpClientBase.java:178) at org.apache.lucene.replicator.http.HttpReplicator.checkForUpdate(HttpReplicator.java:51) at org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.java:196) at org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.java:402) at org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic(HttpReplicatorTest.java:110) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1621 - Still Failing
is not static, so the mem estimator would count that as ram used by the
object itself.
The estimation actually includes static fields -- if it didn't you
could easily overflow memory simply by allocating static byte[]
buffers or something else. Object-level fields are garbage collected
because the reference is released after the test (unless something
else keeps it; there is no way to tell). Take a look at the LTC:
.around(new StaticFieldsInvariantRule(STATIC_LEAK_THRESHOLD, true) {
@Override
protected boolean accept(java.lang.reflect.Field field) {
// Don't count known classes that consume memory once.
if (STATIC_LEAK_IGNORED_TYPES.contains(field.getType().getName())) {
return false;
}
// Don't count references from ourselves, we're top-level.
if (field.getDeclaringClass() == LuceneTestCase.class) {
return false;
}
return super.accept(field);
}
})
Dawid
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1621 - Still Failing
: is not static, so the mem estimator would count that as ram used by the : object itself. : : The estimation actually includes static fields -- if it didn't you : could easily overflow memory simply by allocating static byte[] But clearly there is a diff between statics in the tests, and statics in classes of objects held onto by the test -- otherwise we should have started seeing way more clean up your statics failures then this when the Logger changes got committed. this test seemed to be the touchstone because... * the test maintained a static, un-nulled out, SolrRequestParser * SolrRequestParser instance have non-static refrences to a Logger ...surely if the SolrRequestParser *class* had a static var the Logger (instead of an instance var) that wouldn't have counted against the amount of memory being used by the SolrRequestParser ? i mean ... if the static vars in every class were counted against the objects of that class, the RAM estimater would be virtually useless. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4829) transaction log reference leak
[ https://issues.apache.org/jira/browse/SOLR-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659996#comment-13659996 ] Yonik Seeley commented on SOLR-4829: Thanks for verifying Steven! Committed to trunk, 4x, 4.3.1 transaction log reference leak -- Key: SOLR-4829 URL: https://issues.apache.org/jira/browse/SOLR-4829 Project: Solr Issue Type: Bug Affects Versions: 4.1 Reporter: Yonik Seeley Assignee: Yonik Seeley Fix For: 5.0, 4.3.1 Attachments: SOLR-4829.patch, SOLR-4829.patch, SOLR-4829.patch Failure to dereference tlogs or RecentUpdates can cause old transaction logs to never be closed deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4829) transaction log reference leak
[ https://issues.apache.org/jira/browse/SOLR-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-4829. Resolution: Fixed Fix Version/s: 4.4 transaction log reference leak -- Key: SOLR-4829 URL: https://issues.apache.org/jira/browse/SOLR-4829 Project: Solr Issue Type: Bug Affects Versions: 4.1 Reporter: Yonik Seeley Assignee: Yonik Seeley Fix For: 5.0, 4.4, 4.3.1 Attachments: SOLR-4829.patch, SOLR-4829.patch, SOLR-4829.patch Failure to dereference tlogs or RecentUpdates can cause old transaction logs to never be closed deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1621 - Still Failing
...surely if the SolrRequestParser *class* had a static var the Logger (instead of an instance var) that wouldn't have counted against the amount of memory being used by the SolrRequestParser ? No, it wouldn't. We collect static fields from the suite class and then traverse the object graph from these (but don't count static fields again). https://github.com/carrotsearch/randomizedtesting/blob/master/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/rules/StaticFieldsInvariantRule.java#L91 Perhaps I should add an option to dump the heaviest objects (not just fields) from that total graph estimator. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1621 - Still Failing
: ...surely if the SolrRequestParser *class* had a static var the Logger : (instead of an instance var) that wouldn't have counted against the amount : of memory being used by the SolrRequestParser ? : : No, it wouldn't. We collect static fields from the suite class and : then traverse the object graph from these (but don't count static : fields again). Now i'm completley confused. i said... the Logger used by SolrRequestParsers is not static, so the mem estimator would count that as ram used by the object itself. (the object in question being the SolrRequestParsers instance) Then you said... The estimation actually includes static fields ...it appeared that you were refering to static fields in the classes of hte objects ithe estimation was asked to look at (ie: the SolrRequestParsers class), but now i get the sense that you were refering to static fields in the test -- which was never in question, all of the fields listed in teh failure message are obviously static fields in the test class. So i think my initial understanding was correct, and we are just confusing eachother and talking in circles? -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1621 - Still Failing
The estimation actually includes static fields Yeah, I probably misunderstood something along the way, apologies. When you look at the code I linked to things are pretty simple: 1) collect values of static fields from the test suite class (and its superclasses), 2) for non-null values, estimate the RAM used by those objects and their referenced graph of objects. I think your understanding was correct (? :) Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Edit permission for Lucene and Solr wikis' ContributorsGroup pages
FYI: After consultation with the PMC, I've moved all committers from ContributorsGroup to AdminGroup, the idea being that all committers should be able to add people to ContributorsGroup. This change affected just three people: Christian Moen, Shalin Mangar (who's now on the PMC anyway), and Shawn Heisey. Please let me know if I've missed anybody. Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_21) - Build # 2827 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2827/ Java: 64bit/jdk1.7.0_21 -XX:+UseCompressedOops -XX:+UseParallelGC 5 tests failed. FAILED: org.apache.solr.client.solrj.embedded.TestEmbeddedSolrServer.testShutdown Error Message: Stack Trace: org.apache.solr.common.SolrException: at __randomizedtesting.SeedInfo.seed([BC53272C0441EB7A:5F252EB9E33B7E08]:0) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:262) at org.apache.solr.core.CoreContainer.load(CoreContainer.java:219) at org.apache.solr.core.CoreContainer.init(CoreContainer.java:149) at org.apache.solr.client.solrj.embedded.AbstractEmbeddedSolrServerTestCase.setUp(AbstractEmbeddedSolrServerTestCase.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:771) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:722) Caused by: java.io.IOException: The filename, directory name, or volume label syntax is incorrect at java.io.WinNTFileSystem.canonicalize0(Native Method) at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:414) at java.io.File.getCanonicalPath(File.java:589) at
[jira] [Commented] (SOLR-3076) Solr should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660124#comment-13660124 ] Tom Burton-West commented on SOLR-3076: --- I'd like to test this out with some real data and would like to use the XmlUpdateRequestHandler. Since SOLR-3535 was folded in here, I looked here to try to find the XML syntax to use. I couldn't tell from a quick read of the code what the XML syntax would be to actually use to add a parent and children. Would it be possible to add a test similar to solr/core/src/test/org.apache.solr.handler/XmlUpdateRequestHandlerTest? I would assume all that the xml in XmlUpdateRequestHandlerTest could be replaced with the proper xml to index a block consisting of a parent and its children i.e in the test replace: String xml = doc boost=\5.5\ + field name=\id\ boost=\2.2\12345/field + field name=\name\kitten/field + field name=\cat\ boost=\3\aaa/field + field name=\cat\ boost=\4\bbb/field + field name=\cat\ boost=\5\bbb/field + field name=\ab\aamp;b/field + /doc; with whatever xml is needed to index a block (parent and children). Solr should support block joins --- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 5.0, 4.4 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660197#comment-13660197
]
Koji Sekiguchi commented on SOLR-4751:
--
Looks good! I'll commit shortly.
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Attachments: SOLR-4751.patch, SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-4751:
-
Fix Version/s: 4.3.1
4.4
5.0
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4751.patch, SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi resolved SOLR-4751.
--
Resolution: Fixed
Committed on trunk, branch_4x and lucene_solr_4_3. Thanks!
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4751.patch, SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4751) The replication problem of the file in a subdirectory.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660264#comment-13660264
]
Minoru Osuka commented on SOLR-4751:
Sekiguchi-san,
Thank you so much for your help!
The replication problem of the file in a subdirectory.
--
Key: SOLR-4751
URL: https://issues.apache.org/jira/browse/SOLR-4751
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 4.2.1
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 5.0, 4.4, 4.3.1
Attachments: SOLR-4751.patch, SOLR-4751.patch
When set lang/stopwords_ja.txt to confFiles in replication settings,
{code:xml}
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str
name=confFilesschema.xml,stopwords.txt,lang/stopwords_ja.txt/str
/lst
/requestHandler
{code}
Only stopwords_ja.txt exists in solr/collection1/conf/lang directory on slave
node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4834) Surround QParser should enable query text analysis
Isaac Hebsh created SOLR-4834:
-
Summary: Surround QParser should enable query text analysis
Key: SOLR-4834
URL: https://issues.apache.org/jira/browse/SOLR-4834
Project: Solr
Issue Type: Improvement
Components: query parsers
Affects Versions: 4.3
Reporter: Isaac Hebsh
Fix For: 5.0, 4.4
When using surround query parser, the query terms are not being analyzed. The
basic example is lower case, of course. This is probably an intended behaviour,
not a bug.
I suggest one more query parameter, which determines whether to do analysis or
not. something like this:
{code}
_query_:{!surround df=myfield analyze=true}SpinPoint 7n GB18030
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: documentation-lint warning
On Thu, May 16, 2013 at 7:55 PM, Robert Muir rcm...@gmail.com wrote: FYI we currently have: [exec] Crawl/parse... [exec] [exec] file:///build/docs/analyzers-common/org/apache/lucene/analysis/util/FilteringTokenFilter.html [exec] WARNING: anchor version appears more than once I forget why this is a warning and not a hard fail, but we should probably investigate: it seems wrong. The reason why there were 2 anchors named version is that javadoc added such an anchor for the protected field called version and the class javadocs contained another anchor named version to describe the way FilteringTokenFilter handles the lucene match version. I renamed the 2nd one to fix this warning. +1 to fail hard on duplicate anchor names. -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1375) BloomFilter on a field
[ https://issues.apache.org/jira/browse/SOLR-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660354#comment-13660354 ] Isaac Hebsh commented on SOLR-1375: --- Hi, I know that this issue is not active for a long while, But I could not understand why. What work should be done in order to make the issue resolved? BloomFilter on a field -- Key: SOLR-1375 URL: https://issues.apache.org/jira/browse/SOLR-1375 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.4 Reporter: Jason Rutherglen Priority: Minor Fix For: 4.4 Attachments: SOLR-1375.patch, SOLR-1375.patch, SOLR-1375.patch, SOLR-1375.patch, SOLR-1375.patch Original Estimate: 120h Remaining Estimate: 120h * A bloom filter is a read only probabilistic set. Its useful for verifying a key exists in a set, though it returns false positives. http://en.wikipedia.org/wiki/Bloom_filter * The use case is indexing in Hadoop and checking for duplicates against a Solr cluster (which when using term dictionary or a query) is too slow and exceeds the time consumed for indexing. When a match is found, the host, segment, and term are returned. If the same term is found on multiple servers, multiple results are returned by the distributed process. (We'll need to add in the core name I just realized). * When new segments are created, and commit is called, a new bloom filter is generated from a given field (default:id) by iterating over the term dictionary values. There's a bloom filter file per segment, which is managed on each Solr shard. When segments are merged away, their corresponding .blm files is also removed. In a future version we'll have a central server for the bloom filters so we're not abusing the thread pool of the Solr proxy and the networking of the Solr cluster (this will be done sooner than later after testing this version). I held off because the central server requires syncing the Solr servers' files (which is like reverse replication). * The patch uses the BloomFilter from Hadoop 0.20. I want to jar up only the necessary classes so we don't have a giant Hadoop jar in lib. http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/util/bloom/BloomFilter.html * Distributed code is added and seems to work, I extended TestDistributedSearch to test over multiple HTTP servers. I chose this approach rather than the manual method used by (for example) TermVectorComponent.testDistributed because I'm new to Solr's distributed search and wanted to learn how it works (the stages are confusing). Using this method, I didn't need to setup multiple tomcat servers and manually execute tests. * We need more of the bloom filter options passable via solrconfig * I'll add more test cases -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4834) Surround QParser should enable query text analysis
[
https://issues.apache.org/jira/browse/SOLR-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isaac Hebsh updated SOLR-4834:
--
Labels: analysis qparserplugin surround (was: )
Surround QParser should enable query text analysis
--
Key: SOLR-4834
URL: https://issues.apache.org/jira/browse/SOLR-4834
Project: Solr
Issue Type: Improvement
Components: query parsers
Affects Versions: 4.3
Reporter: Isaac Hebsh
Labels: analysis, qparserplugin, surround
Fix For: 5.0, 4.4
When using surround query parser, the query terms are not being analyzed. The
basic example is lower case, of course. This is probably an intended
behaviour, not a bug.
I suggest one more query parameter, which determines whether to do analysis
or not. something like this:
{code}
_query_:{!surround df=myfield analyze=true}SpinPoint 7n GB18030
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4835) highlighting in combination with join does not work in solr 4.0 - 4.2
Matthias Herrmann created SOLR-4835:
---
Summary: highlighting in combination with join does not work in
solr 4.0 - 4.2
Key: SOLR-4835
URL: https://issues.apache.org/jira/browse/SOLR-4835
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 4.0-ALPHA
Reporter: Matthias Herrmann
q= {!join from=manu_id_s to=id}ipod
by highlighting this query it does not highlights the required field ,hence
highlighting not works in join queries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4835) highlighting in combination with join does not work in solr 4.0 - 4.2
[
https://issues.apache.org/jira/browse/SOLR-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herrmann updated SOLR-4835:
Description:
I need to highlight results based on a query that contains a join operation.
I made a simple example by indexing example/exampledocs/*.xml which ships with
standard Solr distribution. Having these documents indexed to the example
server I run the following query:
[http://localhost:8983/solr/collection1/select?q=belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*
]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{
name:[emBelkin/em Mobile Power Cord for iPod w/ Dock],
manu_id_s:[embelkin/em],
manu:[emBelkin/em]},
IW-02:{
manu_id_s:[embelkin/em],
manu:[emBelkin/em]}}
{code}
So highlighting works fine. BUT when running this query:
[http://localhost:8983/solr/collection1/select?q=\{!join+from=id+to=id\}belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{},
IW-02:{}}
{code}
As you can see highlighting does not work in combination with join. Is this a
bug or am I missing something?
was:
q= {!join from=manu_id_s to=id}ipod
by highlighting this query it does not highlights the required field ,hence
highlighting not works in join queries.
highlighting in combination with join does not work in solr 4.0 - 4.2
-
Key: SOLR-4835
URL: https://issues.apache.org/jira/browse/SOLR-4835
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 4.0-ALPHA
Reporter: Matthias Herrmann
Labels: documentation
I need to highlight results based on a query that contains a join operation.
I made a simple example by indexing example/exampledocs/*.xml which ships
with standard Solr distribution. Having these documents indexed to the
example server I run the following query:
[http://localhost:8983/solr/collection1/select?q=belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*
]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{
name:[emBelkin/em Mobile Power Cord for iPod w/ Dock],
manu_id_s:[embelkin/em],
manu:[emBelkin/em]},
IW-02:{
manu_id_s:[embelkin/em],
manu:[emBelkin/em]}}
{code}
So highlighting works fine. BUT when running this query:
[http://localhost:8983/solr/collection1/select?q=\{!join+from=id+to=id\}belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{},
IW-02:{}}
{code}
As you can see highlighting does not work in combination with join. Is this a
bug or am I missing something?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4835) highlighting in combination with join does not work in solr 4.0 - 4.2
[
https://issues.apache.org/jira/browse/SOLR-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herrmann updated SOLR-4835:
Component/s: query parsers
highlighting in combination with join does not work in solr 4.0 - 4.2
-
Key: SOLR-4835
URL: https://issues.apache.org/jira/browse/SOLR-4835
Project: Solr
Issue Type: Bug
Components: highlighter, query parsers
Affects Versions: 4.0-ALPHA
Reporter: Matthias Herrmann
Labels: documentation
I need to highlight results based on a query that contains a join operation.
I made a simple example by indexing example/exampledocs/*.xml which ships
with standard Solr distribution. Having these documents indexed to the
example server I run the following query:
[http://localhost:8983/solr/collection1/select?q=belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*
]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{
name:[emBelkin/em Mobile Power Cord for iPod w/ Dock],
manu_id_s:[embelkin/em],
manu:[emBelkin/em]},
IW-02:{
manu_id_s:[embelkin/em],
manu:[emBelkin/em]}}
{code}
So highlighting works fine. BUT when running this query:
[http://localhost:8983/solr/collection1/select?q=\{!join+from=id+to=id\}belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{},
IW-02:{}}
{code}
As you can see highlighting does not work in combination with join. Is this a
bug or am I missing something?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4835) highlighting in combination with join does not work in solr 4.0 - 4.2
[
https://issues.apache.org/jira/browse/SOLR-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herrmann updated SOLR-4835:
Description:
I need to highlight results based on a query that contains a join operation. I
want to highlight docs that occur in the to set which is in my
I made a simple example by indexing example/exampledocs/*.xml which ships with
standard Solr distribution. Having these documents indexed to the example
server I run the following query:
[http://localhost:8983/solr/collection1/select?q=belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*
]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{
name:[emBelkin/em Mobile Power Cord for iPod w/ Dock],
manu_id_s:[embelkin/em],
manu:[emBelkin/em]},
IW-02:{
manu_id_s:[embelkin/em],
manu:[emBelkin/em]}}
{code}
So highlighting works fine. BUT when running this query:
[http://localhost:8983/solr/collection1/select?q=\{!join+from=id+to=id\}belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{},
IW-02:{}}
{code}
As you can see highlighting does not work in combination with join. Is this a
bug or am I missing something?
was:
I need to highlight results based on a query that contains a join operation.
I made a simple example by indexing example/exampledocs/*.xml which ships with
standard Solr distribution. Having these documents indexed to the example
server I run the following query:
[http://localhost:8983/solr/collection1/select?q=belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*
]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{
name:[emBelkin/em Mobile Power Cord for iPod w/ Dock],
manu_id_s:[embelkin/em],
manu:[emBelkin/em]},
IW-02:{
manu_id_s:[embelkin/em],
manu:[emBelkin/em]}}
{code}
So highlighting works fine. BUT when running this query:
[http://localhost:8983/solr/collection1/select?q=\{!join+from=id+to=id\}belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{},
IW-02:{}}
{code}
As you can see highlighting does not work in combination with join. Is this a
bug or am I missing something?
highlighting in combination with join does not work in solr 4.0 - 4.2
-
Key: SOLR-4835
URL: https://issues.apache.org/jira/browse/SOLR-4835
Project: Solr
Issue Type: Bug
Components: highlighter, query parsers
Affects Versions: 4.0-ALPHA
Reporter: Matthias Herrmann
Labels: documentation
I need to highlight results based on a query that contains a join operation.
I want to highlight docs that occur in the to set which is in my
I made a simple example by indexing example/exampledocs/*.xml which ships
with standard Solr distribution. Having these documents indexed to the
example server I run the following query:
[http://localhost:8983/solr/collection1/select?q=belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*
]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{
name:[emBelkin/em Mobile Power Cord for iPod w/ Dock],
manu_id_s:[embelkin/em],
manu:[emBelkin/em]},
IW-02:{
manu_id_s:[embelkin/em],
manu:[emBelkin/em]}}
{code}
So highlighting works fine. BUT when running this query:
[http://localhost:8983/solr/collection1/select?q=\{!join+from=id+to=id\}belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{},
IW-02:{}}
{code}
As you can see highlighting does not work in combination with join. Is this a
bug or am I missing something?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4835) highlighting in combination with join does not work in solr 4.0 - 4.2
[
https://issues.apache.org/jira/browse/SOLR-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herrmann updated SOLR-4835:
Description:
I need to highlight results based on a query that contains a join operation. I
want to highlight docs that occur in the to set which is in my understanding
the final result set of the join operation.
I made a simple example by indexing example/exampledocs/*.xml which ships with
standard Solr distribution. Having these documents indexed to the example
server I run the following query:
[http://localhost:8983/solr/collection1/select?q=belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*
]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{
name:[emBelkin/em Mobile Power Cord for iPod w/ Dock],
manu_id_s:[embelkin/em],
manu:[emBelkin/em]},
IW-02:{
manu_id_s:[embelkin/em],
manu:[emBelkin/em]}}
{code}
So highlighting works fine. BUT when running this query:
[http://localhost:8983/solr/collection1/select?q=\{!join+from=id+to=id\}belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{},
IW-02:{}}
{code}
As you can see highlighting does not work in combination with join. Is this a
bug or am I missing something?
was:
I need to highlight results based on a query that contains a join operation. I
want to highlight docs that occur in the to set which is in my
I made a simple example by indexing example/exampledocs/*.xml which ships with
standard Solr distribution. Having these documents indexed to the example
server I run the following query:
[http://localhost:8983/solr/collection1/select?q=belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*
]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{
name:[emBelkin/em Mobile Power Cord for iPod w/ Dock],
manu_id_s:[embelkin/em],
manu:[emBelkin/em]},
IW-02:{
manu_id_s:[embelkin/em],
manu:[emBelkin/em]}}
{code}
So highlighting works fine. BUT when running this query:
[http://localhost:8983/solr/collection1/select?q=\{!join+from=id+to=id\}belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{},
IW-02:{}}
{code}
As you can see highlighting does not work in combination with join. Is this a
bug or am I missing something?
highlighting in combination with join does not work in solr 4.0 - 4.2
-
Key: SOLR-4835
URL: https://issues.apache.org/jira/browse/SOLR-4835
Project: Solr
Issue Type: Bug
Components: highlighter, query parsers
Affects Versions: 4.0-ALPHA
Reporter: Matthias Herrmann
Labels: documentation
I need to highlight results based on a query that contains a join operation.
I want to highlight docs that occur in the to set which is in my
understanding the final result set of the join operation.
I made a simple example by indexing example/exampledocs/*.xml which ships
with standard Solr distribution. Having these documents indexed to the
example server I run the following query:
[http://localhost:8983/solr/collection1/select?q=belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*
]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{
name:[emBelkin/em Mobile Power Cord for iPod w/ Dock],
manu_id_s:[embelkin/em],
manu:[emBelkin/em]},
IW-02:{
manu_id_s:[embelkin/em],
manu:[emBelkin/em]}}
{code}
So highlighting works fine. BUT when running this query:
[http://localhost:8983/solr/collection1/select?q=\{!join+from=id+to=id\}belkindefType=lucenewt=jsonindent=truehl=truehl.fl=*]
In the query result the section highlighting looks like:
{code}
highlighting:{
F8V7067-APL-KIT:{},
IW-02:{}}
{code}
As you can see highlighting does not work in combination with join. Is this a
bug or am I missing something?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
