[JENKINS] Lucene-Solr-SmokeRelease-4.3 - Build # 4 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-4.3/4/
No tests ran.
Build Log:
[...truncated 32711 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeRelease
[copy] Copying 401 files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeRelease/lucene
[copy] Copying 194 files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeRelease/solr
[exec] JAVA6_HOME is /home/hudson/tools/java/latest1.6
[exec] JAVA7_HOME is /home/hudson/tools/java/latest1.7
[exec] NOTE: output encoding is US-ASCII
[exec]
[exec] Load release URL
"file:/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lTraceback
(most recent call last):
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scriptucene/build/fakeRelease/"...
[exec]
[exec] Test Lucene...
[exec] test basics...
[exec] get KEYS
[exec] 0.1 MB
[exec]
[exec] command "gpg --homedir
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeReleaseTmp/lucene.gpg
--import /usr/home/hudson/hudson-slave/ws/smokeTestRelease.py", line 1385, in
[exec] main()
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py",
line 1331, in main
[exec] smokeTest(baseURL, version, tmpDir, isSigned)
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py",
line 1364, in
smokeTestorkspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeReleaseTmp/lucene.KEYS"
failed:
[exec]
[exec] checkSigs('lucene', lucenePath, version, tmpDir, isSigned)
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py",
line 365, in checkSigs
[exec] '%s/%s.gpg.import.log 2>&1' % (tmpDir, project))
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py",
line 513, in run
[exec] printFileContents(logFile)
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py",
line 497, in printFileContents
[exec] txt = codecs.open(fileName, 'r',
encoding=sys.getdefaultencoding(), errors='replace').read()
[exec] File "/usr/local/lib/python3.2/codecs.py", line 884, in open
[exec] file = builtins.open(filename, mode, buffering)
[exec] IOError: [Errno 2] No such file or directory:
'/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeReleaseTmp/lucene.gpg.import.log
2>&1'
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/build.xml:303:
exec returned: 1
Total time: 17 minutes 27 seconds
Build step 'Invoke Ant' marked build as failure
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-4048) Add a "findRecursive" method to NamedList
[
https://issues.apache.org/jira/browse/SOLR-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661832#comment-13661832
]
Shawn Heisey commented on SOLR-4048:
Trunk commit r1484386 to improve and clean up new method. All tests and
precommit passed. Will run tests and precommit on 4x before backporting
tomorrow.
> Add a "findRecursive" method to NamedList
> -
>
> Key: SOLR-4048
> URL: https://issues.apache.org/jira/browse/SOLR-4048
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 4.4
>
> Attachments: SOLR-4048-cleanup.patch, SOLR-4048.patch,
> SOLR-4048.patch, SOLR-4048.patch, SOLR-4048.patch, SOLR-4048.patch,
> SOLR-4048.patch, SOLR-4048.patch
>
>
> Most of the time when accessing data from a NamedList, what you'll be doing
> is using get() to retrieve another NamedList, and doing so over and over
> until you reach the final level, where you'll actually retrieve the value you
> want.
> I propose adding a method to NamedList which would do all that heavy lifting
> for you. I created the following method for my own code. It could be
> adapted fairly easily for inclusion into NamedList itself. The only reason I
> did not include it as a patch is because I figure you'll want to ensure it
> meets all your particular coding guidelines, and that the JavaDoc is much
> better than I have done here:
> {code}
> /**
>* Recursively parse a NamedList and return the value at the last level,
>* assuming that the object found at each level is also a NamedList. For
>* example, if "response" is the NamedList response from the Solr4 mbean
>* handler, the following code makes sense:
>*
>* String coreName = (String) getRecursiveFromResponse(response, new
>* String[] { "solr-mbeans", "CORE", "core", "stats", "coreName" });
>*
>*
>* @param namedList the NamedList to parse
>* @param args A list of values to recursively request
>* @return the object at the last level.
>* @throws SolrServerException
>*/
> @SuppressWarnings("unchecked")
> private final Object getRecursiveFromResponse(
> NamedList namedList, String[] args)
> throws SolrServerException
> {
> NamedList list = null;
> Object value = null;
> try
> {
> for (String key : args)
> {
> if (list == null)
> {
> list = namedList;
> }
> else
> {
> list = (NamedList) value;
> }
> value = list.get(key);
> }
> return value;
> }
> catch (Exception e)
> {
> throw new SolrServerException(
> "Failed to recursively parse
> NamedList", e);
> }
> }
> {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
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 266 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/266/
4 tests failed.
REGRESSION: org.apache.lucene.spatial.DistanceStrategyTest.testDistanceOrder
{strategy=recursive_quad}
Error Message:
Not equal for doc 0 expected:<2.827493667602539> but was:<180.0>
Stack Trace:
java.lang.AssertionError: Not equal for doc 0 expected:<2.827493667602539> but
was:<180.0>
at
__randomizedtesting.SeedInfo.seed([F4A4BB00B127FF78:76CC5EC69BC981D0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:443)
at
org.apache.lucene.spatial.StrategyTestCase.checkValueSource(StrategyTestCase.java:227)
at
org.apache.lucene.spatial.DistanceStrategyTest.checkDistValueSource(DistanceStrategyTest.java:124)
at
org.apache.lucene.spatial.DistanceStrategyTest.testDistanceOrder(DistanceStrategyTest.java:95)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at
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)
REGRESSION: org.apache.lucene.spatial.DistanceStrategyTest.testDistanceOrder
{strategy=termquery_geohash}
Error Message:
Not equal for doc 0 expected:<2.827493667602539> but wa
[jira] [Commented] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661866#comment-13661866 ] Elran Dvir commented on SOLR-2894: -- Hi, I want to report a problem that we found in the patch of March 21st. It seems that the problem Shahar reported is now solved, but there is another similar problem. In short, the problem seems to be related to facet.limit per field definition and the symptom is that a distributed pivot returns less terms than expected. Here's a simple scenario: if I run a distributed pivot such as: http://myHost:8999/solr/core-B/select?shards=myHost:8999/solr/core-A&q=*:*&wt=xml&facet=true&facet.pivot=field_A&rows=0&facet.limit=-1&facet.sort=index it will return exactly number of terms for field_A as expected. On the other hand, if I use f..facet.limit=-1: http://myHost:8999/solr/core-B/select?shards=myHost:8999/solr/core-A&q=*:*&wt=xml&facet=true&facet.pivot=field_A&rows=0&f.field_A.facet.limit=-1&facet.sort=index then it will return at most 100 terms for field_A. I'll appreciate your help with this. Thanks. > Implement distributed pivot faceting > > > Key: SOLR-2894 > URL: https://issues.apache.org/jira/browse/SOLR-2894 > Project: Solr > Issue Type: Improvement >Reporter: Erik Hatcher > Fix For: 4.4 > > Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, > SOLR-2894-reworked.patch > > > Following up on SOLR-792, pivot faceting currently only supports > undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-4048) Add a "findRecursive" method to NamedList
[
https://issues.apache.org/jira/browse/SOLR-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661883#comment-13661883
]
Uwe Schindler commented on SOLR-4048:
-
All fine now!
> Add a "findRecursive" method to NamedList
> -
>
> Key: SOLR-4048
> URL: https://issues.apache.org/jira/browse/SOLR-4048
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 4.4
>
> Attachments: SOLR-4048-cleanup.patch, SOLR-4048.patch,
> SOLR-4048.patch, SOLR-4048.patch, SOLR-4048.patch, SOLR-4048.patch,
> SOLR-4048.patch, SOLR-4048.patch
>
>
> Most of the time when accessing data from a NamedList, what you'll be doing
> is using get() to retrieve another NamedList, and doing so over and over
> until you reach the final level, where you'll actually retrieve the value you
> want.
> I propose adding a method to NamedList which would do all that heavy lifting
> for you. I created the following method for my own code. It could be
> adapted fairly easily for inclusion into NamedList itself. The only reason I
> did not include it as a patch is because I figure you'll want to ensure it
> meets all your particular coding guidelines, and that the JavaDoc is much
> better than I have done here:
> {code}
> /**
>* Recursively parse a NamedList and return the value at the last level,
>* assuming that the object found at each level is also a NamedList. For
>* example, if "response" is the NamedList response from the Solr4 mbean
>* handler, the following code makes sense:
>*
>* String coreName = (String) getRecursiveFromResponse(response, new
>* String[] { "solr-mbeans", "CORE", "core", "stats", "coreName" });
>*
>*
>* @param namedList the NamedList to parse
>* @param args A list of values to recursively request
>* @return the object at the last level.
>* @throws SolrServerException
>*/
> @SuppressWarnings("unchecked")
> private final Object getRecursiveFromResponse(
> NamedList namedList, String[] args)
> throws SolrServerException
> {
> NamedList list = null;
> Object value = null;
> try
> {
> for (String key : args)
> {
> if (list == null)
> {
> list = namedList;
> }
> else
> {
> list = (NamedList) value;
> }
> value = list.get(key);
> }
> return value;
> }
> catch (Exception e)
> {
> throw new SolrServerException(
> "Failed to recursively parse
> NamedList", e);
> }
> }
> {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-4841) DetectedLanguage constructor should be public
Maciej Lizewski created SOLR-4841: - Summary: DetectedLanguage constructor should be public Key: SOLR-4841 URL: https://issues.apache.org/jira/browse/SOLR-4841 Project: Solr Issue Type: Bug Reporter: Maciej Lizewski org.apache.solr.update.processor.DetectedLanguage constructor should be public. Without that it is impossible to create owne class extending LanguageIdentifierUpdateProcessor. LanguageIdentifierUpdateProcessor base class needs detectLanguage(String content) function to return listy of DetectedLanguage's but you cannot create such objects because constructor is accessible only in same package (org.apache.solr.update.processor). -- 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-4841) DetectedLanguage constructor should be public
[ https://issues.apache.org/jira/browse/SOLR-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661991#comment-13661991 ] Uwe Schindler commented on SOLR-4841: - protected should be enough! > DetectedLanguage constructor should be public > - > > Key: SOLR-4841 > URL: https://issues.apache.org/jira/browse/SOLR-4841 > Project: Solr > Issue Type: Bug >Reporter: Maciej Lizewski > > org.apache.solr.update.processor.DetectedLanguage constructor should be > public. Without that it is impossible to create owne class extending > LanguageIdentifierUpdateProcessor. > LanguageIdentifierUpdateProcessor base class needs detectLanguage(String > content) function to return listy of DetectedLanguage's but you cannot create > such objects because constructor is accessible only in same package > (org.apache.solr.update.processor). -- 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-4841) DetectedLanguage constructor should be public
[ https://issues.apache.org/jira/browse/SOLR-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662013#comment-13662013 ] Maciej Lizewski commented on SOLR-4841: --- I am OK with that. My point was that it is impossible to extend LanguageIdentifierUpdateProcessor with own custom implementation, because constructor does not have any visibility modifier, so it is accessible only from same package. > DetectedLanguage constructor should be public > - > > Key: SOLR-4841 > URL: https://issues.apache.org/jira/browse/SOLR-4841 > Project: Solr > Issue Type: Bug >Reporter: Maciej Lizewski > > org.apache.solr.update.processor.DetectedLanguage constructor should be > public. Without that it is impossible to create owne class extending > LanguageIdentifierUpdateProcessor. > LanguageIdentifierUpdateProcessor base class needs detectLanguage(String > content) function to return listy of DetectedLanguage's but you cannot create > such objects because constructor is accessible only in same package > (org.apache.solr.update.processor). -- 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] (LUCENE-5010) Getting a Poterstemmer error in Solr
Mark Streitman created LUCENE-5010:
--
Summary: Getting a Poterstemmer error in Solr
Key: LUCENE-5010
URL: https://issues.apache.org/jira/browse/LUCENE-5010
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis, modules/spellchecker
Affects Versions: 3.6.1
Environment: Windows 7 64bit
Reporter: Mark Streitman
Java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
is dying from an error in porterstemmer.
This is just like the error listed from 2011
https://issues.apache.org/jira/browse/LUCENE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070153#comment-13070153
Below is the log file that is generated
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x02b08ce1, pid=3208,
tid=4688
#
# JRE version: 7.0-b147
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b17 mixed mode windows-amd64
compressed oops)
# Problematic frame:
# J org.apache.lucene.analysis.PorterStemmer.stem(I)Z
#
# Failed to write core dump. Minidumps are not enabled by default on client
versions of Windows
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
--- T H R E A D ---
Current thread (0x0f57f000): JavaThread
"http-localhost-127.0.0.1-8080-5" daemon [_thread_in_Java, id=4688,
stack(0x0b25,0x0b35)]
siginfo: ExceptionCode=0xc005, reading address 0x0002fd8be046
Registers:
RAX=0x0001, RBX=0x, RCX=0xfd8be038,
RDX=0x0065
RSP=0x0b34e950, RBP=0x, RSI=0x,
RDI=0x0003
R8 =0xfd8be010, R9 =0xfffe, R10=0x0065,
R11=0x0032
R12=0x, R13=0x02b08c88, R14=0x0003,
R15=0x0f57f000
RIP=0x02b08ce1, EFLAGS=0x00010286
Top of Stack: (sp=0x0b34e950)
0x0b34e950: 00650072
0x0b34e960: fd8be010 0001e053f560
0x0b34e970: fd8bdbb0
0x0b34e980: 0b34ea08 026660d8
0x0b34e990: fd8bdfe0 026660d8
0x0b34e9a0: 0b34ea08 026663d0
0x0b34e9b0: 026663d0
0x0b34e9c0: fd8be010 0b34e9c8
0x0b34e9d0: d2e598d2 0b34ea30
0x0b34e9e0: d2e5a290 d3fe7bc8
0x0b34e9f0: d2e59918 0b34e9b8
0x0b34ea00: 0b34ea40 fd8be010
0x0b34ea10: 02a502c4 0004
0x0b34ea20: fd8bdbb0
0x0b34ea30: fd8be010 02a502c4
0x0b34ea40: f5d70090 fd8bdf30
Instructions: (pc=0x02b08ce1)
0x02b08cc1: 41 83 c1 fb 4c 63 f7 42 0f b7 5c 71 10 89 5c 24
0x02b08cd1: 04 8b c7 83 c0 fe 0f b7 54 41 10 8b df 83 c3 fc
0x02b08ce1: 40 0f b7 6c 59 10 83 c7 fd 44 0f b7 6c 79 10 41
0x02b08cf1: 83 fa 69 0f 84 07 03 00 00 49 b8 d8 31 4e e0 00
Register to memory mapping:
RAX=0x0001 is an unknown value
RBX=0x is an unallocated location in the heap
RCX=0xfd8be038 is an oop
[C
- klass: {type array char}
- length: 50
RDX=0x0065 is an unknown value
RSP=0x0b34e950 is pointing into the stack for thread: 0x0f57f000
RBP=0x is an unknown value
RSI=0x is an unknown value
RDI=0x0003 is an unknown value
R8 =0xfd8be010 is an oop
org.apache.lucene.analysis.PorterStemmer
- klass: 'org/apache/lucene/analysis/PorterStemmer'
R9 =0xfffe is an unallocated location in the heap
R10=0x0065 is an unknown value
R11=0x0032 is an unknown value
R12=0x is an unknown value
R13=0x02b07c10 [CodeBlob (0x02b07c10)]
Framesize: 12
R14=0x0003 is an unknown value
R15=0x0f57f000 is a thread
Stack: [0x0b25,0x0b35], sp=0x0b34e950, free
space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J org.apache.lucene.analysis.PorterStemmer.stem(I)Z
[error occurred during error reporting (printing native stack), id 0xc005]
--- P R O C E S S ---
Java Threads: ( => current thread )
0x08570800 JavaThread "http-localhost-127.0.0.1-8080-21" daemon
[_thread_blocked, id=5652, stack(0x0c81,0x0c91)]
0x05eb5800 JavaThread "http-localhost-127.0.0.1-8080-20" dae
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.6.0) - Build # 472 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/472/ Java: 64bit/jdk1.6.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. REGRESSION: org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic Error Message: Connection to http://localhost:51800 refused Stack Trace: org.apache.http.conn.HttpHostConnectException: Connection to http://localhost:51800 refused at __randomizedtesting.SeedInfo.seed([57D348FF93F4CB24:FC2955EA4C284D0A]: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)
ExternalDocValuesFilterReader progress?
In march, there was so effort at looking at cleaner ways to integrate external data: http://mail-archives.apache.org/mod_mbox/lucene-dev/201303.mbox/%3cc2e7cc37-52f2-4527-a919-a071d26f9...@flax.co.uk%3E Any updates on this? Thanks Ryan
RE: have developer question about ClobTransformer and DIH
I think you're confusing the hierarchy of your database's types with the hierarchy in Java. In Java, a java.sql.Blob and a java.sql.Clob are 2 different things. They do not extend a common ancestor (excpt java.lang.Object). To write code that deals with both means you need to have separate paths for each object type. There is no way around this. (Compare the situation with Integer, Float, BigDecimal, etc, which all extend Number...In this case, your jdbc code can just expect a Number back from the database regardless of what object a particular jdbc driver decided to return to you.) James Dyer Ingram Content Group (615) 213-4311 -Original Message- From: geeky2 [mailto:gee...@hotmail.com] Sent: Friday, May 17, 2013 9:01 PM To: dev@lucene.apache.org Subject: RE: have developer question about ClobTransformer and DIH i still have a disconnect on this (see below) i have been reading on the informix site about BLOB, CLOB and TEXT types. *i miss-stated earlier that a TEXT type "is another type of informix blob" - after reading the dox - this is not true.* >> I think what it comes down to is that a Clob "is-not-a" Blob. << the informix docs indicate the opposite. CLOB and BLOB are sub-classes of smart object types. what is a smart object type (the super class for BLOB and CLOB): http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqlr.doc/sqlrmst136.htm what is a BLOB type: http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqlr.doc/sqlrmst136.htm what is a CLOB type: http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqlr.doc/sqlrmst136.htm what is a TEXT type: http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqlr.doc/sqlrmst136.htm after reading the above - my disconnect lies with the following: if an informix TEXT type is basically text - then why did solr return the two TEXT fields as binary addresses, when i removed all references to ClobTransformer and the clob="true" switches from the fields in the db-config.xml file?? if TEXT is just text, then there should be no need to leverage ClobTransformer and to "cast" TEXT type fields as CLOBs. see my earlier post on the solr users group for the detail: http://lucene.472066.n3.nabble.com/having-trouble-storing-large-text-blob-fields-returns-binary-address-in-search-results-td4063979.html#a4064260 mark -- View this message in context: http://lucene.472066.n3.nabble.com/have-developer-question-about-ClobTransformer-and-DIH-tp4064256p4064323.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Created] (SOLR-4827) fuzzy search problem
Note, I'm rapidly catching up so I just skimmed... but is it possible that your imports are replacing older documents with new documents that don't happen to match? Looking at numDocs/maxDoc in the admin GUI should tell you this, the delta between those two numbers is the number of replaced documents. Best Erick On Thu, May 16, 2013 at 3:59 AM, vishal parekh (JIRA) wrote: > vishal parekh created SOLR-4827: > --- > > Summary: fuzzy search problem > Key: SOLR-4827 > URL: https://issues.apache.org/jira/browse/SOLR-4827 > Project: Solr > Issue Type: Bug > Components: search > Affects Versions: 4.3, 4.2 > Environment: OS - ubuntu > Server - Jboss 7 > Reporter: vishal parekh > > > I am periodically import/index records into solr server. > > (1) so, suppose first, import 40 records, commited. > and then do fuzzy search on it, and works fine. > > (2) import another 10 records, commited. fuzzy search works fine. > > (3) import another 5 records, commited. now, when i do fuzzy search on > not these new records but above older records; it gives me lesser records > then previous. > > say after 1st import it gives me 3000 records (from 40) for any fuzzy > search, now on same data it returns only 1000 records (from 40) for same > search. > > above steps are just example, its not like after 3rd import only it cause > this issue. > > not sure, if size of index cause any problem or any other issue. > > > > -- > 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 > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5007) smokeTestRelease.py should be able to pass cmdline test args to 'ant test', e.g. "-Dtests.jettyConnector=Socket"; also, "ant nightly-smoke" should be able to pass these
[
https://issues.apache.org/jira/browse/LUCENE-5007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved LUCENE-5007.
Resolution: Fixed
Lucene Fields: New,Patch Available (was: New)
Committed:
- trunk: r1484524
- branch_4x: r1484525
> smokeTestRelease.py should be able to pass cmdline test args to 'ant test',
> e.g. "-Dtests.jettyConnector=Socket"; also, "ant nightly-smoke" should be
> able to pass these args to smokeTestRelease.py
>
>
> Key: LUCENE-5007
> URL: https://issues.apache.org/jira/browse/LUCENE-5007
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/test
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 4.4
>
> Attachments: LUCENE-5007-branch_4x.patch,
> LUCENE-5007-branch_4x.patch, LUCENE-5007-trunk.patch
>
>
> SOLR-4189 added sensitivity to sysprop {{tests.jettyConnector}} to allow
> setting test mode Jetty to use Socket connector instead of the default
> SelectChannel connector.
> New module lucene/replicator is running into the same problem, failing 100%
> of the time when running under 'ant nightly-smoke' on ASF Jenkins on FreeBSD.
> At present there's no way from smokeTestRelease.py, or from "ant
> nightly-smoke", to pass through this sysprop (or any other).
> [~rcmuir] wrote on dev@l.o.a about one of the replicator module's failures on
> FreeBSD:
> {quote}
> This is a jenkins setup/test harness issue.
> there needs to be a way for the jetty connector sysprop to be passed
> all the way thru to ant test running from the smoketester.
> {quote}
--
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-trunk-Windows (64bit/jdk1.7.0_21) - Build # 2842 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2842/ Java: 64bit/jdk1.7.0_21 -XX:+UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.client.solrj.embedded.TestEmbeddedSolrServer.testGetCoreContainer Error Message: Stack Trace: org.apache.solr.common.SolrException: at __randomizedtesting.SeedInfo.seed([ED20914B7DE21255:2033A504CB137AEB]: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.(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 org.apache.solr.core.ConfigSolrXmlOld.initCoreLis
Re: ExternalDocValuesFilterReader progress?
I made a start on this, but in the end the client decided to do something different so it never got finished. I did get https://issues.apache.org/jira/browse/LUCENE-4902 out of it, which would allow you to plug in custom FilterReaders to Solr via the IndexReaderFactory. I'm still interested in working on it, just need a project that would use it, and some time... Alan Woodward www.flax.co.uk On 20 May 2013, at 16:29, Ryan McKinley wrote: > In march, there was so effort at looking at cleaner ways to integrate > external data: > > http://mail-archives.apache.org/mod_mbox/lucene-dev/201303.mbox/%3cc2e7cc37-52f2-4527-a919-a071d26f9...@flax.co.uk%3E > > Any updates on this? > > Thanks > Ryan > >
[jira] [Commented] (SOLR-4048) Add a "findRecursive" method to NamedList
[
https://issues.apache.org/jira/browse/SOLR-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662225#comment-13662225
]
Shawn Heisey commented on SOLR-4048:
On 4x, two solr-core tests failed with 500 server errors during shard
splitting. I've seen this over and over in Jenkins, so I'm pretty sure it's
not my changes. All solr-solrj tests pass fine, and precommit passes. The
branch_4x commit is r1484548.
> Add a "findRecursive" method to NamedList
> -
>
> Key: SOLR-4048
> URL: https://issues.apache.org/jira/browse/SOLR-4048
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 4.4
>
> Attachments: SOLR-4048-cleanup.patch, SOLR-4048.patch,
> SOLR-4048.patch, SOLR-4048.patch, SOLR-4048.patch, SOLR-4048.patch,
> SOLR-4048.patch, SOLR-4048.patch
>
>
> Most of the time when accessing data from a NamedList, what you'll be doing
> is using get() to retrieve another NamedList, and doing so over and over
> until you reach the final level, where you'll actually retrieve the value you
> want.
> I propose adding a method to NamedList which would do all that heavy lifting
> for you. I created the following method for my own code. It could be
> adapted fairly easily for inclusion into NamedList itself. The only reason I
> did not include it as a patch is because I figure you'll want to ensure it
> meets all your particular coding guidelines, and that the JavaDoc is much
> better than I have done here:
> {code}
> /**
>* Recursively parse a NamedList and return the value at the last level,
>* assuming that the object found at each level is also a NamedList. For
>* example, if "response" is the NamedList response from the Solr4 mbean
>* handler, the following code makes sense:
>*
>* String coreName = (String) getRecursiveFromResponse(response, new
>* String[] { "solr-mbeans", "CORE", "core", "stats", "coreName" });
>*
>*
>* @param namedList the NamedList to parse
>* @param args A list of values to recursively request
>* @return the object at the last level.
>* @throws SolrServerException
>*/
> @SuppressWarnings("unchecked")
> private final Object getRecursiveFromResponse(
> NamedList namedList, String[] args)
> throws SolrServerException
> {
> NamedList list = null;
> Object value = null;
> try
> {
> for (String key : args)
> {
> if (list == null)
> {
> list = namedList;
> }
> else
> {
> list = (NamedList) value;
> }
> value = list.get(key);
> }
> return value;
> }
> catch (Exception e)
> {
> throw new SolrServerException(
> "Failed to recursively parse
> NamedList", e);
> }
> }
> {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] [Resolved] (SOLR-4048) Add a "findRecursive" method to NamedList
[
https://issues.apache.org/jira/browse/SOLR-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey resolved SOLR-4048.
Resolution: Fixed
Fix Version/s: 5.0
> Add a "findRecursive" method to NamedList
> -
>
> Key: SOLR-4048
> URL: https://issues.apache.org/jira/browse/SOLR-4048
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 5.0, 4.4
>
> Attachments: SOLR-4048-cleanup.patch, SOLR-4048.patch,
> SOLR-4048.patch, SOLR-4048.patch, SOLR-4048.patch, SOLR-4048.patch,
> SOLR-4048.patch, SOLR-4048.patch
>
>
> Most of the time when accessing data from a NamedList, what you'll be doing
> is using get() to retrieve another NamedList, and doing so over and over
> until you reach the final level, where you'll actually retrieve the value you
> want.
> I propose adding a method to NamedList which would do all that heavy lifting
> for you. I created the following method for my own code. It could be
> adapted fairly easily for inclusion into NamedList itself. The only reason I
> did not include it as a patch is because I figure you'll want to ensure it
> meets all your particular coding guidelines, and that the JavaDoc is much
> better than I have done here:
> {code}
> /**
>* Recursively parse a NamedList and return the value at the last level,
>* assuming that the object found at each level is also a NamedList. For
>* example, if "response" is the NamedList response from the Solr4 mbean
>* handler, the following code makes sense:
>*
>* String coreName = (String) getRecursiveFromResponse(response, new
>* String[] { "solr-mbeans", "CORE", "core", "stats", "coreName" });
>*
>*
>* @param namedList the NamedList to parse
>* @param args A list of values to recursively request
>* @return the object at the last level.
>* @throws SolrServerException
>*/
> @SuppressWarnings("unchecked")
> private final Object getRecursiveFromResponse(
> NamedList namedList, String[] args)
> throws SolrServerException
> {
> NamedList list = null;
> Object value = null;
> try
> {
> for (String key : args)
> {
> if (list == null)
> {
> list = namedList;
> }
> else
> {
> list = (NamedList) value;
> }
> value = list.get(key);
> }
> return value;
> }
> catch (Exception e)
> {
> throw new SolrServerException(
> "Failed to recursively parse
> NamedList", e);
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4788) Multiple Entities DIH delta import: dataimporter.[entityName].last_index_time is empty
[
https://issues.apache.org/jira/browse/SOLR-4788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662253#comment-13662253
]
Shawn Heisey commented on SOLR-4788:
A review of all Solr issues that mention last_index_time turns up SOLR-4051
(via SOLR-1970) as a possible candidate for the commit that broke this
functionality. This assumes of course that it worked after the feature was
added by SOLR-783, which is probably a safe assumption.
SOLR-4051 says that it patches functionality that was introduced to 3.6. I
think that was added by SOLR-2382, so it might have been SOLR-2382 that broke
things.
If I get some time in the near future I will attempt to write a test that
illustrates the bug, and see if I can run that test on 3.6 as well. If anyone
out there can try a manual test on 3.6, that would save some time.
Side note: the code uses two constants for "last_index_time" - LAST_INDEX_TIME
and LAST_INDEX_KEY. Those should probably be combined.
> Multiple Entities DIH delta import: dataimporter.[entityName].last_index_time
> is empty
> --
>
> Key: SOLR-4788
> URL: https://issues.apache.org/jira/browse/SOLR-4788
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.2, 4.3
> Environment: solr-spec
> 4.2.1.2013.03.26.08.26.55
> solr-impl
> 4.2.1 1461071 - mark - 2013-03-26 08:26:55
> lucene-spec
> 4.2.1
> lucene-impl
> 4.2.1 1461071 - mark - 2013-03-26 08:23:34
> OR
> solr-spec
> 4.3.0
> solr-impl
> 4.3.0 1477023 - simonw - 2013-04-29 15:10:12
> lucene-spec
> 4.3.0
> lucene-impl
> 4.3.0 1477023 - simonw - 2013-04-29 14:55:14
>Reporter: chakming wong
>Assignee: Shalin Shekhar Mangar
>
> {code:title=conf/dataimport.properties|borderStyle=solid}entity1.last_index_time=2013-05-06
> 03\:02\:06
> last_index_time=2013-05-06 03\:05\:22
> entity2.last_index_time=2013-05-06 03\:03\:14
> entity3.last_index_time=2013-05-06 03\:05\:22
> {code}
> {code:title=conf/solrconfig.xml|borderStyle=solid} encoding="UTF-8" ?>
> ...
> class="org.apache.solr.handler.dataimport.DataImportHandler">
>
> dihconfig.xml
>
>
> ...
> {code}
> {code:title=conf/dihconfig.xml|borderStyle=solid} encoding="UTF-8" ?>
>
> type="JdbcDataSource" driver="com.mysql.jdbc.Driver"
> url="jdbc:mysql://*:*/*"
> user="*" password="*"/>
>
> query="SELECT * FROM table_a"
> deltaQuery="SELECT table_a_id FROM table_b WHERE
> last_modified > '${dataimporter.entity1.last_index_time}'"
> deltaImportQuery="SELECT * FROM table_a WHERE id =
> '${dataimporter.entity1.id}'"
> transformer="TemplateTransformer">
> ...
> ...
> ...
>
>
> ...
> ...
>
>
> ...
> ...
>
>
>
> {code}Â
> In above setup, *dataimporter.entity1.last_index_time* is *empty string* and
> cause the sql query having error
--
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-4834) Surround QParser should enable query text analysis
[
https://issues.apache.org/jira/browse/SOLR-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662263#comment-13662263
]
Paul Elschot commented on SOLR-4834:
>From the Lucene In Action book, 2nd edition:
{quote}
Unlike the standard QueryParser, the Surround parser doesn’t use an analyzer.
This means that the user will have to know precisely how terms are indexed. For
indexing texts to be queried by the Surround language, we recommend that you
use a
lowercasing analyzer that removes only the most frequently occurring
punctuations.
{quote}
Nevertheless, to use an analyzer for the queries, one can override some of the
protected methods of the Surround QueryParser to use the analyzer.
> 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
Re: svn commit: r1484015 - in /lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext: ./ jcl-over-slf4j-1.6.6.jar jul-to-slf4j-1.6.6.jar log4j-1.2.16.jar slf4j-api-1.6.6.jar slf4j-log4j12-1.6.6.jar
James, I'm assuming this was a mistake? Can you revert it? Thanks. Mike McCandless http://blog.mikemccandless.com On Sat, May 18, 2013 at 4:41 AM, Uwe Schindler wrote: > What happened here?: > - We don't use 4.2 branch anymore > - Please don't commit JAR files > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -Original Message- >> From: jd...@apache.org [mailto:jd...@apache.org] >> Sent: Saturday, May 18, 2013 12:13 AM >> To: comm...@lucene.apache.org >> Subject: svn commit: r1484015 - in >> /lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext: ./ jcl-over- >> slf4j-1.6.6.jar jul-to-slf4j-1.6.6.jar log4j-1.2.16.jar slf4j-api-1.6.6.jar >> slf4j- >> log4j12-1.6.6.jar >> >> Author: jdyer >> Date: Fri May 17 22:13:05 2013 >> New Revision: 1484015 >> >> URL: http://svn.apache.org/r1484015 >> Log: >> initial buy >> >> Added: >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/ >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/jcl-over- >> slf4j-1.6.6.jar (with props) >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/jul-to-slf4j- >> 1.6.6.jar (with props) >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/log4j- >> 1.2.16.jar (with props) >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/slf4j-api- >> 1.6.6.jar (with props) >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/slf4j-log4j12- >> 1.6.6.jar (with props) >> >> Added: lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/jcl- >> over-slf4j-1.6.6.jar >> URL: >> http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_2/solr/e >> xample/lib/ext/jcl-over-slf4j-1.6.6.jar?rev=1484015&view=auto >> == >> >> Binary file - no diff available. >> >> Added: lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/jul-to- >> slf4j-1.6.6.jar >> URL: >> http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_2/solr/e >> xample/lib/ext/jul-to-slf4j-1.6.6.jar?rev=1484015&view=auto >> == >> >> Binary file - no diff available. >> >> Added: lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/log4j- >> 1.2.16.jar >> URL: >> http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_2/solr/e >> xample/lib/ext/log4j-1.2.16.jar?rev=1484015&view=auto >> == >> >> Binary file - no diff available. >> >> Added: lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/slf4j- >> api-1.6.6.jar >> URL: >> http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_2/solr/e >> xample/lib/ext/slf4j-api-1.6.6.jar?rev=1484015&view=auto >> == >> >> Binary file - no diff available. >> >> Added: lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/slf4j- >> log4j12-1.6.6.jar >> URL: >> http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_2/solr/e >> xample/lib/ext/slf4j-log4j12-1.6.6.jar?rev=1484015&view=auto >> == >> >> Binary file - no diff available. > > > > - > 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-SmokeRelease-4.3 - Build # 4 - Failure
Steven, is your fix LUCENE-5007 related to that?
I am just mentioning this, because 4.3 is the release branch, so it should pass
smoke tester!
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> Sent: Monday, May 20, 2013 9:08 AM
> To: dev@lucene.apache.org
> Subject: [JENKINS] Lucene-Solr-SmokeRelease-4.3 - Build # 4 - Failure
>
> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-4.3/4/
>
> No tests ran.
>
> Build Log:
> [...truncated 32711 lines...]
> prepare-release-no-sign:
> [mkdir] Created dir: /usr/home/hudson/hudson-slave/workspace/Lucene-
> Solr-SmokeRelease-4.3/lucene/build/fakeRelease
> [copy] Copying 401 files to /usr/home/hudson/hudson-
> slave/workspace/Lucene-Solr-SmokeRelease-
> 4.3/lucene/build/fakeRelease/lucene
> [copy] Copying 194 files to /usr/home/hudson/hudson-
> slave/workspace/Lucene-Solr-SmokeRelease-
> 4.3/lucene/build/fakeRelease/solr
> [exec] JAVA6_HOME is /home/hudson/tools/java/latest1.6
> [exec] JAVA7_HOME is /home/hudson/tools/java/latest1.7
> [exec] NOTE: output encoding is US-ASCII
> [exec]
> [exec] Load release URL "file:/usr/home/hudson/hudson-
> slave/workspace/Lucene-Solr-SmokeRelease-4.3/lTraceback (most recent
> call last):
> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
> SmokeRelease-4.3/dev-tools/scriptucene/build/fakeRelease/"...
> [exec]
> [exec] Test Lucene...
> [exec] test basics...
> [exec] get KEYS
> [exec] 0.1 MB
> [exec]
> [exec] command "gpg --homedir /usr/home/hudson/hudson-
> slave/workspace/Lucene-Solr-SmokeRelease-
> 4.3/lucene/build/fakeReleaseTmp/lucene.gpg --import
> /usr/home/hudson/hudson-slave/ws/smokeTestRelease.py", line 1385, in
>
> [exec] main()
> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 1331, in
> main
> [exec] smokeTest(baseURL, version, tmpDir, isSigned)
> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 1364, in
> smokeTestorkspace/Lucene-Solr-SmokeRelease-
> 4.3/lucene/build/fakeReleaseTmp/lucene.KEYS" failed:
> [exec]
> [exec] checkSigs('lucene', lucenePath, version, tmpDir, isSigned)
> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 365, in
> checkSigs
> [exec] '%s/%s.gpg.import.log 2>&1' % (tmpDir, project))
> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 513, in run
> [exec] printFileContents(logFile)
> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 497, in
> printFileContents
> [exec] txt = codecs.open(fileName, 'r',
> encoding=sys.getdefaultencoding(), errors='replace').read()
> [exec] File "/usr/local/lib/python3.2/codecs.py", line 884, in open
> [exec] file = builtins.open(filename, mode, buffering)
> [exec] IOError: [Errno 2] No such file or directory:
> '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-
> 4.3/lucene/build/fakeReleaseTmp/lucene.gpg.import.log 2>&1'
>
> BUILD FAILED
> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-
> 4.3/build.xml:303: exec returned: 1
>
> Total time: 17 minutes 27 seconds
> Build step 'Invoke Ant' marked build as failure 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-SmokeRelease-4.3 - Build # 4 - Failure
Uwe,
No, I didn't commit LUCENE-5007 on the 4.3 branch.
I skimmed the errors and IIRC it looked like " 2>&1" is part of a file name
that Python can't find, which makes sense. Not sure why this is only a problem
on Jenkins, though. Maybe the newer version of Python you upgraded to changed
file handling somehow?
Steve
On May 20, 2013, at 4:03 PM, "Uwe Schindler" wrote:
> Steven, is your fix LUCENE-5007 related to that?
>
> I am just mentioning this, because 4.3 is the release branch, so it should
> pass smoke tester!
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -Original Message-
>> From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
>> Sent: Monday, May 20, 2013 9:08 AM
>> To: dev@lucene.apache.org
>> Subject: [JENKINS] Lucene-Solr-SmokeRelease-4.3 - Build # 4 - Failure
>>
>> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-4.3/4/
>>
>> No tests ran.
>>
>> Build Log:
>> [...truncated 32711 lines...]
>> prepare-release-no-sign:
>>[mkdir] Created dir: /usr/home/hudson/hudson-slave/workspace/Lucene-
>> Solr-SmokeRelease-4.3/lucene/build/fakeRelease
>> [copy] Copying 401 files to /usr/home/hudson/hudson-
>> slave/workspace/Lucene-Solr-SmokeRelease-
>> 4.3/lucene/build/fakeRelease/lucene
>> [copy] Copying 194 files to /usr/home/hudson/hudson-
>> slave/workspace/Lucene-Solr-SmokeRelease-
>> 4.3/lucene/build/fakeRelease/solr
>> [exec] JAVA6_HOME is /home/hudson/tools/java/latest1.6
>> [exec] JAVA7_HOME is /home/hudson/tools/java/latest1.7
>> [exec] NOTE: output encoding is US-ASCII
>> [exec]
>> [exec] Load release URL "file:/usr/home/hudson/hudson-
>> slave/workspace/Lucene-Solr-SmokeRelease-4.3/lTraceback (most recent
>> call last):
>> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
>> SmokeRelease-4.3/dev-tools/scriptucene/build/fakeRelease/"...
>> [exec]
>> [exec] Test Lucene...
>> [exec] test basics...
>> [exec] get KEYS
>> [exec] 0.1 MB
>> [exec]
>> [exec] command "gpg --homedir /usr/home/hudson/hudson-
>> slave/workspace/Lucene-Solr-SmokeRelease-
>> 4.3/lucene/build/fakeReleaseTmp/lucene.gpg --import
>> /usr/home/hudson/hudson-slave/ws/smokeTestRelease.py", line 1385, in
>>
>> [exec] main()
>> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
>> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 1331, in
>> main
>> [exec] smokeTest(baseURL, version, tmpDir, isSigned)
>> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
>> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 1364, in
>> smokeTestorkspace/Lucene-Solr-SmokeRelease-
>> 4.3/lucene/build/fakeReleaseTmp/lucene.KEYS" failed:
>> [exec]
>> [exec] checkSigs('lucene', lucenePath, version, tmpDir, isSigned)
>> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
>> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 365, in
>> checkSigs
>> [exec] '%s/%s.gpg.import.log 2>&1' % (tmpDir, project))
>> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
>> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 513, in run
>> [exec] printFileContents(logFile)
>> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
>> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 497, in
>> printFileContents
>> [exec] txt = codecs.open(fileName, 'r',
>> encoding=sys.getdefaultencoding(), errors='replace').read()
>> [exec] File "/usr/local/lib/python3.2/codecs.py", line 884, in open
>> [exec] file = builtins.open(filename, mode, buffering)
>> [exec] IOError: [Errno 2] No such file or directory:
>> '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-
>> 4.3/lucene/build/fakeReleaseTmp/lucene.gpg.import.log 2>&1'
>>
>> BUILD FAILED
>> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-
>> 4.3/build.xml:303: exec returned: 1
>>
>> Total time: 17 minutes 27 seconds
>> Build step 'Invoke Ant' marked build as failure 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-SmokeRelease-4.3 - Build # 4 - Failure
It is still Python 3.2 and 2.7. Maybe some changes in FreeBSD 9.x
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Steve Rowe [mailto:sar...@gmail.com]
> Sent: Monday, May 20, 2013 10:07 PM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS] Lucene-Solr-SmokeRelease-4.3 - Build # 4 - Failure
>
> Uwe,
>
> No, I didn't commit LUCENE-5007 on the 4.3 branch.
>
> I skimmed the errors and IIRC it looked like " 2>&1" is part of a file name
> that
> Python can't find, which makes sense. Not sure why this is only a problem on
> Jenkins, though. Maybe the newer version of Python you upgraded to
> changed file handling somehow?
>
> Steve
>
> On May 20, 2013, at 4:03 PM, "Uwe Schindler" wrote:
>
> > Steven, is your fix LUCENE-5007 related to that?
> >
> > I am just mentioning this, because 4.3 is the release branch, so it should
> pass smoke tester!
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >> -Original Message-
> >> From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> >> Sent: Monday, May 20, 2013 9:08 AM
> >> To: dev@lucene.apache.org
> >> Subject: [JENKINS] Lucene-Solr-SmokeRelease-4.3 - Build # 4 - Failure
> >>
> >> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-4.3/4/
> >>
> >> No tests ran.
> >>
> >> Build Log:
> >> [...truncated 32711 lines...]
> >> prepare-release-no-sign:
> >>[mkdir] Created dir:
> >> /usr/home/hudson/hudson-slave/workspace/Lucene-
> >> Solr-SmokeRelease-4.3/lucene/build/fakeRelease
> >> [copy] Copying 401 files to /usr/home/hudson/hudson-
> >> slave/workspace/Lucene-Solr-SmokeRelease-
> >> 4.3/lucene/build/fakeRelease/lucene
> >> [copy] Copying 194 files to /usr/home/hudson/hudson-
> >> slave/workspace/Lucene-Solr-SmokeRelease-
> >> 4.3/lucene/build/fakeRelease/solr
> >> [exec] JAVA6_HOME is /home/hudson/tools/java/latest1.6
> >> [exec] JAVA7_HOME is /home/hudson/tools/java/latest1.7
> >> [exec] NOTE: output encoding is US-ASCII
> >> [exec]
> >> [exec] Load release URL "file:/usr/home/hudson/hudson-
> >> slave/workspace/Lucene-Solr-SmokeRelease-4.3/lTraceback (most recent
> >> call last):
> >> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-
> Solr-
> >> SmokeRelease-4.3/dev-tools/scriptucene/build/fakeRelease/"...
> >> [exec]
> >> [exec] Test Lucene...
> >> [exec] test basics...
> >> [exec] get KEYS
> >> [exec] 0.1 MB
> >> [exec]
> >> [exec] command "gpg --homedir /usr/home/hudson/hudson-
> >> slave/workspace/Lucene-Solr-SmokeRelease-
> >> 4.3/lucene/build/fakeReleaseTmp/lucene.gpg --import
> >> /usr/home/hudson/hudson-slave/ws/smokeTestRelease.py", line 1385,
> in
> >>
> >> [exec] main()
> >> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-
> Solr-
> >> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 1331,
> >> in main
> >> [exec] smokeTest(baseURL, version, tmpDir, isSigned)
> >> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-
> Solr-
> >> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 1364,
> >> in
> >> smokeTestorkspace/Lucene-Solr-SmokeRelease-
> >> 4.3/lucene/build/fakeReleaseTmp/lucene.KEYS" failed:
> >> [exec]
> >> [exec] checkSigs('lucene', lucenePath, version, tmpDir, isSigned)
> >> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-
> Solr-
> >> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 365, in
> >> checkSigs
> >> [exec] '%s/%s.gpg.import.log 2>&1' % (tmpDir, project))
> >> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-
> Solr-
> >> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 513, in
> run
> >> [exec] printFileContents(logFile)
> >> [exec] File "/usr/home/hudson/hudson-slave/workspace/Lucene-
> Solr-
> >> SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py", line 497, in
> >> printFileContents
> >> [exec] txt = codecs.open(fileName, 'r',
> >> encoding=sys.getdefaultencoding(), errors='replace').read()
> >> [exec] File "/usr/local/lib/python3.2/codecs.py", line 884, in open
> >> [exec] file = builtins.open(filename, mode, buffering)
> >> [exec] IOError: [Errno 2] No such file or directory:
> >> '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
> SmokeRelease-
> >> 4.3/lucene/build/fakeReleaseTmp/lucene.gpg.import.log 2>&1'
> >>
> >> BUILD FAILED
> >> /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-
> SmokeRelease-
> >> 4.3/build.xml:303: exec returned: 1
> >>
> >> Total time: 17 minutes 27 seconds
> >> Build step 'Invoke Ant' marked build as failure Email was triggered
> >> for: Failure Sending email for trigger: Failure
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-m
RE: svn commit: r1484015 - in /lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext: ./ jcl-over-slf4j-1.6.6.jar jul-to-slf4j-1.6.6.jar log4j-1.2.16.jar slf4j-api-1.6.6.jar slf4j-log4j12-1.6.6.jar
My apologies. I will revert now. James Dyer Ingram Content Group (615) 213-4311 -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Monday, May 20, 2013 2:48 PM To: Lucene/Solr dev Subject: Re: svn commit: r1484015 - in /lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext: ./ jcl-over-slf4j-1.6.6.jar jul-to-slf4j-1.6.6.jar log4j-1.2.16.jar slf4j-api-1.6.6.jar slf4j-log4j12-1.6.6.jar James, I'm assuming this was a mistake? Can you revert it? Thanks. Mike McCandless http://blog.mikemccandless.com On Sat, May 18, 2013 at 4:41 AM, Uwe Schindler wrote: > What happened here?: > - We don't use 4.2 branch anymore > - Please don't commit JAR files > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -Original Message- >> From: jd...@apache.org [mailto:jd...@apache.org] >> Sent: Saturday, May 18, 2013 12:13 AM >> To: comm...@lucene.apache.org >> Subject: svn commit: r1484015 - in >> /lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext: ./ jcl-over- >> slf4j-1.6.6.jar jul-to-slf4j-1.6.6.jar log4j-1.2.16.jar slf4j-api-1.6.6.jar >> slf4j- >> log4j12-1.6.6.jar >> >> Author: jdyer >> Date: Fri May 17 22:13:05 2013 >> New Revision: 1484015 >> >> URL: http://svn.apache.org/r1484015 >> Log: >> initial buy >> >> Added: >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/ >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/jcl-over- >> slf4j-1.6.6.jar (with props) >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/jul-to-slf4j- >> 1.6.6.jar (with props) >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/log4j- >> 1.2.16.jar (with props) >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/slf4j-api- >> 1.6.6.jar (with props) >> lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/slf4j-log4j12- >> 1.6.6.jar (with props) >> >> Added: lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/jcl- >> over-slf4j-1.6.6.jar >> URL: >> http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_2/solr/e >> xample/lib/ext/jcl-over-slf4j-1.6.6.jar?rev=1484015&view=auto >> == >> >> Binary file - no diff available. >> >> Added: lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/jul-to- >> slf4j-1.6.6.jar >> URL: >> http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_2/solr/e >> xample/lib/ext/jul-to-slf4j-1.6.6.jar?rev=1484015&view=auto >> == >> >> Binary file - no diff available. >> >> Added: lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/log4j- >> 1.2.16.jar >> URL: >> http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_2/solr/e >> xample/lib/ext/log4j-1.2.16.jar?rev=1484015&view=auto >> == >> >> Binary file - no diff available. >> >> Added: lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/slf4j- >> api-1.6.6.jar >> URL: >> http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_2/solr/e >> xample/lib/ext/slf4j-api-1.6.6.jar?rev=1484015&view=auto >> == >> >> Binary file - no diff available. >> >> Added: lucene/dev/branches/lucene_solr_4_2/solr/example/lib/ext/slf4j- >> log4j12-1.6.6.jar >> URL: >> http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_2/solr/e >> xample/lib/ext/slf4j-log4j12-1.6.6.jar?rev=1484015&view=auto >> == >> >> Binary file - no diff available. > > > > - > 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
Solr core discovery wiki pages - rename from 4.3 to 4.4
For anyone who doesn't know already, core discovery is fundamentally broken in 4.3.0, and the problems won't be fixed in 4.3.1. The specific problem that a user found isn't a problem on branch_4x, but the code is quite a lot different. See discussion on SOLR-4773 starting on May 6th. I am planning to go through the wiki and rename all the pages for core discovery so they say 4.4, and modify the page content similarly as well. The pages include a note saying that the change was introduced in 4.3.0 but doesn't work right until 4.4. I will put redirects on the old pages after I rename them. It will be a bit of an undertaking to make sure all the changes happen somehwat seamlessly, so I will be waiting until I get home this evening before attempting it. I also wanted to get some feedback on this change before it happens. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
SOLR-3076 and IndexWriter.addDocuments()
My understanding of Lucene Block-Join indexing is that at some point IndexWriter.addDocuments() or IndexWriter.updateDocuments() need to be called to actually write a block of documents to disk. I'm trying to understand how SOLR-3076 (Solr should support block joins), works and haven't been able to trace out how or where it calls IndexWriter.addDocuments() or IndexWriter.updateDocuments. Can someone point me to the right place in the patch code? (If I should be asking this in the JIRA instead of the dev list please let me know) Tom
[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 After spending more time looking at everything that an upateRequest can do I realized that not all parts of a request are routable. The latest patch handles this by first sending all the routable updates to the correct shard. Then executing a final update request with non-routable update commands such OPTIMIZE or deleteByQuery. This latest patch has not been tested so is for review purposes only. > 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.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-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-tabpanel&focusedCommentId=13662389#comment-13662389 ] Joel Bernstein edited comment on SOLR-4816 at 5/20/13 10:00 PM: After spending more time looking at everything that an upateRequest can do I realized that not all parts of a request are routable. The latest patch handles this by first sending all the routable updates to the correct shard. Then executing a final update request with non-routable update commands such as OPTIMIZE or deleteByQuery. This latest patch has not been tested so is for review purposes only. was (Author: joel.bernstein): After spending more time looking at everything that an upateRequest can do I realized that not all parts of a request are routable. The latest patch handles this by first sending all the routable updates to the correct shard. Then executing a final update request with non-routable update commands such OPTIMIZE or deleteByQuery. This latest patch has not been tested so is for review purposes only. > 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.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] [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 > 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.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] [Commented] (SOLR-3385) Extended Dismax parser ignores all regular search terms when one search term is using + (dismax behaves differently)
[ https://issues.apache.org/jira/browse/SOLR-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662402#comment-13662402 ] Naomi Dushay commented on SOLR-3385: I believe this is the same as SOLR-2649: // For correct lucene queries, turn off mm processing if there // were explicit operators (except for AND). boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; (lines 232-234 taken from tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java) > Extended Dismax parser ignores all regular search terms when one search term > is using + (dismax behaves differently) > > > Key: SOLR-3385 > URL: https://issues.apache.org/jira/browse/SOLR-3385 > Project: Solr > Issue Type: Bug > Components: query parsers >Affects Versions: 3.5 >Reporter: Nils Kaiser > Attachments: select_dev_PLUSsales_dismax_553results.xml, > select_dev_PLUSsales_edismax_9600results.xml, > select_dev_PLUSsales_miau_dismax_0results.xml, > select_dev_PLUSsales_miau_edismax_9600results.xml, > select_dev_sales_miau_edismax_0results.xml, > select_PLUSsales_dismax_9600results.xml, > select_PLUSsales_edismax_9600results.xml > > > When using the extended dismax parser with at least one term using + or -, > all other search terms are ignored. > Example: > (the terms dev and sales are found in the index, the term miau is not part of > the index) > "dev sales miau", "+dev +sales +miau", "dev +sales +miau" all give me 0 > results (as expected) > "dev +sales miau", "dev +sales" or "+sales" return the same number of results > (dev and miau terms are ignored) > The standard dismax parser always treats search terms as +, so "dev sales > miau", "+dev +sales miau", "dev +sales miau" return the same number of > results. -- 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: SOLR-3076 and IndexWriter.addDocuments()
Found it. In AddBlockUpdateTest.testSmallBlockDirect assertEquals(2, h.getCore().getUpdateHandler().addBlock(cmd)); and in the patched code DirectUpdateHandler2.addBlock() Tom On Mon, May 20, 2013 at 5:49 PM, Tom Burton-West wrote: > My understanding of Lucene Block-Join indexing is that at some point > IndexWriter.addDocuments() or IndexWriter.updateDocuments() need to be > called to actually write a block of documents to disk. > >I'm trying to understand how SOLR-3076 (Solr should support block > joins), works and haven't been able to trace out how or where it calls > IndexWriter.addDocuments() or IndexWriter.updateDocuments. > > Can someone point me to the right place in the patch code? > > (If I should be asking this in the JIRA instead of the dev list please let > me know) > > Tom >
[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators
[ https://issues.apache.org/jira/browse/SOLR-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662455#comment-13662455 ] Naomi Dushay commented on SOLR-2649: Our dismax mm setting is 6<-1 6<90%. I would like our mm to be honored for the top-level SHOULD clauses. Oh please, oh please? EDISMAX q=customer driven academic library: +(((custom)~0.01 (driven)~0.01 (academ)~0.01 (librari)~0.01)~4) 4 hits customer NOT driven academic library: +((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01) 984300 hits <= INSANE customer -driven academic library: +((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01) 984300 hits <= INSANE customer OR academic OR library NOT driven: +((custom)~0.01 (academ)~0.01 (librari)~0.01 -(driven)~0.01) 984300 hits customer academic library: +(((custom)~0.01 (academ)~0.01 (librari)~0.01)~3) 100 hits DISMAX (plausible results!): customer driven academic library: +(((custom)~0.01 (driven)~0.01 (academ)~0.01 (librari)~0.01)~4) ()4 hits customer NOT driven academic library: +(((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01)~3) () 96 hits customer -driven academic library: +(((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01)~3) () 96 hits customer academic library: +(((custom)~0.01 (academ)~0.01 (librari)~0.01)~3)() 100 hits > MM ignored in edismax queries with operators > > > Key: SOLR-2649 > URL: https://issues.apache.org/jira/browse/SOLR-2649 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Magnus Bergmark >Priority: Minor > Fix For: 4.4 > > > Hypothetical scenario: > 1. User searches for "stocks oil gold" with MM set to "50%" > 2. User adds "-stockings" to the query: "stocks oil gold -stockings" > 3. User gets no hits since MM was ignored and all terms where AND-ed > together > The behavior seems to be intentional, although the reason why is never > explained: > // For correct lucene queries, turn off mm processing if there > // were explicit operators (except for AND). > boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; > (lines 232-234 taken from > tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java) > This makes edismax unsuitable as an replacement to dismax; mm is one of the > primary features of dismax. -- 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: have developer question about ClobTransformer and DIH
: I think you're confusing the hierarchy of your database's types with the : hierarchy in Java. In Java, a java.sql.Blob and a java.sql.Clob are 2 : different things. They do not extend a common ancestor (excpt Exactly - regardless of what the informix docs may say about how column types are related (for the purposes of casting an conversion in SQL) what matters is how the JDBC driver you are using maps your databases types to java types, some quick googling pulls up this result... http://docs.oracle.com/cd/E17904_01/web./e13753/informix.htm#i1065747 Which lists specifically.. Informix BLOB -> JDBC BLOB Informix CLOB -> JDBC CLOB Informix TEXT -> JDBC LONGVARCHAR ...i suspect that there is not any real problem with the ClobTransformer -- it seems to be working perfectly, dealing with the CLOB fields returned appropriately -- but there may in fact be a problem with if/how DIH deals with JDBC values that are LONGVARCHARs. Since i don't see Types.LONGVARCHAR mentioned anywhere in the DIH code base, i suspect it's falling back to some default behavior assuming String data which doesn't account for the way LONGVARCHAR data is probably returned as an Object that needs to be streamed similar to a Clob. specifically, some quick googling for LONGVARCHAR in the JDBC APIs suggests that ResultSet.getUnicodeStream or ResultSet.getCharacterStream should be used for LONGVARCHAR columns -- but i don't see any usage of that method in the DIH code base. geeky2: would you mind opening a bug to fix support for LONGVARCHAR in JdbcDataSource? -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-2649) MM ignored in edismax queries with operators
[ https://issues.apache.org/jira/browse/SOLR-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662455#comment-13662455 ] Naomi Dushay edited comment on SOLR-2649 at 5/20/13 11:41 PM: -- Our dismax mm setting is 6<-1 6<90%. I would like our mm to be honored for the top-level SHOULD clauses. Oh please, oh please? EDISMAX q=customer driven academic library: +(((custom)~0.01 (driven)~0.01 (academ)~0.01 (librari)~0.01)~4) 4 hits customer NOT driven academic library: +((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01) 984300 hits <= INSANE customer -driven academic library: +((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01) 984300 hits <= INSANE customer OR academic OR library NOT driven: +((custom)~0.01 (academ)~0.01 (librari)~0.01 -(driven)~0.01) 984300 hits customer academic library: +(((custom)~0.01 (academ)~0.01 (librari)~0.01)~3) 100 hits DISMAX (plausible results!): customer driven academic library: +(((custom)~0.01 (driven)~0.01 (academ)~0.01 (librari)~0.01)~4) () 4 hits customer NOT driven academic library: +(((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01)~3) () 96 hits customer -driven academic library: +(((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01)~3) () 96 hits customer academic library: +(((custom)~0.01 (academ)~0.01 (librari)~0.01)~3)() 100 hits was (Author: ndushay): Our dismax mm setting is 6<-1 6<90%. I would like our mm to be honored for the top-level SHOULD clauses. Oh please, oh please? EDISMAX q=customer driven academic library: +(((custom)~0.01 (driven)~0.01 (academ)~0.01 (librari)~0.01)~4) 4 hits customer NOT driven academic library: +((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01) 984300 hits <= INSANE customer -driven academic library: +((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01) 984300 hits <= INSANE customer OR academic OR library NOT driven: +((custom)~0.01 (academ)~0.01 (librari)~0.01 -(driven)~0.01) 984300 hits customer academic library: +(((custom)~0.01 (academ)~0.01 (librari)~0.01)~3) 100 hits DISMAX (plausible results!): customer driven academic library: +(((custom)~0.01 (driven)~0.01 (academ)~0.01 (librari)~0.01)~4) ()4 hits customer NOT driven academic library: +(((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01)~3) () 96 hits customer -driven academic library: +(((custom)~0.01 -(driven)~0.01 (academ)~0.01 (librari)~0.01)~3) () 96 hits customer academic library: +(((custom)~0.01 (academ)~0.01 (librari)~0.01)~3)() 100 hits > MM ignored in edismax queries with operators > > > Key: SOLR-2649 > URL: https://issues.apache.org/jira/browse/SOLR-2649 > Project: Solr > Issue Type: Bug > Components: query parsers >Reporter: Magnus Bergmark >Priority: Minor > Fix For: 4.4 > > > Hypothetical scenario: > 1. User searches for "stocks oil gold" with MM set to "50%" > 2. User adds "-stockings" to the query: "stocks oil gold -stockings" > 3. User gets no hits since MM was ignored and all terms where AND-ed > together > The behavior seems to be intentional, although the reason why is never > explained: > // For correct lucene queries, turn off mm processing if there > // were explicit operators (except for AND). > boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; > (lines 232-234 taken from > tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java) > This makes edismax unsuitable as an replacement to dismax; mm is one of the > primary features of dismax. -- 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: Solr core discovery wiki pages - rename from 4.3 to 4.4
Go for it, it's probably best to discourage people from trying this out at this point... Erick On Mon, May 20, 2013 at 4:35 PM, Shawn Heisey wrote: > For anyone who doesn't know already, core discovery is fundamentally broken > in 4.3.0, and the problems won't be fixed in 4.3.1. The specific problem > that a user found isn't a problem on branch_4x, but the code is quite a lot > different. > > See discussion on SOLR-4773 starting on May 6th. > > I am planning to go through the wiki and rename all the pages for core > discovery so they say 4.4, and modify the page content similarly as well. > The pages include a note saying that the change was introduced in 4.3.0 but > doesn't work right until 4.4. I will put redirects on the old pages after I > rename them. > > It will be a bit of an undertaking to make sure all the changes happen > somehwat seamlessly, so I will be waiting until I get home this evening > before attempting it. > > I also wanted to get some feedback on this change before it happens. > > Thanks, > Shawn > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4842) Field faceting with local params affects successive field faceting parameters
Erik Hatcher created SOLR-4842:
--
Summary: Field faceting with local params affects successive field
faceting parameters
Key: SOLR-4842
URL: https://issues.apache.org/jira/browse/SOLR-4842
Project: Solr
Issue Type: Bug
Components: search, SearchComponents - other
Affects Versions: 4.3
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Critical
SOLR-4717 introduced local param support for per-field faceting, allowing the
same field to be faceted in various ways. There's a problem such that one
fields local param setting will override the defaults of the next field. For
example: facet.field={!key=foo facet.mincount=1
facet.missing=false}field&facet.field={!key=bar facet.missing=true}field causes
the "bar" faceting to use facet.mincount=1 when it should use the default of 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4842) Field faceting with local params affects successive field faceting parameters
[
https://issues.apache.org/jira/browse/SOLR-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-4842:
---
Attachment: SOLR-4842.patch
Here's a patch demonstrating a failing test case that should pass,
demonstrating the corruption of one facet.field's local params into another
facet.field.
> Field faceting with local params affects successive field faceting parameters
> -
>
> Key: SOLR-4842
> URL: https://issues.apache.org/jira/browse/SOLR-4842
> Project: Solr
> Issue Type: Bug
> Components: search, SearchComponents - other
>Affects Versions: 4.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Critical
> Attachments: SOLR-4842.patch
>
>
> SOLR-4717 introduced local param support for per-field faceting, allowing the
> same field to be faceted in various ways. There's a problem such that one
> fields local param setting will override the defaults of the next field. For
> example: facet.field={!key=foo facet.mincount=1
> facet.missing=false}field&facet.field={!key=bar facet.missing=true}field
> causes the "bar" faceting to use facet.mincount=1 when it should use the
> default of 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4842) Field faceting with local params affects successive field faceting parameters
[
https://issues.apache.org/jira/browse/SOLR-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-4842:
---
Fix Version/s: 4.3.1
> Field faceting with local params affects successive field faceting parameters
> -
>
> Key: SOLR-4842
> URL: https://issues.apache.org/jira/browse/SOLR-4842
> Project: Solr
> Issue Type: Bug
> Components: search, SearchComponents - other
>Affects Versions: 4.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Critical
> Fix For: 4.3.1
>
> Attachments: SOLR-4842.patch
>
>
> SOLR-4717 introduced local param support for per-field faceting, allowing the
> same field to be faceted in various ways. There's a problem such that one
> fields local param setting will override the defaults of the next field. For
> example: facet.field={!key=foo facet.mincount=1
> facet.missing=false}field&facet.field={!key=bar facet.missing=true}field
> causes the "bar" faceting to use facet.mincount=1 when it should use the
> default of 0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4842) Field faceting with local params affects successive field faceting parameters
[
https://issues.apache.org/jira/browse/SOLR-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-4842:
---
Fix Version/s: (was: 4.3.1)
Description: SOLR-4717 introduced local param support for per-field
faceting, allowing the same field to be faceted in various ways. There's a
problem such that one fields local param setting will override the defaults of
the next field. For example: {code}facet.field={!key=foo facet.mincount=1
facet.missing=false}field&facet.field={!key=bar facet.missing=true}field{code}
causes the "bar" faceting to use facet.mincount=1 when it should use the
default of 0. (was: SOLR-4717 introduced local param support for per-field
faceting, allowing the same field to be faceted in various ways. There's a
problem such that one fields local param setting will override the defaults of
the next field. For example: facet.field={!key=foo facet.mincount=1
facet.missing=false}field&facet.field={!key=bar facet.missing=true}field causes
the "bar" faceting to use facet.mincount=1 when it should use the default of 0.)
> Field faceting with local params affects successive field faceting parameters
> -
>
> Key: SOLR-4842
> URL: https://issues.apache.org/jira/browse/SOLR-4842
> Project: Solr
> Issue Type: Bug
> Components: search, SearchComponents - other
>Affects Versions: 4.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Critical
> Attachments: SOLR-4842.patch
>
>
> SOLR-4717 introduced local param support for per-field faceting, allowing the
> same field to be faceted in various ways. There's a problem such that one
> fields local param setting will override the defaults of the next field. For
> example: {code}facet.field={!key=foo facet.mincount=1
> facet.missing=false}field&facet.field={!key=bar
> facet.missing=true}field{code} causes the "bar" faceting to use
> facet.mincount=1 when it should use the default of 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-4842) Field faceting with local params affects successive field faceting parameters
[
https://issues.apache.org/jira/browse/SOLR-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662580#comment-13662580
]
Erik Hatcher commented on SOLR-4842:
I'm not sure my patch actually shows the problem clearly yet. facet.mincount
and deprecated facet.zeros support still in there confuse things a bit. I'm
still working through a test case showing the issue clearly.
> Field faceting with local params affects successive field faceting parameters
> -
>
> Key: SOLR-4842
> URL: https://issues.apache.org/jira/browse/SOLR-4842
> Project: Solr
> Issue Type: Bug
> Components: search, SearchComponents - other
>Affects Versions: 4.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Critical
> Attachments: SOLR-4842.patch
>
>
> SOLR-4717 introduced local param support for per-field faceting, allowing the
> same field to be faceted in various ways. There's a problem such that one
> fields local param setting will override the defaults of the next field. For
> example: {code}facet.field={!key=foo facet.mincount=1
> facet.missing=false}field&facet.field={!key=bar
> facet.missing=true}field{code} causes the "bar" faceting to use
> facet.mincount=1 when it should use the default of 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
Re: ExternalDocValuesFilterReader progress?
thanks thats a great start... ah solo much to do! On Mon, May 20, 2013 at 10:37 AM, Alan Woodward wrote: > I made a start on this, but in the end the client decided to do something > different so it never got finished. I did get > https://issues.apache.org/jira/browse/LUCENE-4902 out of it, which would > allow you to plug in custom FilterReaders to Solr via the > IndexReaderFactory. I'm still interested in working on it, just need a > project that would use it, and some time... > > Alan Woodward > www.flax.co.uk > > > On 20 May 2013, at 16:29, Ryan McKinley wrote: > > In march, there was so effort at looking at cleaner ways to integrate > external data: > > > http://mail-archives.apache.org/mod_mbox/lucene-dev/201303.mbox/%3cc2e7cc37-52f2-4527-a919-a071d26f9...@flax.co.uk%3E > > Any updates on this? > > Thanks > Ryan > > > >
[jira] [Updated] (SOLR-4842) Field faceting with local params affects successive field faceting parameters
[
https://issues.apache.org/jira/browse/SOLR-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-4842:
---
Attachment: SOLR-4842__hoss_tests.patch
Erik: based on your followup comment, i ignored your patch and attempted to
write a test to reproduce the general problem you described and could not do so
-- see attached SOLR-4842__hoss_tests.patch.
if there is a bug, i suspect it must be something subtle in the way the
defaults of a particular param are defined. if you're having trouble writing a
test aptch to demonstrate the problme you are seeing, can you at least describe
a specific example query where you observe a problem? even if you can't share
the docs needed to seee the problem, knowing exactly what params may help
narrow things down.
> Field faceting with local params affects successive field faceting parameters
> -
>
> Key: SOLR-4842
> URL: https://issues.apache.org/jira/browse/SOLR-4842
> Project: Solr
> Issue Type: Bug
> Components: search, SearchComponents - other
>Affects Versions: 4.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Critical
> Attachments: SOLR-4842__hoss_tests.patch, SOLR-4842.patch
>
>
> SOLR-4717 introduced local param support for per-field faceting, allowing the
> same field to be faceted in various ways. There's a problem such that one
> fields local param setting will override the defaults of the next field. For
> example: {code}facet.field={!key=foo facet.mincount=1
> facet.missing=false}field&facet.field={!key=bar
> facet.missing=true}field{code} causes the "bar" faceting to use
> facet.mincount=1 when it should use the default of 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-4842) Field faceting with local params affects successive field faceting parameters
[
https://issues.apache.org/jira/browse/SOLR-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662646#comment-13662646
]
Hoss Man commented on SOLR-4842:
Erik: ok, now looking at your test, i think it's just flawed.
Ignore for a minute the issue of faceting multiple ways, ignore the "foo" key
in the assertQ your patch modifies, ignore everything about it, delete it from
the test, and just consider a query using only the "bar" key like so...
{noformat}
assertQ("ignore foo, look at bar",
req("q", "id:[42 TO 47]"
,"facet", "true"
,"facet.zeros", "false"
,"fq", "id:[42 TO 45]"
,"facet.field", "{!key=bar " +
"facet.missing=true "+
"}"+fname
)
,"*[count(//doc)=4]"
,"*[count(//lst[@name='bar']/int)=5]"
,"//lst[@name='bar']/int[not(@name)][.='1']"
);
{noformat}
That test is still going to fail because facet.zeros=false but you are
asserting that there should be 5 terms for "bar". the only way there could be
5 terms is if you include the terms with a zero.
I don't think the docs have never really specified what happens if you mix and
match "facet.mincount" with the deprecated "facet.zeros" (ie:
"facet.mincount=1&facet.zeros=true&facet.field=XXX"), let alone in the case of
per-field overrides (ie:
"facet.mincount=1&f.XXX.facet.zeros=true&facet.field=XXX") -- i think it's fair
game to say all bets are off in the new situation of localparams. but in this
specific case, there's no way it makes sense to think that the "bar" key should
have a mincount of "0".
> Field faceting with local params affects successive field faceting parameters
> -
>
> Key: SOLR-4842
> URL: https://issues.apache.org/jira/browse/SOLR-4842
> Project: Solr
> Issue Type: Bug
> Components: search, SearchComponents - other
>Affects Versions: 4.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Critical
> Attachments: SOLR-4842__hoss_tests.patch, SOLR-4842.patch
>
>
> SOLR-4717 introduced local param support for per-field faceting, allowing the
> same field to be faceted in various ways. There's a problem such that one
> fields local param setting will override the defaults of the next field. For
> example: {code}facet.field={!key=foo facet.mincount=1
> facet.missing=false}field&facet.field={!key=bar
> facet.missing=true}field{code} causes the "bar" faceting to use
> facet.mincount=1 when it should use the default of 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
[JENKINS] Lucene-Solr-SmokeRelease-4.3 - Build # 5 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-4.3/5/
No tests ran.
Build Log:
[...truncated 32711 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeRelease
[copy] Copying 401 files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeRelease/lucene
[copy] Copying 194 files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeRelease/solr
[exec] JAVA6_HOME is /home/hudson/tools/java/latest1.6
[exec] JAVA7_HOME is /home/hudson/tools/java/latest1.7
[exec] NOTE: output encoding is US-ASCII
[exec]
[exec] Load release URL
"file:/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeRelease/"...
[exec]
[exec] Test Lucene...
[exec] test basics...
[exec] get KEYS
[exec] 0.1 MB
[exec]
[exec] command "gpg --homedir
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeReleaseTmp/lucene.gpg
--import /usr/home/hudson/hudson-slave/wTraceback (most recent call last):
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/script
[exec]
orkspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeReleaseTmp/lucene.KEYS"
failed:
[exec] s/smokeTestRelease.py", line 1385, in
[exec] main()
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py",
line 1331, in main
[exec] smokeTest(baseURL, version, tmpDir, isSigned)
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py",
line 1364, in smokeTest
[exec] checkSigs('lucene', lucenePath, version, tmpDir, isSigned)
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py",
line 365, in checkSigs
[exec] '%s/%s.gpg.import.log 2>&1' % (tmpDir, project))
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py",
line 513, in run
[exec] printFileContents(logFile)
[exec] File
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/dev-tools/scripts/smokeTestRelease.py",
line 497, in printFileContents
[exec] txt = codecs.open(fileName, 'r',
encoding=sys.getdefaultencoding(), errors='replace').read()
[exec] File "/usr/local/lib/python3.2/codecs.py", line 884, in open
[exec] file = builtins.open(filename, mode, buffering)
[exec] IOError: [Errno 2] No such file or directory:
'/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/lucene/build/fakeReleaseTmp/lucene.gpg.import.log
2>&1'
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.3/build.xml:303:
exec returned: 1
Total time: 17 minutes 23 seconds
Build step 'Invoke Ant' marked build as failure
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
