[JENKINS] Solr-Artifacts-trunk - Build # 2072 - Failure
Build: https://builds.apache.org/job/Solr-Artifacts-trunk/2072/ No tests ran. Build Log: [...truncated 8220 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/solr/common-build.xml:362: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 15 minutes 21 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Publishing Javadoc 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-4255) Solr 4 spatial- Add a filter=false local-param to just use the distance based valuesource
[ https://issues.apache.org/jira/browse/SOLR-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545333#comment-13545333 ] Commit Tag Bot commented on SOLR-4255: -- [branch_4x commit] David Wayne Smiley http://svn.apache.org/viewvc?view=revision&revision=1429472 SOLR-4255: add spatial filter=false local-param option > Solr 4 spatial- Add a filter=false local-param to just use the distance based > valuesource > - > > Key: SOLR-4255 > URL: https://issues.apache.org/jira/browse/SOLR-4255 > Project: Solr > Issue Type: New Feature >Reporter: David Smiley >Assignee: David Smiley > Fix For: 4.1, 5.0 > > Attachments: SOLR-4255_spatial_filter_=_false.patch > > > The Solr 4 spatial fields use AbstractSpatialFieldType and by default only > filter and supply 1 as the constant score. For sorting or boosting, you can > add the local-param score="distance" (or recipDistance) option to have the > score of the query be as specified. However this query still filters, and in > some cases this is redundant. For example you probably already have a filter > query doing the filter portion, and then you are again using the shape > reference here for a boost query. > The change is a simple matter of returning the FunctionQuery and not wrapping > it in FilteredQuery. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-java7 - Build # 3615 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-java7/3615/ All tests passed Build Log: [...truncated 8258 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/build.xml:353: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/build.xml:39: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/build.xml:178: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/common-build.xml:428: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/common-build.xml:378: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/common-build.xml:329: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/common-build.xml:349: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 31 minutes 52 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4255) Solr 4 spatial- Add a filter=false local-param to just use the distance based valuesource
[ https://issues.apache.org/jira/browse/SOLR-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-4255. Resolution: Fixed Fix Version/s: 5.0 > Solr 4 spatial- Add a filter=false local-param to just use the distance based > valuesource > - > > Key: SOLR-4255 > URL: https://issues.apache.org/jira/browse/SOLR-4255 > Project: Solr > Issue Type: New Feature >Reporter: David Smiley >Assignee: David Smiley > Fix For: 4.1, 5.0 > > Attachments: SOLR-4255_spatial_filter_=_false.patch > > > The Solr 4 spatial fields use AbstractSpatialFieldType and by default only > filter and supply 1 as the constant score. For sorting or boosting, you can > add the local-param score="distance" (or recipDistance) option to have the > score of the query be as specified. However this query still filters, and in > some cases this is redundant. For example you probably already have a filter > query doing the filter portion, and then you are again using the shape > reference here for a boost query. > The change is a simple matter of returning the FunctionQuery and not wrapping > it in FilteredQuery. -- 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-4255) Solr 4 spatial- Add a filter=false local-param to just use the distance based valuesource
[ https://issues.apache.org/jira/browse/SOLR-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545327#comment-13545327 ] Commit Tag Bot commented on SOLR-4255: -- [trunk commit] David Wayne Smiley http://svn.apache.org/viewvc?view=revision&revision=1429468 SOLR-4255: (CHANGES.txt) add spatial filter=false local-param option > Solr 4 spatial- Add a filter=false local-param to just use the distance based > valuesource > - > > Key: SOLR-4255 > URL: https://issues.apache.org/jira/browse/SOLR-4255 > Project: Solr > Issue Type: New Feature >Reporter: David Smiley >Assignee: David Smiley > Fix For: 4.1 > > Attachments: SOLR-4255_spatial_filter_=_false.patch > > > The Solr 4 spatial fields use AbstractSpatialFieldType and by default only > filter and supply 1 as the constant score. For sorting or boosting, you can > add the local-param score="distance" (or recipDistance) option to have the > score of the query be as specified. However this query still filters, and in > some cases this is redundant. For example you probably already have a filter > query doing the filter portion, and then you are again using the shape > reference here for a boost query. > The change is a simple matter of returning the FunctionQuery and not wrapping > it in FilteredQuery. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-java7 - Build # 865 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/865/ All tests passed Build Log: [...truncated 8098 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:353: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:39: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/build.xml:178: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/common-build.xml:428: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/common-build.xml:378: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/common-build.xml:329: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/common-build.xml:349: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 34 minutes 14 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4255) Solr 4 spatial- Add a filter=false local-param to just use the distance based valuesource
[ https://issues.apache.org/jira/browse/SOLR-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545323#comment-13545323 ] Commit Tag Bot commented on SOLR-4255: -- [trunk commit] David Wayne Smiley http://svn.apache.org/viewvc?view=revision&revision=1429466 SOLR-4255: add spatial filter=false local-param option > Solr 4 spatial- Add a filter=false local-param to just use the distance based > valuesource > - > > Key: SOLR-4255 > URL: https://issues.apache.org/jira/browse/SOLR-4255 > Project: Solr > Issue Type: New Feature >Reporter: David Smiley >Assignee: David Smiley > Fix For: 4.1 > > Attachments: SOLR-4255_spatial_filter_=_false.patch > > > The Solr 4 spatial fields use AbstractSpatialFieldType and by default only > filter and supply 1 as the constant score. For sorting or boosting, you can > add the local-param score="distance" (or recipDistance) option to have the > score of the query be as specified. However this query still filters, and in > some cases this is redundant. For example you probably already have a filter > query doing the filter portion, and then you are again using the shape > reference here for a boost query. > The change is a simple matter of returning the FunctionQuery and not wrapping > it in FilteredQuery. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java6 - Build # 15784 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java6/15784/ All tests passed Build Log: [...truncated 7625 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/build.xml:353: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/build.xml:39: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/build.xml:178: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:428: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:378: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:329: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:349: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 40 minutes 7 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1200 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1200/ All tests passed Build Log: [...truncated 7480 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:353: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:39: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/build.xml:178: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:428: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:378: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:329: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:349: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 35 minutes 17 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 141 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/141/ All tests passed Build Log: [...truncated 7736 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/build.xml:373: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/build.xml:353: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/build.xml:39: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build.xml:178: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/common-build.xml:428: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/common-build.xml:378: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/common-build.xml:329: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/common-build.xml:349: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 68 minutes 54 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-trunk - Build # 47 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/47/ No tests ran. Build Log: [...truncated 19899 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/build.xml:273: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/solr/common-build.xml:362: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 24 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
[JENKINS] Lucene-Solr-Tests-trunk-java7 - Build # 3614 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-java7/3614/ All tests passed Build Log: [...truncated 8353 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/build.xml:353: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/build.xml:39: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/build.xml:178: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/common-build.xml:428: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/common-build.xml:378: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/common-build.xml:329: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/common-build.xml:349: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 37 minutes 54 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java6 - Build # 15783 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java6/15783/ All tests passed Build Log: [...truncated 7716 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/build.xml:353: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/build.xml:39: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/build.xml:178: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:428: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:378: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:329: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:349: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java6/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 34 minutes 47 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-java7 - Build # 864 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/864/ All tests passed Build Log: [...truncated 8116 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:353: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:39: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/build.xml:178: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/common-build.xml:428: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/common-build.xml:378: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/common-build.xml:329: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/common-build.xml:349: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 33 minutes 15 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1199 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1199/ All tests passed Build Log: [...truncated 7593 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:353: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:39: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/build.xml:178: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:428: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:378: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:329: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:349: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/common-build.xml:387: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/solr/example/build.xml:57: impossible to resolve dependencies: resolve failed - see output for details Total time: 43 minutes 59 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4271) add postingshighlighter
[ https://issues.apache.org/jira/browse/SOLR-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545233#comment-13545233 ] Commit Tag Bot commented on SOLR-4271: -- [branch_4x commit] Robert Muir http://svn.apache.org/viewvc?view=revision&revision=1429422 SOLR-4271: add support for PostingsHighlighter > add postingshighlighter > --- > > Key: SOLR-4271 > URL: https://issues.apache.org/jira/browse/SOLR-4271 > Project: Solr > Issue Type: New Feature > Components: highlighter >Reporter: Robert Muir >Assignee: Robert Muir > Fix For: 4.1, 5.0 > > Attachments: SOLR-4271.patch > > > add solr integration for postingshighlighter, and move it out of the sandbox. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #203: POMs out of sync
The whole jetty folder disappeared in maven/ivy. No release anymore visible. Maybe a temporary problem. Uwe Apache Jenkins Server schrieb: >Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/203/ > >No tests ran. > >Build Log: >[...truncated 3801 lines...] > > > > > > > >- >To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >For additional commands, e-mail: dev-h...@lucene.apache.org -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de
[JENKINS-MAVEN] Lucene-Solr-Maven-4.x #203: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/203/ No tests ran. Build Log: [...truncated 3801 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #728: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/728/ No tests ran. Build Log: [...truncated 3902 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
[ https://issues.apache.org/jira/browse/SOLR-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545218#comment-13545218 ] Commit Tag Bot commented on SOLR-4275: -- [branch_4x commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1429420 Merged revision(s) 1429419 from lucene/dev/trunk: SOLR-4275: Fix test. Sorry, the Solr build system did not recognize the test change without ant clean!? > TrieTokenizer causes StringIOOBE when input is empty instead of returning no > token > -- > > Key: SOLR-4275 > URL: https://issues.apache.org/jira/browse/SOLR-4275 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.1, 5.0 > > Attachments: SOLR-4275.patch > > > When you use the admin interface and select a trie field (e.g. tint) and > enter nothing into the field, the tokenizer should normally return no tokens. > TrieTokenizer instead gets and SIOOBE because read() into the charbuffer > returns -1 (end of stream). This is used to initialize the string's length... > The problem is mostly affecting the analysis request handler and query > parsing, but while indexing the values, Solr uses NumericField and not the > tokenizer directly. The solr admin UI has the additional problem that you get > a strange exception if you fill in the number on the left, but leave the > query (right empty). > The fix is to modify the tokenizer to behave like a real tokenizer: > - correct the read loop to look like the one from KeywordTokenizer. The > current loop is not guaranteed to work with unbuffered readers (Solr always > uses StringReaders so this is no issue, but who knows) > - if the resulting string is empty (total len == 0), set a boolean to false > and make the incrementToken/close/end methods not delegate and return false. -- 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-4271) add postingshighlighter
[ https://issues.apache.org/jira/browse/SOLR-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-4271. --- Resolution: Fixed Fix Version/s: 5.0 4.1 > add postingshighlighter > --- > > Key: SOLR-4271 > URL: https://issues.apache.org/jira/browse/SOLR-4271 > Project: Solr > Issue Type: New Feature > Components: highlighter >Reporter: Robert Muir >Assignee: Robert Muir > Fix For: 4.1, 5.0 > > Attachments: SOLR-4271.patch > > > add solr integration for postingshighlighter, and move it out of the sandbox. -- 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-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
[ https://issues.apache.org/jira/browse/SOLR-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545212#comment-13545212 ] Commit Tag Bot commented on SOLR-4275: -- [trunk commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1429419 SOLR-4275: Fix test. Sorry, the Solr build system did not recognize the test change without ant clean!? > TrieTokenizer causes StringIOOBE when input is empty instead of returning no > token > -- > > Key: SOLR-4275 > URL: https://issues.apache.org/jira/browse/SOLR-4275 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.1, 5.0 > > Attachments: SOLR-4275.patch > > > When you use the admin interface and select a trie field (e.g. tint) and > enter nothing into the field, the tokenizer should normally return no tokens. > TrieTokenizer instead gets and SIOOBE because read() into the charbuffer > returns -1 (end of stream). This is used to initialize the string's length... > The problem is mostly affecting the analysis request handler and query > parsing, but while indexing the values, Solr uses NumericField and not the > tokenizer directly. The solr admin UI has the additional problem that you get > a strange exception if you fill in the number on the left, but leave the > query (right empty). > The fix is to modify the tokenizer to behave like a real tokenizer: > - correct the read loop to look like the one from KeywordTokenizer. The > current loop is not guaranteed to work with unbuffered readers (Solr always > uses StringReaders so this is no issue, but who knows) > - if the resulting string is empty (total len == 0), set a boolean to false > and make the incrementToken/close/end methods not delegate and return false. -- 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-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
[ https://issues.apache.org/jira/browse/SOLR-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545211#comment-13545211 ] Commit Tag Bot commented on SOLR-4275: -- [branch_4x commit] Robert Muir http://svn.apache.org/viewvc?view=revision&revision=1429417 SOLR-4275: unbreak the build > TrieTokenizer causes StringIOOBE when input is empty instead of returning no > token > -- > > Key: SOLR-4275 > URL: https://issues.apache.org/jira/browse/SOLR-4275 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.1, 5.0 > > Attachments: SOLR-4275.patch > > > When you use the admin interface and select a trie field (e.g. tint) and > enter nothing into the field, the tokenizer should normally return no tokens. > TrieTokenizer instead gets and SIOOBE because read() into the charbuffer > returns -1 (end of stream). This is used to initialize the string's length... > The problem is mostly affecting the analysis request handler and query > parsing, but while indexing the values, Solr uses NumericField and not the > tokenizer directly. The solr admin UI has the additional problem that you get > a strange exception if you fill in the number on the left, but leave the > query (right empty). > The fix is to modify the tokenizer to behave like a real tokenizer: > - correct the read loop to look like the one from KeywordTokenizer. The > current loop is not guaranteed to work with unbuffered readers (Solr always > uses StringReaders so this is no issue, but who knows) > - if the resulting string is empty (total len == 0), set a boolean to false > and make the incrementToken/close/end methods not delegate and return false. -- 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-4271) add postingshighlighter
[ https://issues.apache.org/jira/browse/SOLR-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545210#comment-13545210 ] Commit Tag Bot commented on SOLR-4271: -- [trunk commit] Robert Muir http://svn.apache.org/viewvc?view=revision&revision=1429413 SOLR-4271: add support for PostingsHighlighter > add postingshighlighter > --- > > Key: SOLR-4271 > URL: https://issues.apache.org/jira/browse/SOLR-4271 > Project: Solr > Issue Type: New Feature > Components: highlighter >Reporter: Robert Muir >Assignee: Robert Muir > Attachments: SOLR-4271.patch > > > add solr integration for postingshighlighter, and move it out of the sandbox. -- 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-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
[ https://issues.apache.org/jira/browse/SOLR-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545209#comment-13545209 ] Commit Tag Bot commented on SOLR-4275: -- [branch_4x commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1429411 Merged revision(s) 1429410 from lucene/dev/trunk: SOLR-4275: Add test > TrieTokenizer causes StringIOOBE when input is empty instead of returning no > token > -- > > Key: SOLR-4275 > URL: https://issues.apache.org/jira/browse/SOLR-4275 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.1, 5.0 > > Attachments: SOLR-4275.patch > > > When you use the admin interface and select a trie field (e.g. tint) and > enter nothing into the field, the tokenizer should normally return no tokens. > TrieTokenizer instead gets and SIOOBE because read() into the charbuffer > returns -1 (end of stream). This is used to initialize the string's length... > The problem is mostly affecting the analysis request handler and query > parsing, but while indexing the values, Solr uses NumericField and not the > tokenizer directly. The solr admin UI has the additional problem that you get > a strange exception if you fill in the number on the left, but leave the > query (right empty). > The fix is to modify the tokenizer to behave like a real tokenizer: > - correct the read loop to look like the one from KeywordTokenizer. The > current loop is not guaranteed to work with unbuffered readers (Solr always > uses StringReaders so this is no issue, but who knows) > - if the resulting string is empty (total len == 0), set a boolean to false > and make the incrementToken/close/end methods not delegate and return false. -- 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-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
[ https://issues.apache.org/jira/browse/SOLR-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545208#comment-13545208 ] Commit Tag Bot commented on SOLR-4275: -- [trunk commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1429410 SOLR-4275: Add test > TrieTokenizer causes StringIOOBE when input is empty instead of returning no > token > -- > > Key: SOLR-4275 > URL: https://issues.apache.org/jira/browse/SOLR-4275 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.1, 5.0 > > Attachments: SOLR-4275.patch > > > When you use the admin interface and select a trie field (e.g. tint) and > enter nothing into the field, the tokenizer should normally return no tokens. > TrieTokenizer instead gets and SIOOBE because read() into the charbuffer > returns -1 (end of stream). This is used to initialize the string's length... > The problem is mostly affecting the analysis request handler and query > parsing, but while indexing the values, Solr uses NumericField and not the > tokenizer directly. The solr admin UI has the additional problem that you get > a strange exception if you fill in the number on the left, but leave the > query (right empty). > The fix is to modify the tokenizer to behave like a real tokenizer: > - correct the read loop to look like the one from KeywordTokenizer. The > current loop is not guaranteed to work with unbuffered readers (Solr always > uses StringReaders so this is no issue, but who knows) > - if the resulting string is empty (total len == 0), set a boolean to false > and make the incrementToken/close/end methods not delegate and return false. -- 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-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
[ https://issues.apache.org/jira/browse/SOLR-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545199#comment-13545199 ] Commit Tag Bot commented on SOLR-4275: -- [branch_4x commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1429402 Merged revision(s) 1429401 from lucene/dev/trunk: SOLR-4275: Fix TrieTokenizer to no longer throw StringIndexOutOfBoundsException in admin UI / AnalysisRequestHandler when you enter no number to tokenize > TrieTokenizer causes StringIOOBE when input is empty instead of returning no > token > -- > > Key: SOLR-4275 > URL: https://issues.apache.org/jira/browse/SOLR-4275 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.1, 5.0 > > Attachments: SOLR-4275.patch > > > When you use the admin interface and select a trie field (e.g. tint) and > enter nothing into the field, the tokenizer should normally return no tokens. > TrieTokenizer instead gets and SIOOBE because read() into the charbuffer > returns -1 (end of stream). This is used to initialize the string's length... > The problem is mostly affecting the analysis request handler and query > parsing, but while indexing the values, Solr uses NumericField and not the > tokenizer directly. The solr admin UI has the additional problem that you get > a strange exception if you fill in the number on the left, but leave the > query (right empty). > The fix is to modify the tokenizer to behave like a real tokenizer: > - correct the read loop to look like the one from KeywordTokenizer. The > current loop is not guaranteed to work with unbuffered readers (Solr always > uses StringReaders so this is no issue, but who knows) > - if the resulting string is empty (total len == 0), set a boolean to false > and make the incrementToken/close/end methods not delegate and return false. -- 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-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
[ https://issues.apache.org/jira/browse/SOLR-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545197#comment-13545197 ] Commit Tag Bot commented on SOLR-4275: -- [trunk commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1429401 SOLR-4275: Fix TrieTokenizer to no longer throw StringIndexOutOfBoundsException in admin UI / AnalysisRequestHandler when you enter no number to tokenize > TrieTokenizer causes StringIOOBE when input is empty instead of returning no > token > -- > > Key: SOLR-4275 > URL: https://issues.apache.org/jira/browse/SOLR-4275 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.1, 5.0 > > Attachments: SOLR-4275.patch > > > When you use the admin interface and select a trie field (e.g. tint) and > enter nothing into the field, the tokenizer should normally return no tokens. > TrieTokenizer instead gets and SIOOBE because read() into the charbuffer > returns -1 (end of stream). This is used to initialize the string's length... > The problem is mostly affecting the analysis request handler and query > parsing, but while indexing the values, Solr uses NumericField and not the > tokenizer directly. The solr admin UI has the additional problem that you get > a strange exception if you fill in the number on the left, but leave the > query (right empty). > The fix is to modify the tokenizer to behave like a real tokenizer: > - correct the read loop to look like the one from KeywordTokenizer. The > current loop is not guaranteed to work with unbuffered readers (Solr always > uses StringReaders so this is no issue, but who knows) > - if the resulting string is empty (total len == 0), set a boolean to false > and make the incrementToken/close/end methods not delegate and return false. -- 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-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
[ https://issues.apache.org/jira/browse/SOLR-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved SOLR-4275. - Resolution: Fixed Committed to 4.x and trunk. > TrieTokenizer causes StringIOOBE when input is empty instead of returning no > token > -- > > Key: SOLR-4275 > URL: https://issues.apache.org/jira/browse/SOLR-4275 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.1, 5.0 > > Attachments: SOLR-4275.patch > > > When you use the admin interface and select a trie field (e.g. tint) and > enter nothing into the field, the tokenizer should normally return no tokens. > TrieTokenizer instead gets and SIOOBE because read() into the charbuffer > returns -1 (end of stream). This is used to initialize the string's length... > The problem is mostly affecting the analysis request handler and query > parsing, but while indexing the values, Solr uses NumericField and not the > tokenizer directly. The solr admin UI has the additional problem that you get > a strange exception if you fill in the number on the left, but leave the > query (right empty). > The fix is to modify the tokenizer to behave like a real tokenizer: > - correct the read loop to look like the one from KeywordTokenizer. The > current loop is not guaranteed to work with unbuffered readers (Solr always > uses StringReaders so this is no issue, but who knows) > - if the resulting string is empty (total len == 0), set a boolean to false > and make the incrementToken/close/end methods not delegate and return false. -- 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-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
[ https://issues.apache.org/jira/browse/SOLR-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-4275: Description: When you use the admin interface and select a trie field (e.g. tint) and enter nothing into the field, the tokenizer should normally return no tokens. TrieTokenizer instead gets and SIOOBE because read() into the charbuffer returns -1 (end of stream). This is used to initialize the string's length... The problem is mostly affecting the analysis request handler and query parsing, but while indexing the values, Solr uses NumericField and not the tokenizer directly. The solr admin UI has the additional problem that you get a strange exception if you fill in the number on the left, but leave the query (right empty). The fix is to modify the tokenizer to behave like a real tokenizer: - correct the read loop to look like the one from KeywordTokenizer. The current loop is not guaranteed to work with unbuffered readers (Solr always uses StringReaders so this is no issue, but who knows) - if the resulting string is empty (total len == 0), set a boolean to false and make the incrementToken/close/end methods not delegate and return false. was: When you use the admin interface and select a trie field (e.g. tint) and enter nothing into the field, the tokenizer should normally return no tokens. TrieTokenizer instead gets and SIOOBE because read() into the charbuffer returns -1 (end of stream). This is used to initialize the string's length... The fix is to modify the tokenizer to behave like a real tokenizer: - after reading the input, check if empty (read < 0) and then use 0 as length - if the resulting string is empty (total len == 0), set a boolean to false and make the incrementToken/end methods not delegate and return false. > TrieTokenizer causes StringIOOBE when input is empty instead of returning no > token > -- > > Key: SOLR-4275 > URL: https://issues.apache.org/jira/browse/SOLR-4275 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.1, 5.0 > > Attachments: SOLR-4275.patch > > > When you use the admin interface and select a trie field (e.g. tint) and > enter nothing into the field, the tokenizer should normally return no tokens. > TrieTokenizer instead gets and SIOOBE because read() into the charbuffer > returns -1 (end of stream). This is used to initialize the string's length... > The problem is mostly affecting the analysis request handler and query > parsing, but while indexing the values, Solr uses NumericField and not the > tokenizer directly. The solr admin UI has the additional problem that you get > a strange exception if you fill in the number on the left, but leave the > query (right empty). > The fix is to modify the tokenizer to behave like a real tokenizer: > - correct the read loop to look like the one from KeywordTokenizer. The > current loop is not guaranteed to work with unbuffered readers (Solr always > uses StringReaders so this is no issue, but who knows) > - if the resulting string is empty (total len == 0), set a boolean to false > and make the incrementToken/close/end methods not delegate and return false. -- 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-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
[ https://issues.apache.org/jira/browse/SOLR-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-4275: Attachment: SOLR-4275.patch Simle patch. It also corrects the read logic so it also works with unbuffered input readers. > TrieTokenizer causes StringIOOBE when input is empty instead of returning no > token > -- > > Key: SOLR-4275 > URL: https://issues.apache.org/jira/browse/SOLR-4275 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.1, 5.0 > > Attachments: SOLR-4275.patch > > > When you use the admin interface and select a trie field (e.g. tint) and > enter nothing into the field, the tokenizer should normally return no tokens. > TrieTokenizer instead gets and SIOOBE because read() into the charbuffer > returns -1 (end of stream). This is used to initialize the string's length... > The fix is to modify the tokenizer to behave like a real tokenizer: > - after reading the input, check if empty (read < 0) and then use 0 as length > - if the resulting string is empty (total len == 0), set a boolean to false > and make the incrementToken/end methods not delegate and return false. -- 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-4273) Lazy/transient core loading - display cores not currently loaded with different background color
[ https://issues.apache.org/jira/browse/SOLR-4273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545191#comment-13545191 ] Shawn Heisey commented on SOLR-4273: I just thought of another use for this idea - a red background color for cores that did not load due to an error. If possible, clicking on the core would display any available error messages. > Lazy/transient core loading - display cores not currently loaded with > different background color > > > Key: SOLR-4273 > URL: https://issues.apache.org/jira/browse/SOLR-4273 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.0 >Reporter: Shawn Heisey > Fix For: 4.2, 5.0 > > > An idea related to SOLR-4267 and SOLR-4268. > When using cores with the transient option turned on, there may be cores that > are configured, but not actually loaded. It would be useful to have those > cores display in the core list, but with a different background color to > indicate this not-loaded state. > I don't think the color should be red, because red tends to indicate > something is wrong. If possible, whatever color is chosen should work for > people with common forms of color blindness. -- 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-4275) TrieTokenizer causes StringIOOBE when input is empty instead of returning no token
Uwe Schindler created SOLR-4275: --- Summary: TrieTokenizer causes StringIOOBE when input is empty instead of returning no token Key: SOLR-4275 URL: https://issues.apache.org/jira/browse/SOLR-4275 Project: Solr Issue Type: Bug Affects Versions: 4.0 Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 4.1, 5.0 When you use the admin interface and select a trie field (e.g. tint) and enter nothing into the field, the tokenizer should normally return no tokens. TrieTokenizer instead gets and SIOOBE because read() into the charbuffer returns -1 (end of stream). This is used to initialize the string's length... The fix is to modify the tokenizer to behave like a real tokenizer: - after reading the input, check if empty (read < 0) and then use 0 as length - if the resulting string is empty (total len == 0), set a boolean to false and make the incrementToken/end methods not delegate and return false. -- 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-4274) Solr logs loud exception when a client closes the connection before the response is sent
[ https://issues.apache.org/jira/browse/SOLR-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545188#comment-13545188 ] Shawn Heisey commented on SOLR-4274: There is also a pair of exceptions logged to stdout by jetty. No idea whether these can be shortened or eliminated. > Solr logs loud exception when a client closes the connection before the > response is sent > > > Key: SOLR-4274 > URL: https://issues.apache.org/jira/browse/SOLR-4274 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Shawn Heisey > Fix For: 4.2, 5.0 > > > If a client closes the HTTP/TCP connection before Solr has had time to > respond, a loud Jetty exception is thrown and logged. If possible, I would > like to see that reduced to a warning message that includes the request > parameters. -- 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-4274) Solr logs loud exception when a client closes the connection before the response is sent
[
https://issues.apache.org/jira/browse/SOLR-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545187#comment-13545187
]
Shawn Heisey commented on SOLR-4274:
Exception from Solr branch_4x:
{noformat}
ERROR - 2013-01-03 02:32:47.732; org.apache.solr.common.SolrException;
null:org.eclipse.jetty.io.EofException
at
org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:914)
at
org.eclipse.jetty.http.AbstractGenerator.blockForOutput(AbstractGenerator.java:523)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:147)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:107)
at
org.apache.solr.common.util.FastOutputStream.flush(FastOutputStream.java:214)
at
org.apache.solr.common.util.FastOutputStream.flushBuffer(FastOutputStream.java:207)
at
org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:94)
at
org.apache.solr.response.BinaryResponseWriter.write(BinaryResponseWriter.java:50)
at
org.apache.solr.servlet.SolrDispatchFilter.writeResponse(SolrDispatchFilter.java:407)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:292)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:560)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:365)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:926)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:988)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94)
at sun.nio.ch.IOUtil.write(IOUtil.java:65)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:450)
at
org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:293)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:362)
at
org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:341)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:336)
at
org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:841)
... 34 more
{noformat}
> Solr logs loud exception when a client closes the connection before the
> response is sent
>
>
> Key: SOLR-4274
> URL: https://issues.apache.org/jira/browse/SOLR-4274
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
>
> If a client closes the HTTP/TCP connection before Solr has had time to
> respond, a loud Jetty
[jira] [Commented] (SOLR-4274) Solr logs loud exception when a client closes the connection before the response is sent
[ https://issues.apache.org/jira/browse/SOLR-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545186#comment-13545186 ] Shawn Heisey commented on SOLR-4274: It may not be possible or desirable to fix this, but just in case, I wanted to make the request. I filed SOLR-4191 because I was seeing exceptions from this issue in my log. Ultimately I determined that the problem was mine - bad GC tuning. > Solr logs loud exception when a client closes the connection before the > response is sent > > > Key: SOLR-4274 > URL: https://issues.apache.org/jira/browse/SOLR-4274 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Shawn Heisey > Fix For: 4.2, 5.0 > > > If a client closes the HTTP/TCP connection before Solr has had time to > respond, a loud Jetty exception is thrown and logged. If possible, I would > like to see that reduced to a warning message that includes the request > parameters. -- 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-4274) Solr logs loud exception when a client closes the connection before the response is sent
Shawn Heisey created SOLR-4274: -- Summary: Solr logs loud exception when a client closes the connection before the response is sent Key: SOLR-4274 URL: https://issues.apache.org/jira/browse/SOLR-4274 Project: Solr Issue Type: Bug Affects Versions: 4.0 Reporter: Shawn Heisey Fix For: 4.2, 5.0 If a client closes the HTTP/TCP connection before Solr has had time to respond, a loud Jetty exception is thrown and logged. If possible, I would like to see that reduced to a warning message that includes the request parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-4191) Exceptions thrown when /admin/mbeans or /admin/ping is accessed during update/commit
[
https://issues.apache.org/jira/browse/SOLR-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey closed SOLR-4191.
--
Resolution: Not A Problem
> Exceptions thrown when /admin/mbeans or /admin/ping is accessed during
> update/commit
>
>
> Key: SOLR-4191
> URL: https://issues.apache.org/jira/browse/SOLR-4191
> Project: Solr
> Issue Type: Bug
>Affects Versions: 3.5, 4.1
> Environment: solr-impl 4.1-SNAPSHOT 1421496 - ncindex - 2012-12-13
> 14:56:25
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
> Attachments: solr-2012-12-14[1].log
>
>
> I am getting the following exceptions in quick succession in the solr log
> when /admin/mbeans is accessed at the moment that an update/commit is
> happening:
> ERROR - 2012-12-13 18:17:01.930; org.apache.solr.common.SolrException;
> null:org.eclipse.jetty.io.EofException
> ERROR - 2012-12-13 18:17:01.982; org.apache.solr.common.SolrException;
> null:org.eclipse.jetty.io.EofException
> WARN - 2012-12-13 18:17:01.984; org.eclipse.jetty.server.Response; Committed
> before 500 {msg=Broken pipe,trace=org.eclipse.jetty.io.EofException
> WARN - 2012-12-13 18:17:01.984; org.eclipse.jetty.servlet.ServletHandler;
> /solr/s0live/admin/mbeans
> java.lang.IllegalStateException: Committed
> I will attach the full solr log. Before SOLR-4135 was fixed, I got a *lot*
> of those exceptions, but these were far less common. Now these appear to be
> the only thing I am getting in my logs, which log4j is logging at WARN.
--
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-4191) Exceptions thrown when /admin/mbeans or /admin/ping is accessed during update/commit
[
https://issues.apache.org/jira/browse/SOLR-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545183#comment-13545183
]
Shawn Heisey commented on SOLR-4191:
I will close this issue as not a problem. I went into so much detail because
others might run into something similar, this may help them fix it.
> Exceptions thrown when /admin/mbeans or /admin/ping is accessed during
> update/commit
>
>
> Key: SOLR-4191
> URL: https://issues.apache.org/jira/browse/SOLR-4191
> Project: Solr
> Issue Type: Bug
>Affects Versions: 3.5, 4.1
> Environment: solr-impl 4.1-SNAPSHOT 1421496 - ncindex - 2012-12-13
> 14:56:25
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
> Attachments: solr-2012-12-14[1].log
>
>
> I am getting the following exceptions in quick succession in the solr log
> when /admin/mbeans is accessed at the moment that an update/commit is
> happening:
> ERROR - 2012-12-13 18:17:01.930; org.apache.solr.common.SolrException;
> null:org.eclipse.jetty.io.EofException
> ERROR - 2012-12-13 18:17:01.982; org.apache.solr.common.SolrException;
> null:org.eclipse.jetty.io.EofException
> WARN - 2012-12-13 18:17:01.984; org.eclipse.jetty.server.Response; Committed
> before 500 {msg=Broken pipe,trace=org.eclipse.jetty.io.EofException
> WARN - 2012-12-13 18:17:01.984; org.eclipse.jetty.servlet.ServletHandler;
> /solr/s0live/admin/mbeans
> java.lang.IllegalStateException: Committed
> I will attach the full solr log. Before SOLR-4135 was fixed, I got a *lot*
> of those exceptions, but these were far less common. Now these appear to be
> the only thing I am getting in my logs, which log4j is logging at WARN.
--
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-4191) Exceptions thrown when /admin/mbeans or /admin/ping is accessed during update/commit
[
https://issues.apache.org/jira/browse/SOLR-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545174#comment-13545174
]
Shawn Heisey commented on SOLR-4191:
I changed the NewRatio to 8 while I was doing a full-import on all shards. I
did have one DOWN event on the load balancer during that import, but it was not
caused by a GC pause. It appears that the ping request took 7.7 seconds, which
is longer than the 5 second timeout on the load balancer check. Best guess is
that the I/O involved in indexing and merging made the ping take too long.
After the full-import finished, I removed NewRatio and instead went with
MaxNewSize. Here is my memory config now:
-Xms4096M -Xmx8192M -XX:MaxNewSize=256M -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+CMSIncrementalMode
-XX:MaxTenuringThreshold=3
I will do another full-import later and then let it run uninterrupted for a few
days to see what happens.
> Exceptions thrown when /admin/mbeans or /admin/ping is accessed during
> update/commit
>
>
> Key: SOLR-4191
> URL: https://issues.apache.org/jira/browse/SOLR-4191
> Project: Solr
> Issue Type: Bug
>Affects Versions: 3.5, 4.1
> Environment: solr-impl 4.1-SNAPSHOT 1421496 - ncindex - 2012-12-13
> 14:56:25
>Reporter: Shawn Heisey
> Fix For: 4.2, 5.0
>
> Attachments: solr-2012-12-14[1].log
>
>
> I am getting the following exceptions in quick succession in the solr log
> when /admin/mbeans is accessed at the moment that an update/commit is
> happening:
> ERROR - 2012-12-13 18:17:01.930; org.apache.solr.common.SolrException;
> null:org.eclipse.jetty.io.EofException
> ERROR - 2012-12-13 18:17:01.982; org.apache.solr.common.SolrException;
> null:org.eclipse.jetty.io.EofException
> WARN - 2012-12-13 18:17:01.984; org.eclipse.jetty.server.Response; Committed
> before 500 {msg=Broken pipe,trace=org.eclipse.jetty.io.EofException
> WARN - 2012-12-13 18:17:01.984; org.eclipse.jetty.servlet.ServletHandler;
> /solr/s0live/admin/mbeans
> java.lang.IllegalStateException: Committed
> I will attach the full solr log. Before SOLR-4135 was fixed, I got a *lot*
> of those exceptions, but these were far less common. Now these appear to be
> the only thing I am getting in my logs, which log4j is logging at WARN.
--
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-4273) Lazy/transient core loading - display cores not currently loaded with different background color
Shawn Heisey created SOLR-4273: -- Summary: Lazy/transient core loading - display cores not currently loaded with different background color Key: SOLR-4273 URL: https://issues.apache.org/jira/browse/SOLR-4273 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Reporter: Shawn Heisey Fix For: 4.2, 5.0 An idea related to SOLR-4267 and SOLR-4268. When using cores with the transient option turned on, there may be cores that are configured, but not actually loaded. It would be useful to have those cores display in the core list, but with a different background color to indicate this not-loaded state. I don't think the color should be red, because red tends to indicate something is wrong. If possible, whatever color is chosen should work for people with common forms of color blindness. -- 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-4267) Solr Admin UI - checkbox option to sort cores by name
[ https://issues.apache.org/jira/browse/SOLR-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545165#comment-13545165 ] Shawn Heisey commented on SOLR-4267: The list of cores is nicely sorted now! It seems to take a bit longer than I would expect to display the core list on a page refresh. I have 16 cores. I don't know that the sort made it any slower, it could be just that I am focused on it a little more now. I worry about the performance for 'thousands of cores' functionality. > Solr Admin UI - checkbox option to sort cores by name > - > > Key: SOLR-4267 > URL: https://issues.apache.org/jira/browse/SOLR-4267 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 4.0 >Reporter: Shawn Heisey > Fix For: 4.1, 5.0 > > > The new UI currently shows the list of cores in an unsorted order. > Presumably they are shown in the order that they finished starting, but I > have not looked to verify this. I would like to have the option to show that > list sorted alphanumerically. IMHO it would be good to make this the > default, but I'm not willing to speak for others. > There has been recent work to support thousands of cores. I think that this > would be even more important for that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4653) Make TestIndexWriter.testThreadInterruptDeadlock meaner
[ https://issues.apache.org/jira/browse/LUCENE-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544871#comment-13544871 ] Commit Tag Bot commented on LUCENE-4653: [trunk commit] Michael McCandless http://svn.apache.org/viewvc?view=revision&revision=1428306 LUCENE-4653: add deletes to TIW.testThreadInterruptDeadlock; fix a few places that didn't handle InterruptedException properly > Make TestIndexWriter.testThreadInterruptDeadlock meaner > --- > > Key: LUCENE-4653 > URL: https://issues.apache.org/jira/browse/LUCENE-4653 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4653.patch, LUCENE-4653.patch > > > Just tweaking the test to also call w.updateDocument (so we sometimes apply > deletes) (Rob's idea) causes all sorts of fun failures ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4647) Simplify CategoryDocumentBuilder
[ https://issues.apache.org/jira/browse/LUCENE-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544870#comment-13544870 ] Commit Tag Bot commented on LUCENE-4647: [trunk commit] Shai Erera http://svn.apache.org/viewvc?view=revision&revision=1428320 LUCENE-4647: Simplify CategoryDocumentBuilder > Simplify CategoryDocumentBuilder > > > Key: LUCENE-4647 > URL: https://issues.apache.org/jira/browse/LUCENE-4647 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet >Reporter: Shai Erera >Assignee: Shai Erera > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4647.patch > > > CategoryDocumentBuilder is used to add facet fields to a document. Today the > usage is not so straightforward, and I'd like to simplify it. First, to > improve usage but also to make cutover to DocValues easier. > This clsas does two operations: (1) adds drill-down terms and (2) creates the > fulltree payload. Today, since it does it all on terms, there's a hairy > TokenStream which does both these operations in one go. For simplicity, I'd > like to break this into two steps: > # Write a TokenStream which adds the drill-down terms > #* For no associations, terms should be indexed w/ DOCS_ONLY (see > LUCENE-4623). > #* With associations, drill-down terms have payload too. > #* So EnhancementsDocumentBuilder should be able to extend this stream. > # Write some API which can be used to build the fulltree payload (i.e. > populate a byte[]). Currently that byte[] will be written to a payload and > later to DV. > Hopefully, I'd like to have FacetsDocumentBuilder (maybe just FacetsBuilder?) > which only handles things with no associations, and EnhancementsDocBuilder > which extends whatever is needed to add associations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4290) basic highlighter that uses postings offsets
[ https://issues.apache.org/jira/browse/LUCENE-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544869#comment-13544869 ] Commit Tag Bot commented on LUCENE-4290: [trunk commit] Robert Muir http://svn.apache.org/viewvc?view=revision&revision=1428338 LUCENE-4290: use SimpleAnalyzer so we test single-word sentences too > basic highlighter that uses postings offsets > > > Key: LUCENE-4290 > URL: https://issues.apache.org/jira/browse/LUCENE-4290 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/other >Reporter: Robert Muir > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4290.patch > > > We added IndexOptions.DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS so you can > efficiently compress character offsets in the postings list, but nothing yet > makes use of this. > Here is a simple highlighter that uses them: it doesn't have many tests or > fancy features, but I think its ok for the sandbox/ (maybe with a couple more > tests) > Additionally I didnt do any benchmarking. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1972) Need additional query stats in admin interface - median, 95th and 99th percentile
[ https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544868#comment-13544868 ] Commit Tag Bot commented on SOLR-1972: -- [trunk commit] Alan Woodward http://svn.apache.org/viewvc?view=revision&revision=1428372 SOLR-1972: Add extra query stats to RequestHandler > Need additional query stats in admin interface - median, 95th and 99th > percentile > - > > Key: SOLR-1972 > URL: https://issues.apache.org/jira/browse/SOLR-1972 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 1.4 >Reporter: Shawn Heisey >Assignee: Alan Woodward >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, > elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, > elyograg-closeable.patch, leak-closeable.patch, leak.patch, > revert-SOLR-1972.patch, SOLR-1972-branch3x-url_pattern.patch, > SOLR-1972-branch4x.patch, SOLR-1972-branch4x.patch, > SOLR-1972_forked-metrics.patch, SOLR-1972_forked-metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > solr1972-metricsregistry-branch4x-failure.log, SOLR-1972.patch, > SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, > SOLR-1972-url_pattern.patch, stacktraces.tar.gz > > > I would like to see more detailed query statistics from the admin GUI. This > is what you can get now: > requests : 809 > errors : 0 > timeouts : 0 > totalTime : 70053 > avgTimePerRequest : 86.59209 > avgRequestsPerSecond : 0.8148785 > I'd like to see more data on the time per request - median, 95th percentile, > 99th percentile, and any other statistical function that makes sense to > include. In my environment, the first bunch of queries after startup tend to > take several seconds each. I find that the average value tends to be useless > until it has several thousand queries under its belt and the caches are > thoroughly warmed. The statistical functions I have mentioned would quickly > eliminate the influence of those initial slow queries. > The system will have to store individual data about each query. I don't know > if this is something Solr does already. It would be nice to have a > configurable count of how many of the most recent data points are kept, to > control the amount of memory the feature uses. The default value could be > something like 1024 or 4096. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4651) Use generics for the type of assigned class in Classifier
[ https://issues.apache.org/jira/browse/LUCENE-4651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544867#comment-13544867 ] Commit Tag Bot commented on LUCENE-4651: [trunk commit] Tommaso Teofili http://svn.apache.org/viewvc?view=revision&revision=1428411 [LUCENE-4651] - added generics to Classifier and ClassificationResult > Use generics for the type of assigned class in Classifier > - > > Key: LUCENE-4651 > URL: https://issues.apache.org/jira/browse/LUCENE-4651 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/classification >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Minor > Fix For: 5.0 > > Attachments: LUCENE-4651.patch > > > Currently Classifier#assignClass returns a ClassificationResult which holds > the class as a String while there are use cases where this would be not > optimal as assigned labels types could be known upfront, therefore having a > _Classifier_ returning a _ClassificationResult_ would be better. > Side node: current implementations could be improved by using _BytesRef_ > instead of _String_ . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4653) Make TestIndexWriter.testThreadInterruptDeadlock meaner
[ https://issues.apache.org/jira/browse/LUCENE-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544866#comment-13544866 ] Commit Tag Bot commented on LUCENE-4653: [trunk commit] Michael McCandless http://svn.apache.org/viewvc?view=revision&revision=1428432 LUCENE-4653: make test more evil; fix leak on exception in IW.getReader > Make TestIndexWriter.testThreadInterruptDeadlock meaner > --- > > Key: LUCENE-4653 > URL: https://issues.apache.org/jira/browse/LUCENE-4653 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4653.patch, LUCENE-4653.patch > > > Just tweaking the test to also call w.updateDocument (so we sometimes apply > deletes) (Rob's idea) causes all sorts of fun failures ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4653) Make TestIndexWriter.testThreadInterruptDeadlock meaner
[ https://issues.apache.org/jira/browse/LUCENE-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544865#comment-13544865 ] Commit Tag Bot commented on LUCENE-4653: [trunk commit] Michael McCandless http://svn.apache.org/viewvc?view=revision&revision=1428440 LUCENE-4653: reduce iterations back to 300 > Make TestIndexWriter.testThreadInterruptDeadlock meaner > --- > > Key: LUCENE-4653 > URL: https://issues.apache.org/jira/browse/LUCENE-4653 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4653.patch, LUCENE-4653.patch > > > Just tweaking the test to also call w.updateDocument (so we sometimes apply > deletes) (Rob's idea) causes all sorts of fun failures ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4657) a new testThreadInterruptDeadlock failure
[ https://issues.apache.org/jira/browse/LUCENE-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544864#comment-13544864 ] Commit Tag Bot commented on LUCENE-4657: [trunk commit] Robert Muir http://svn.apache.org/viewvc?view=revision&revision=1428552 LUCENE-4657: disable deleteAll in this test until we figure it out > a new testThreadInterruptDeadlock failure > - > > Key: LUCENE-4657 > URL: https://issues.apache.org/jira/browse/LUCENE-4657 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4657_hack.patch, LUCENE-4657.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4657) a new testThreadInterruptDeadlock failure
[ https://issues.apache.org/jira/browse/LUCENE-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544863#comment-13544863 ] Commit Tag Bot commented on LUCENE-4657: [trunk commit] Michael McCandless http://svn.apache.org/viewvc?view=revision&revision=1428609 LUCENE-4657: make test evil again; fix more InterruptedException handling cases > a new testThreadInterruptDeadlock failure > - > > Key: LUCENE-4657 > URL: https://issues.apache.org/jira/browse/LUCENE-4657 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4657_hack.patch, LUCENE-4657.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4653) Make TestIndexWriter.testThreadInterruptDeadlock meaner
[ https://issues.apache.org/jira/browse/LUCENE-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544862#comment-13544862 ] Commit Tag Bot commented on LUCENE-4653: [trunk commit] Robert Muir http://svn.apache.org/viewvc?view=revision&revision=1428636 LUCENE-4653: toss in a addIndexes > Make TestIndexWriter.testThreadInterruptDeadlock meaner > --- > > Key: LUCENE-4653 > URL: https://issues.apache.org/jira/browse/LUCENE-4653 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4653.patch, LUCENE-4653.patch > > > Just tweaking the test to also call w.updateDocument (so we sometimes apply > deletes) (Rob's idea) causes all sorts of fun failures ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4653) Make TestIndexWriter.testThreadInterruptDeadlock meaner
[ https://issues.apache.org/jira/browse/LUCENE-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544861#comment-13544861 ] Commit Tag Bot commented on LUCENE-4653: [trunk commit] Robert Muir http://svn.apache.org/viewvc?view=revision&revision=1428638 LUCENE-4653: only delete one doc > Make TestIndexWriter.testThreadInterruptDeadlock meaner > --- > > Key: LUCENE-4653 > URL: https://issues.apache.org/jira/browse/LUCENE-4653 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4653.patch, LUCENE-4653.patch > > > Just tweaking the test to also call w.updateDocument (so we sometimes apply > deletes) (Rob's idea) causes all sorts of fun failures ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4656) Fix IndexWriter working together with EmptyTokenizer and EmptyTokenStream (without CharTermAttribute), fix BaseTokenStreamTestCase
[ https://issues.apache.org/jira/browse/LUCENE-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544860#comment-13544860 ] Commit Tag Bot commented on LUCENE-4656: [trunk commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1428671 LUCENE-4656: Fix regression in IndexWriter to work with empty TokenStreams that have no TermToBytesRefAttribute (commonly provided by CharTermAttribute), e.g., oal.analysis.miscellaneous.EmptyTokenStream. Remove EmptyTokenizer from test-framework. > Fix IndexWriter working together with EmptyTokenizer and EmptyTokenStream > (without CharTermAttribute), fix BaseTokenStreamTestCase > -- > > Key: LUCENE-4656 > URL: https://issues.apache.org/jira/browse/LUCENE-4656 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Affects Versions: 4.0 >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Trivial > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4656_bttc.patch, LUCENE-4656-IW-bug.patch, > LUCENE-4656-IW-fix.patch, LUCENE-4656-IW-fix.patch, LUCENE-4656.patch, > LUCENE-4656.patch, LUCENE-4656.patch, LUCENE-4656.patch, LUCENE-4656.patch, > LUCENE-4656.patch > > > TestRandomChains can fail because EmptyTokenizer doesn't have a > CharTermAttribute and doesn't compute the end offset (if the offset attribute > was added by a filter). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4660) When ConcurrentMergeScheduler stalls incoming threads it has unexpected hysteresis
[ https://issues.apache.org/jira/browse/LUCENE-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544857#comment-13544857 ] Commit Tag Bot commented on LUCENE-4660: [trunk commit] Michael McCandless http://svn.apache.org/viewvc?view=revision&revision=1428949 LUCENE-4660: add missing notifyAll after merge finishes > When ConcurrentMergeScheduler stalls incoming threads it has unexpected > hysteresis > -- > > Key: LUCENE-4660 > URL: https://issues.apache.org/jira/browse/LUCENE-4660 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4660.patch > > > Eg if you set maxMergeCount to 2, as soon as a 3rd merge need to kick off, we > stall incoming segment-creating threads. Then we wait ... and we are > supposed to resume the threads when the merge count drops back to 2, but > instead we are only resuming when merge count gets to 1. Ie, we stall for > too long (= unexpected hysteresis). -- 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-3180) ChaosMonkey test failures
[ https://issues.apache.org/jira/browse/SOLR-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544856#comment-13544856 ] Commit Tag Bot commented on SOLR-3180: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1429027 SOLR-3180: tests: timeouts from 30 sec to 60 sec > ChaosMonkey test failures > - > > Key: SOLR-3180 > URL: https://issues.apache.org/jira/browse/SOLR-3180 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: 4.1, 5.0 > > Attachments: CMSL_fail1.log, CMSL_hang_2.txt, CMSL_hang.txt, > fail.130101_034142.txt, fail.130102_020942.txt, fail.130103_105104.txt, > fail.130103_193722.txt, fail.inconsistent.txt, test_report_1.txt > > > Handle intermittent failures in the ChaosMonkey tests. -- 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-4106) Javac/ ivy path warnings with morfologik
[
https://issues.apache.org/jira/browse/SOLR-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544858#comment-13544858
]
Commit Tag Bot commented on SOLR-4106:
--
[trunk commit] Dawid Weiss
http://svn.apache.org/viewvc?view=revision&revision=1428823
SOLR-4106: Javac/ ivy path warnings with morfologik fixed by updating to
Morfologik 1.5.5 (no functional changes).
> Javac/ ivy path warnings with morfologik
>
>
> Key: SOLR-4106
> URL: https://issues.apache.org/jira/browse/SOLR-4106
> Project: Solr
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4106.patch, solr4106.zip
>
>
> Does not break the build but brings javac warnings, as pointed out by rmuir:
> {code}
> [javac] warning: [path] bad path element
> "~/.ivy2/cache/org.carrot2/morfologik-polish/jars/morfologik-stemming-1.5.3.jar":
> no such file or directory
>[javac] warning: [path] bad path element
> "~/.ivy2/cache/org.carrot2/morfologik-polish/jars/morfologik-fsa-1.5.3.jar":
> no such file or directory
>[javac] warning: [path] bad path element
> "~/.ivy2/cache/org.carrot2/morfologik-stemming/jars/morfologik-fsa-1.5.3.jar":
> no such file or directory
>[javac] warning: [path] bad path element
> "~/.ivy2/cache/org.carrot2/morfologik-fsa/jars/hppc-0.4.1.jar": no such file
> or directory
> i'm just doing
>
> {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-4257) Don't wait for ZK connection to apply replay updates or peersync updates
[ https://issues.apache.org/jira/browse/SOLR-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544859#comment-13544859 ] Commit Tag Bot commented on SOLR-4257: -- [trunk commit] Yonik Seeley http://svn.apache.org/viewvc?view=revision&revision=1428677 SOLR-4257: PeerSync updates and Log Replay updates should not wait for ZK connection > Don't wait for ZK connection to apply replay updates or peersync updates > > > Key: SOLR-4257 > URL: https://issues.apache.org/jira/browse/SOLR-4257 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4257.patch, SOLR-4257.patch > > > from SOLR-3180, I saw log reply updates blocked on waiting for a ZK > connection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4662) Elision in FrenchAnalyzer
[ https://issues.apache.org/jira/browse/LUCENE-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544855#comment-13544855 ] Commit Tag Bot commented on LUCENE-4662: [trunk commit] Steven Rowe http://svn.apache.org/viewvc?view=revision&revision=1429174 LUCENE-4662: Add missing elided articles and prepos to FrenchAnalyzer's list passed to ElisionFilter > Elision in FrenchAnalyzer > - > > Key: LUCENE-4662 > URL: https://issues.apache.org/jira/browse/LUCENE-4662 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Affects Versions: 4.0-BETA >Reporter: David L >Assignee: Steve Rowe > Fix For: 4.1 > > Attachments: LUCENE-4662.patch > > > It seems org.apache.lucene.analysis.fr.FrenchAnalyzer.DEFAULT_ARTICLES is > missing "d" and "c", but also "jusqu", "quoiqu", "lorsqu", and "puisqu". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4662) Elision in FrenchAnalyzer
[ https://issues.apache.org/jira/browse/LUCENE-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544854#comment-13544854 ] Commit Tag Bot commented on LUCENE-4662: [trunk commit] Steven Rowe http://svn.apache.org/viewvc?view=revision&revision=1429177 LUCENE-4662: CHANGES.txt entry > Elision in FrenchAnalyzer > - > > Key: LUCENE-4662 > URL: https://issues.apache.org/jira/browse/LUCENE-4662 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Affects Versions: 4.0-BETA >Reporter: David L >Assignee: Steve Rowe > Fix For: 4.1 > > Attachments: LUCENE-4662.patch > > > It seems org.apache.lucene.analysis.fr.FrenchAnalyzer.DEFAULT_ARTICLES is > missing "d" and "c", but also "jusqu", "quoiqu", "lorsqu", and "puisqu". -- 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-4121) balanced single quotes cause parse error in (new) standard QParser
[
https://issues.apache.org/jira/browse/SOLR-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544852#comment-13544852
]
Commit Tag Bot commented on SOLR-4121:
--
[trunk commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revision&revision=1429188
SOLR-4121: add test for fix
> balanced single quotes cause parse error in (new) standard QParser
> --
>
> Key: SOLR-4121
> URL: https://issues.apache.org/jira/browse/SOLR-4121
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>Priority: Blocker
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4121-test.patch
>
>
> The parser changes introduced in SOLR-4093 cause the standard parser to freak
> out anytime there are blanaced single quotes in a query string.
> the expected behavior is that single quotes should not be considered special
> to the parser, and should be ignored and passed down to the appropriate field
> analyzers
> Example of error...
> http://localhost:8983/solr/select?q=%27zz+xx%27&debugQuery=true
> {noformat}
> Caused by: org.apache.solr.parser.ParseException: Encountered "
> "\'zz xx\' "" at line 1, column 0.
> Was expecting one of:
> ...
> "+" ...
> "-" ...
> ...
> "(" ...
> "*" ...
> ...
> ...
> ...
> ...
> ...
> "[" ...
> "{" ...
> ...
> ...
> ...
> "*" ...
>
> at
> org.apache.solr.parser.QueryParser.generateParseException(QueryParser.java:649)
> at
> org.apache.solr.parser.QueryParser.jj_consume_token(QueryParser.java:531)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:216)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:107)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:96)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:159)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4662) Elision in FrenchAnalyzer
[ https://issues.apache.org/jira/browse/LUCENE-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544851#comment-13544851 ] Commit Tag Bot commented on LUCENE-4662: [trunk commit] Steven Rowe http://svn.apache.org/viewvc?view=revision&revision=1429191 LUCENE-4662: Add missing elided articles and prepositions to French ElisionFilter list under Solr example > Elision in FrenchAnalyzer > - > > Key: LUCENE-4662 > URL: https://issues.apache.org/jira/browse/LUCENE-4662 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Affects Versions: 4.0-BETA >Reporter: David L >Assignee: Steve Rowe > Fix For: 4.1 > > Attachments: LUCENE-4662.patch > > > It seems org.apache.lucene.analysis.fr.FrenchAnalyzer.DEFAULT_ARTICLES is > missing "d" and "c", but also "jusqu", "quoiqu", "lorsqu", and "puisqu". -- 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-4121) balanced single quotes cause parse error in (new) standard QParser
[
https://issues.apache.org/jira/browse/SOLR-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544853#comment-13544853
]
Commit Tag Bot commented on SOLR-4121:
--
[trunk commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revision&revision=1429181
SOLR-4121: add test for fix
> balanced single quotes cause parse error in (new) standard QParser
> --
>
> Key: SOLR-4121
> URL: https://issues.apache.org/jira/browse/SOLR-4121
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>Priority: Blocker
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4121-test.patch
>
>
> The parser changes introduced in SOLR-4093 cause the standard parser to freak
> out anytime there are blanaced single quotes in a query string.
> the expected behavior is that single quotes should not be considered special
> to the parser, and should be ignored and passed down to the appropriate field
> analyzers
> Example of error...
> http://localhost:8983/solr/select?q=%27zz+xx%27&debugQuery=true
> {noformat}
> Caused by: org.apache.solr.parser.ParseException: Encountered "
> "\'zz xx\' "" at line 1, column 0.
> Was expecting one of:
> ...
> "+" ...
> "-" ...
> ...
> "(" ...
> "*" ...
> ...
> ...
> ...
> ...
> ...
> "[" ...
> "{" ...
> ...
> ...
> ...
> "*" ...
>
> at
> org.apache.solr.parser.QueryParser.generateParseException(QueryParser.java:649)
> at
> org.apache.solr.parser.QueryParser.jj_consume_token(QueryParser.java:531)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:216)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:107)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:96)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:159)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4262) Replication Icon on Dashboard does not reflect Master-/Slave-State
[ https://issues.apache.org/jira/browse/SOLR-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544850#comment-13544850 ] Commit Tag Bot commented on SOLR-4262: -- [trunk commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429248 SOLR-4262: Replication Icon on Dashboard does not reflect Master-/Slave-State > Replication Icon on Dashboard does not reflect Master-/Slave-State > -- > > Key: SOLR-4262 > URL: https://issues.apache.org/jira/browse/SOLR-4262 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Trivial > Fix For: 4.1 > > Attachments: SOLR-4262.patch > > > On the Core-Dashboard, the Replication Block shows only one (generic) icon .. > originally this should reflect the Master-/Slave-State - like it's already > done in the Title (as Text) -- 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-4262) Replication Icon on Dashboard does not reflect Master-/Slave-State
[ https://issues.apache.org/jira/browse/SOLR-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544849#comment-13544849 ] Commit Tag Bot commented on SOLR-4262: -- [trunk commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429252 SOLR-4262: Replication Icon on Dashboard does not reflect Master-/Slave-State > Replication Icon on Dashboard does not reflect Master-/Slave-State > -- > > Key: SOLR-4262 > URL: https://issues.apache.org/jira/browse/SOLR-4262 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Trivial > Fix For: 4.1 > > Attachments: SOLR-4262.patch > > > On the Core-Dashboard, the Replication Block shows only one (generic) icon .. > originally this should reflect the Master-/Slave-State - like it's already > done in the Title (as Text) -- 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-4261) Percentage Infos on Dashboard have a fixed width
[ https://issues.apache.org/jira/browse/SOLR-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544847#comment-13544847 ] Commit Tag Bot commented on SOLR-4261: -- [trunk commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429256 SOLR-4261: Percentage Infos on Dashboard have a fixed width > Percentage Infos on Dashboard have a fixed width > > > Key: SOLR-4261 > URL: https://issues.apache.org/jira/browse/SOLR-4261 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Fix For: 4.1 > > Attachments: SOLR-4261.patch > > > The Percentage Graphs on the Dashboard are calculated with a fixed width, > it's calculated once on Pageload, afterwards it stays fixed even if you > resize the Window. All the other elements are flexible .. -- 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-4045) SOLR admin page returns HTTP 404 on core names containing a '.' (dot)
[ https://issues.apache.org/jira/browse/SOLR-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544846#comment-13544846 ] Commit Tag Bot commented on SOLR-4045: -- [trunk commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429259 SOLR-4045: SOLR admin page returns HTTP 404 on core names containing a '.' (dot) > SOLR admin page returns HTTP 404 on core names containing a '.' (dot) > - > > Key: SOLR-4045 > URL: https://issues.apache.org/jira/browse/SOLR-4045 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.0 > Environment: Linux, Ubuntu 12.04 >Reporter: Alessandro Tommasi >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Labels: admin, solr, webgui > Fix For: 4.1 > > Attachments: SOLR-4045.patch, SOLR-4045.patch > > > When SOLR is configured in multicore mode, cores with '.' (dot) in their > names are inaccessible via the admin web guy. (localhost:8983/solr). The page > shows an alert with the message (test.test was my core name): > 404 Not Found get #/test.test > To replicate: start solr in multicore mode, go to "localhost:8983/solr", via > core admin create a new core "test.test", then refresh the page. "test.test" > will show under the menu at the bottom left. Clicking on it causes the > message, while no core menu appears. -- 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-4264) Missing Error-Screen on UI's Cloud-Page
[ https://issues.apache.org/jira/browse/SOLR-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544848#comment-13544848 ] Commit Tag Bot commented on SOLR-4264: -- [trunk commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429254 SOLR-4264: Missing Error-Screen on UI's Cloud-Page > Missing Error-Screen on UI's Cloud-Page > --- > > Key: SOLR-4264 > URL: https://issues.apache.org/jira/browse/SOLR-4264 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Fix For: 4.1 > > Attachments: SOLR-4264.patch > > > If you're running Solr not in "Cloud-Mode" but you're trying to access UI's > Cloud-Page (for whatever reason) the Page stays blank and doesn't provide any > information about what's happening or not -- 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-4176) analysis ui: javascript not properly handling URL decoding of input
[
https://issues.apache.org/jira/browse/SOLR-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544845#comment-13544845
]
Commit Tag Bot commented on SOLR-4176:
--
[trunk commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revision&revision=1429261
SOLR-4176: analysis ui: javascript not properly handling URL decoding of input
> analysis ui: javascript not properly handling URL decoding of input
> ---
>
> Key: SOLR-4176
> URL: https://issues.apache.org/jira/browse/SOLR-4176
> Project: Solr
> Issue Type: Bug
> Components: web gui
>Affects Versions: 4.0
>Reporter: Hoss Man
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.1
>
> Attachments: SOLR-4176.patch
>
>
> attempting to input values containing "%" in the analysis UI causes errors.
> Example of the bug, using the solr example configs...
> 1) load http://localhost:8983/solr/#/collection1/analysis in a browser
> 2) select field type "text_general"
> 3) enter into either text box: {{{foo%bar}}
> 4) click the "Analyze Values" button.
> results...
> * Window location is updated to be:
> http://localhost:8983/solr/#/collection1/analysis?analysis.fieldvalue=foo%25bar&analysis.query=&analysis.fieldtype=text_general&verbose_output=1
> ** Note: "%" has been properly encoded in URL
> * page does not display any analyis, and text areas are now empty (although
> text_general field type is still selected)
> * web dev error console indicates...{noformat}Error: URIError: malformed URI
> sequence
> Source File: http://localhost:8983/solr/js/scripts/analysis.js
> Line: 132
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3851) create a new core/delete an existing core should also update the main/left list of cores
[ https://issues.apache.org/jira/browse/SOLR-3851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544844#comment-13544844 ] Commit Tag Bot commented on SOLR-3851: -- [trunk commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429286 SOLR-3851: create a new core/delete an existing core should also update the main/left list of cores on the admin UI > create a new core/delete an existing core should also update the main/left > list of cores > > > Key: SOLR-3851 > URL: https://issues.apache.org/jira/browse/SOLR-3851 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 4.0-BETA >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Fix For: 4.1 > > Attachments: SOLR-3851.patch, SOLR-3851.patch, SOLR-3851.patch > > > While working on SOLR-3788, i realized that the main/left list of cores > needs/should also be updated when a new core is created / an existing core is > deleted, which is right now not the fact. > On a first quick look that should not be that hard, hopefully we can reuse > existing functionality from app.js, which already generates a list of cores > when the UI is initialized. -- 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-3840) XML query response display is unreadable in Solr Admin Query UI
[ https://issues.apache.org/jira/browse/SOLR-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544843#comment-13544843 ] Commit Tag Bot commented on SOLR-3840: -- [trunk commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429288 SOLR-3840: XML query response display is unreadable in Solr Admin Query UI > XML query response display is unreadable in Solr Admin Query UI > --- > > Key: SOLR-3840 > URL: https://issues.apache.org/jira/browse/SOLR-3840 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 4.0-BETA > Environment: Google Chrome, Windows 7 - Firefox as well >Reporter: Jack Krupansky >Assignee: Stefan Matheis (steffkes) > Fix For: 4.1 > > Attachments: Query-UI-XML-unreadable.png, SOLR-3840.patch, > SOLR-3840.patch, SOLR-3840.patch, solr-admin-ui-query-highlight-json.png, > solr-admin-ui-query-highlight-json.png, solr-admin-ui-query-highlight-xml.png > > > If I execute a query in the Solr Admin Query UI, the default XML "writer" > displays only the raw text of the Solr response XML element values, but none > of the XML syntax itself, rendering the response display on the Query page > almost completely useless. JSON, Ruby, et al display very reasonably > formatted output, but XML does not. > You can click on the icon next to the generated query URL to display the > response in a browser tab of its own and then it does display the XML very > reasonably, but the framed display on the query page is simply not readable. > My recollection is that the old UI had this same problem. -- 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-4079) Long core names break web gui appearance and functionality
[ https://issues.apache.org/jira/browse/SOLR-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544842#comment-13544842 ] Commit Tag Bot commented on SOLR-4079: -- [trunk commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429292 SOLR-4079: Long core names break web gui appearance and functionality > Long core names break web gui appearance and functionality > -- > > Key: SOLR-4079 > URL: https://issues.apache.org/jira/browse/SOLR-4079 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.0 > Environment: Reproduced in Chrome (23.0.1271.64) >Reporter: Janko Luin >Assignee: Stefan Matheis (steffkes) >Priority: Trivial > Fix For: 4.1 > > Attachments: proposed_patch.css, Screen Shot 2012-11-15 at > 10.40.29.png, SOLR-4079.patch, SOLR-4079.patch > > > Our data is split up over multiple cores with automatic naming, typically of > the form "articles_20080101154402_20080412181644". With long names like that, > the sidebar will massively overshoot its boundaries and intrude so far into > the main pane that it interferes with UI inputs and controls. > Fixing this issue is trivial even within the browser, by introducing a custom > stylesheet. -- 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-4263) Incorrect Link from Schema-Browser to Query From for Top-Terms
[ https://issues.apache.org/jira/browse/SOLR-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544841#comment-13544841 ] Commit Tag Bot commented on SOLR-4263: -- [trunk commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429296 SOLR-4263: Incorrect Link from Schema-Browser to Query From for Top-Terms > Incorrect Link from Schema-Browser to Query From for Top-Terms > -- > > Key: SOLR-4263 > URL: https://issues.apache.org/jira/browse/SOLR-4263 > Project: Solr > Issue Type: Bug > Components: web gui >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Fix For: 4.1 > > Attachments: SOLR-4263.patch > > > Given the Data of "exampledocs", the Schema-Browser offers Links (for jumping > from Top-Terms to the Query-Form) link this: > bq. .../query?q=manu_exact:Apache%20Software%20Foundation > which would lead to an incorrect result because the terms are splitted. -- 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-3829) Admin UI Logging events broken if schema.xml defines a catch-all dynamicField with type ignored
[
https://issues.apache.org/jira/browse/SOLR-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544840#comment-13544840
]
Commit Tag Bot commented on SOLR-3829:
--
[trunk commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revision&revision=1429298
SOLR-3829: Admin UI Logging events broken if schema.xml defines a catch-all
dynamicField with type ignored
> Admin UI Logging events broken if schema.xml defines a catch-all dynamicField
> with type ignored
> ---
>
> Key: SOLR-3829
> URL: https://issues.apache.org/jira/browse/SOLR-3829
> Project: Solr
> Issue Type: Bug
> Components: web gui
>Affects Versions: 4.0-BETA
>Reporter: Andreas Hubold
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.1
>
> Attachments: SOLR-3829.patch
>
>
> The Solr Admin page does not show any log events. There are Javascript errors
> {noformat}
> TypeError: doc.logger.esc is not a function
> ... '' + doc.logger.split( '.'
> ).pop().esc()...
> {noformat}
> This is because the response of the LoggingHandler added unexpected {{[ ...
> ]}} characters around the values for time, level, logger and message:
> {noformat}
> ...
> "history":{"numFound":2,"start":0,"docs":[{"time":["2012-09-11T15:07:05.453Z"],"level":["WARNING"],"logger":["org.apache.solr.core.SolrCore"],"message":["New
> index directory detected: ...
> {noformat}
> This is caused by the way the JSON is created.
> org.apache.solr.logging.LogWatcher#toSolrDocument creates a SolrDocument
> which is then formatted with a org.apache.solr.response.JSONResponseWriter.
> But the JSONResponseWriter uses the index schema to decide how to format the
> JSON. We have the following field declaration in schema.xml:
> {noformat}
>
> {noformat}
> The field type "ignored" has the attribute multiValued set to true. Because
> of this JSONResponseWriter adds [] characters in
> org.apache.solr.response.JSONWriter#writeSolrDocument
> The formatting should be independent from schema.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4647) Simplify CategoryDocumentBuilder
[ https://issues.apache.org/jira/browse/LUCENE-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544839#comment-13544839 ] Commit Tag Bot commented on LUCENE-4647: [branch_4x commit] Shai Erera http://svn.apache.org/viewvc?view=revision&revision=1428324 LUCENE-4647: Simplify CategoryDocumentBuilder > Simplify CategoryDocumentBuilder > > > Key: LUCENE-4647 > URL: https://issues.apache.org/jira/browse/LUCENE-4647 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet >Reporter: Shai Erera >Assignee: Shai Erera > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4647.patch > > > CategoryDocumentBuilder is used to add facet fields to a document. Today the > usage is not so straightforward, and I'd like to simplify it. First, to > improve usage but also to make cutover to DocValues easier. > This clsas does two operations: (1) adds drill-down terms and (2) creates the > fulltree payload. Today, since it does it all on terms, there's a hairy > TokenStream which does both these operations in one go. For simplicity, I'd > like to break this into two steps: > # Write a TokenStream which adds the drill-down terms > #* For no associations, terms should be indexed w/ DOCS_ONLY (see > LUCENE-4623). > #* With associations, drill-down terms have payload too. > #* So EnhancementsDocumentBuilder should be able to extend this stream. > # Write some API which can be used to build the fulltree payload (i.e. > populate a byte[]). Currently that byte[] will be written to a payload and > later to DV. > Hopefully, I'd like to have FacetsDocumentBuilder (maybe just FacetsBuilder?) > which only handles things with no associations, and EnhancementsDocBuilder > which extends whatever is needed to add associations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4290) basic highlighter that uses postings offsets
[ https://issues.apache.org/jira/browse/LUCENE-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544838#comment-13544838 ] Commit Tag Bot commented on LUCENE-4290: [branch_4x commit] Robert Muir http://svn.apache.org/viewvc?view=revision&revision=1428339 LUCENE-4290: use SimpleAnalyzer so we test single-word sentences too > basic highlighter that uses postings offsets > > > Key: LUCENE-4290 > URL: https://issues.apache.org/jira/browse/LUCENE-4290 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/other >Reporter: Robert Muir > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4290.patch > > > We added IndexOptions.DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS so you can > efficiently compress character offsets in the postings list, but nothing yet > makes use of this. > Here is a simple highlighter that uses them: it doesn't have many tests or > fancy features, but I think its ok for the sandbox/ (maybe with a couple more > tests) > Additionally I didnt do any benchmarking. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4608) Handle large number of requested fragments better.
[ https://issues.apache.org/jira/browse/LUCENE-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544837#comment-13544837 ] Commit Tag Bot commented on LUCENE-4608: [branch_4x commit] Martijn van Groningen http://svn.apache.org/viewvc?view=revision&revision=1428340 LUCENE-4608: Moved changes entry to bug fix section > Handle large number of requested fragments better. > -- > > Key: LUCENE-4608 > URL: https://issues.apache.org/jira/browse/LUCENE-4608 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Affects Versions: 4.0 >Reporter: Martijn van Groningen >Assignee: Martijn van Groningen >Priority: Minor > Fix For: 4.1 > > Attachments: LUCENE-4608.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4653) Make TestIndexWriter.testThreadInterruptDeadlock meaner
[ https://issues.apache.org/jira/browse/LUCENE-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544836#comment-13544836 ] Commit Tag Bot commented on LUCENE-4653: [branch_4x commit] Michael McCandless http://svn.apache.org/viewvc?view=revision&revision=1428343 LUCENE-4653: add deletes to TIW.testThreadInterruptDeadlock; fix a few places that didn't handle InterruptedException properly > Make TestIndexWriter.testThreadInterruptDeadlock meaner > --- > > Key: LUCENE-4653 > URL: https://issues.apache.org/jira/browse/LUCENE-4653 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4653.patch, LUCENE-4653.patch > > > Just tweaking the test to also call w.updateDocument (so we sometimes apply > deletes) (Rob's idea) causes all sorts of fun failures ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1972) Need additional query stats in admin interface - median, 95th and 99th percentile
[ https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544835#comment-13544835 ] Commit Tag Bot commented on SOLR-1972: -- [branch_4x commit] Alan Woodward http://svn.apache.org/viewvc?view=revision&revision=1428381 SOLR-1972: Add extra query stats to RequestHandler > Need additional query stats in admin interface - median, 95th and 99th > percentile > - > > Key: SOLR-1972 > URL: https://issues.apache.org/jira/browse/SOLR-1972 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 1.4 >Reporter: Shawn Heisey >Assignee: Alan Woodward >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, > elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, > elyograg-closeable.patch, leak-closeable.patch, leak.patch, > revert-SOLR-1972.patch, SOLR-1972-branch3x-url_pattern.patch, > SOLR-1972-branch4x.patch, SOLR-1972-branch4x.patch, > SOLR-1972_forked-metrics.patch, SOLR-1972_forked-metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, > solr1972-metricsregistry-branch4x-failure.log, SOLR-1972.patch, > SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, > SOLR-1972-url_pattern.patch, stacktraces.tar.gz > > > I would like to see more detailed query statistics from the admin GUI. This > is what you can get now: > requests : 809 > errors : 0 > timeouts : 0 > totalTime : 70053 > avgTimePerRequest : 86.59209 > avgRequestsPerSecond : 0.8148785 > I'd like to see more data on the time per request - median, 95th percentile, > 99th percentile, and any other statistical function that makes sense to > include. In my environment, the first bunch of queries after startup tend to > take several seconds each. I find that the average value tends to be useless > until it has several thousand queries under its belt and the caches are > thoroughly warmed. The statistical functions I have mentioned would quickly > eliminate the influence of those initial slow queries. > The system will have to store individual data about each query. I don't know > if this is something Solr does already. It would be nice to have a > configurable count of how many of the most recent data points are kept, to > control the amount of memory the feature uses. The default value could be > something like 1024 or 4096. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4653) Make TestIndexWriter.testThreadInterruptDeadlock meaner
[ https://issues.apache.org/jira/browse/LUCENE-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544834#comment-13544834 ] Commit Tag Bot commented on LUCENE-4653: [branch_4x commit] Michael McCandless http://svn.apache.org/viewvc?view=revision&revision=1428437 LUCENE-4653: make test more evil; fix leak on exception in IW.getReader > Make TestIndexWriter.testThreadInterruptDeadlock meaner > --- > > Key: LUCENE-4653 > URL: https://issues.apache.org/jira/browse/LUCENE-4653 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4653.patch, LUCENE-4653.patch > > > Just tweaking the test to also call w.updateDocument (so we sometimes apply > deletes) (Rob's idea) causes all sorts of fun failures ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4657) a new testThreadInterruptDeadlock failure
[ https://issues.apache.org/jira/browse/LUCENE-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544833#comment-13544833 ] Commit Tag Bot commented on LUCENE-4657: [branch_4x commit] Robert Muir http://svn.apache.org/viewvc?view=revision&revision=1428553 LUCENE-4657: disable deleteAll in this test until we figure it out > a new testThreadInterruptDeadlock failure > - > > Key: LUCENE-4657 > URL: https://issues.apache.org/jira/browse/LUCENE-4657 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4657_hack.patch, LUCENE-4657.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4657) a new testThreadInterruptDeadlock failure
[ https://issues.apache.org/jira/browse/LUCENE-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544832#comment-13544832 ] Commit Tag Bot commented on LUCENE-4657: [branch_4x commit] Michael McCandless http://svn.apache.org/viewvc?view=revision&revision=1428610 LUCENE-4657: make test evil again; fix more InterruptedException handling cases > a new testThreadInterruptDeadlock failure > - > > Key: LUCENE-4657 > URL: https://issues.apache.org/jira/browse/LUCENE-4657 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4657_hack.patch, LUCENE-4657.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4653) Make TestIndexWriter.testThreadInterruptDeadlock meaner
[ https://issues.apache.org/jira/browse/LUCENE-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544831#comment-13544831 ] Commit Tag Bot commented on LUCENE-4653: [branch_4x commit] Robert Muir http://svn.apache.org/viewvc?view=revision&revision=1428639 LUCENE-4653: toss in a addIndexes > Make TestIndexWriter.testThreadInterruptDeadlock meaner > --- > > Key: LUCENE-4653 > URL: https://issues.apache.org/jira/browse/LUCENE-4653 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4653.patch, LUCENE-4653.patch > > > Just tweaking the test to also call w.updateDocument (so we sometimes apply > deletes) (Rob's idea) causes all sorts of fun failures ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4656) Fix IndexWriter working together with EmptyTokenizer and EmptyTokenStream (without CharTermAttribute), fix BaseTokenStreamTestCase
[ https://issues.apache.org/jira/browse/LUCENE-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544830#comment-13544830 ] Commit Tag Bot commented on LUCENE-4656: [branch_4x commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1428675 Merged revision(s) 1428671 from lucene/dev/trunk: LUCENE-4656: Fix regression in IndexWriter to work with empty TokenStreams that have no TermToBytesRefAttribute (commonly provided by CharTermAttribute), e.g., oal.analysis.miscellaneous.EmptyTokenStream. Remove EmptyTokenizer from test-framework. > Fix IndexWriter working together with EmptyTokenizer and EmptyTokenStream > (without CharTermAttribute), fix BaseTokenStreamTestCase > -- > > Key: LUCENE-4656 > URL: https://issues.apache.org/jira/browse/LUCENE-4656 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Affects Versions: 4.0 >Reporter: Adrien Grand >Assignee: Uwe Schindler >Priority: Trivial > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4656_bttc.patch, LUCENE-4656-IW-bug.patch, > LUCENE-4656-IW-fix.patch, LUCENE-4656-IW-fix.patch, LUCENE-4656.patch, > LUCENE-4656.patch, LUCENE-4656.patch, LUCENE-4656.patch, LUCENE-4656.patch, > LUCENE-4656.patch > > > TestRandomChains can fail because EmptyTokenizer doesn't have a > CharTermAttribute and doesn't compute the end offset (if the offset attribute > was added by a filter). -- 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-4257) Don't wait for ZK connection to apply replay updates or peersync updates
[ https://issues.apache.org/jira/browse/SOLR-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544829#comment-13544829 ] Commit Tag Bot commented on SOLR-4257: -- [branch_4x commit] Yonik Seeley http://svn.apache.org/viewvc?view=revision&revision=1428679 SOLR-4257: PeerSync updates and Log Replay updates should not wait for ZK connection > Don't wait for ZK connection to apply replay updates or peersync updates > > > Key: SOLR-4257 > URL: https://issues.apache.org/jira/browse/SOLR-4257 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4257.patch, SOLR-4257.patch > > > from SOLR-3180, I saw log reply updates blocked on waiting for a ZK > connection. -- 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-4106) Javac/ ivy path warnings with morfologik
[
https://issues.apache.org/jira/browse/SOLR-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544828#comment-13544828
]
Commit Tag Bot commented on SOLR-4106:
--
[branch_4x commit] Dawid Weiss
http://svn.apache.org/viewvc?view=revision&revision=1428824
SOLR-4106: Javac/ ivy path warnings with morfologik fixed by upgrading to
Morfologik 1.5.5
> Javac/ ivy path warnings with morfologik
>
>
> Key: SOLR-4106
> URL: https://issues.apache.org/jira/browse/SOLR-4106
> Project: Solr
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4106.patch, solr4106.zip
>
>
> Does not break the build but brings javac warnings, as pointed out by rmuir:
> {code}
> [javac] warning: [path] bad path element
> "~/.ivy2/cache/org.carrot2/morfologik-polish/jars/morfologik-stemming-1.5.3.jar":
> no such file or directory
>[javac] warning: [path] bad path element
> "~/.ivy2/cache/org.carrot2/morfologik-polish/jars/morfologik-fsa-1.5.3.jar":
> no such file or directory
>[javac] warning: [path] bad path element
> "~/.ivy2/cache/org.carrot2/morfologik-stemming/jars/morfologik-fsa-1.5.3.jar":
> no such file or directory
>[javac] warning: [path] bad path element
> "~/.ivy2/cache/org.carrot2/morfologik-fsa/jars/hppc-0.4.1.jar": no such file
> or directory
> i'm just doing
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4660) When ConcurrentMergeScheduler stalls incoming threads it has unexpected hysteresis
[ https://issues.apache.org/jira/browse/LUCENE-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544827#comment-13544827 ] Commit Tag Bot commented on LUCENE-4660: [branch_4x commit] Michael McCandless http://svn.apache.org/viewvc?view=revision&revision=1428951 LUCENE-4660: add missing notifyAll after merge finishes > When ConcurrentMergeScheduler stalls incoming threads it has unexpected > hysteresis > -- > > Key: LUCENE-4660 > URL: https://issues.apache.org/jira/browse/LUCENE-4660 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4660.patch > > > Eg if you set maxMergeCount to 2, as soon as a 3rd merge need to kick off, we > stall incoming segment-creating threads. Then we wait ... and we are > supposed to resume the threads when the merge count drops back to 2, but > instead we are only resuming when merge count gets to 1. Ie, we stall for > too long (= unexpected hysteresis). -- 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-3180) ChaosMonkey test failures
[ https://issues.apache.org/jira/browse/SOLR-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544826#comment-13544826 ] Commit Tag Bot commented on SOLR-3180: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1429029 SOLR-3180: tests: timeouts from 30 sec to 60 sec > ChaosMonkey test failures > - > > Key: SOLR-3180 > URL: https://issues.apache.org/jira/browse/SOLR-3180 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: 4.1, 5.0 > > Attachments: CMSL_fail1.log, CMSL_hang_2.txt, CMSL_hang.txt, > fail.130101_034142.txt, fail.130102_020942.txt, fail.130103_105104.txt, > fail.130103_193722.txt, fail.inconsistent.txt, test_report_1.txt > > > Handle intermittent failures in the ChaosMonkey tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4662) Elision in FrenchAnalyzer
[ https://issues.apache.org/jira/browse/LUCENE-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544825#comment-13544825 ] Commit Tag Bot commented on LUCENE-4662: [branch_4x commit] Steven Rowe http://svn.apache.org/viewvc?view=revision&revision=1429175 LUCENE-4662: Add missing elided articles and prepositions to FrenchAnalyzer's list passed to ElisionFilter > Elision in FrenchAnalyzer > - > > Key: LUCENE-4662 > URL: https://issues.apache.org/jira/browse/LUCENE-4662 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Affects Versions: 4.0-BETA >Reporter: David L >Assignee: Steve Rowe > Fix For: 4.1 > > Attachments: LUCENE-4662.patch > > > It seems org.apache.lucene.analysis.fr.FrenchAnalyzer.DEFAULT_ARTICLES is > missing "d" and "c", but also "jusqu", "quoiqu", "lorsqu", and "puisqu". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4662) Elision in FrenchAnalyzer
[ https://issues.apache.org/jira/browse/LUCENE-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544824#comment-13544824 ] Commit Tag Bot commented on LUCENE-4662: [branch_4x commit] Steven Rowe http://svn.apache.org/viewvc?view=revision&revision=1429178 LUCENE-4662: CHANGES.txt entry > Elision in FrenchAnalyzer > - > > Key: LUCENE-4662 > URL: https://issues.apache.org/jira/browse/LUCENE-4662 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Affects Versions: 4.0-BETA >Reporter: David L >Assignee: Steve Rowe > Fix For: 4.1 > > Attachments: LUCENE-4662.patch > > > It seems org.apache.lucene.analysis.fr.FrenchAnalyzer.DEFAULT_ARTICLES is > missing "d" and "c", but also "jusqu", "quoiqu", "lorsqu", and "puisqu". -- 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-4121) balanced single quotes cause parse error in (new) standard QParser
[
https://issues.apache.org/jira/browse/SOLR-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544823#comment-13544823
]
Commit Tag Bot commented on SOLR-4121:
--
[branch_4x commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revision&revision=1429183
SOLR-4121: add test for fix
> balanced single quotes cause parse error in (new) standard QParser
> --
>
> Key: SOLR-4121
> URL: https://issues.apache.org/jira/browse/SOLR-4121
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>Priority: Blocker
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4121-test.patch
>
>
> The parser changes introduced in SOLR-4093 cause the standard parser to freak
> out anytime there are blanaced single quotes in a query string.
> the expected behavior is that single quotes should not be considered special
> to the parser, and should be ignored and passed down to the appropriate field
> analyzers
> Example of error...
> http://localhost:8983/solr/select?q=%27zz+xx%27&debugQuery=true
> {noformat}
> Caused by: org.apache.solr.parser.ParseException: Encountered "
> "\'zz xx\' "" at line 1, column 0.
> Was expecting one of:
> ...
> "+" ...
> "-" ...
> ...
> "(" ...
> "*" ...
> ...
> ...
> ...
> ...
> ...
> "[" ...
> "{" ...
> ...
> ...
> ...
> "*" ...
>
> at
> org.apache.solr.parser.QueryParser.generateParseException(QueryParser.java:649)
> at
> org.apache.solr.parser.QueryParser.jj_consume_token(QueryParser.java:531)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:216)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:107)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:96)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:159)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4121) balanced single quotes cause parse error in (new) standard QParser
[
https://issues.apache.org/jira/browse/SOLR-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544822#comment-13544822
]
Commit Tag Bot commented on SOLR-4121:
--
[branch_4x commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revision&revision=1429189
SOLR-4121: add test for fix
> balanced single quotes cause parse error in (new) standard QParser
> --
>
> Key: SOLR-4121
> URL: https://issues.apache.org/jira/browse/SOLR-4121
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>Priority: Blocker
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4121-test.patch
>
>
> The parser changes introduced in SOLR-4093 cause the standard parser to freak
> out anytime there are blanaced single quotes in a query string.
> the expected behavior is that single quotes should not be considered special
> to the parser, and should be ignored and passed down to the appropriate field
> analyzers
> Example of error...
> http://localhost:8983/solr/select?q=%27zz+xx%27&debugQuery=true
> {noformat}
> Caused by: org.apache.solr.parser.ParseException: Encountered "
> "\'zz xx\' "" at line 1, column 0.
> Was expecting one of:
> ...
> "+" ...
> "-" ...
> ...
> "(" ...
> "*" ...
> ...
> ...
> ...
> ...
> ...
> "[" ...
> "{" ...
> ...
> ...
> ...
> "*" ...
>
> at
> org.apache.solr.parser.QueryParser.generateParseException(QueryParser.java:649)
> at
> org.apache.solr.parser.QueryParser.jj_consume_token(QueryParser.java:531)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:216)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:107)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:96)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:159)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4662) Elision in FrenchAnalyzer
[ https://issues.apache.org/jira/browse/LUCENE-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544821#comment-13544821 ] Commit Tag Bot commented on LUCENE-4662: [branch_4x commit] Steven Rowe http://svn.apache.org/viewvc?view=revision&revision=1429193 LUCENE-4662: Add missing elided articles and prepositions to French ElisionFilter list under Solr example > Elision in FrenchAnalyzer > - > > Key: LUCENE-4662 > URL: https://issues.apache.org/jira/browse/LUCENE-4662 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Affects Versions: 4.0-BETA >Reporter: David L >Assignee: Steve Rowe > Fix For: 4.1 > > Attachments: LUCENE-4662.patch > > > It seems org.apache.lucene.analysis.fr.FrenchAnalyzer.DEFAULT_ARTICLES is > missing "d" and "c", but also "jusqu", "quoiqu", "lorsqu", and "puisqu". -- 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-4262) Replication Icon on Dashboard does not reflect Master-/Slave-State
[ https://issues.apache.org/jira/browse/SOLR-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544819#comment-13544819 ] Commit Tag Bot commented on SOLR-4262: -- [branch_4x commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429253 SOLR-4262: Replication Icon on Dashboard does not reflect Master-/Slave-State (merge r1429252) > Replication Icon on Dashboard does not reflect Master-/Slave-State > -- > > Key: SOLR-4262 > URL: https://issues.apache.org/jira/browse/SOLR-4262 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Trivial > Fix For: 4.1 > > Attachments: SOLR-4262.patch > > > On the Core-Dashboard, the Replication Block shows only one (generic) icon .. > originally this should reflect the Master-/Slave-State - like it's already > done in the Title (as Text) -- 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-4262) Replication Icon on Dashboard does not reflect Master-/Slave-State
[ https://issues.apache.org/jira/browse/SOLR-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544820#comment-13544820 ] Commit Tag Bot commented on SOLR-4262: -- [branch_4x commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429249 SOLR-4262: Replication Icon on Dashboard does not reflect Master-/Slave-State (merge r1429248) > Replication Icon on Dashboard does not reflect Master-/Slave-State > -- > > Key: SOLR-4262 > URL: https://issues.apache.org/jira/browse/SOLR-4262 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Trivial > Fix For: 4.1 > > Attachments: SOLR-4262.patch > > > On the Core-Dashboard, the Replication Block shows only one (generic) icon .. > originally this should reflect the Master-/Slave-State - like it's already > done in the Title (as Text) -- 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-4264) Missing Error-Screen on UI's Cloud-Page
[ https://issues.apache.org/jira/browse/SOLR-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544818#comment-13544818 ] Commit Tag Bot commented on SOLR-4264: -- [branch_4x commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429255 SOLR-4264: Missing Error-Screen on UI's Cloud-Page (merge r1429254) > Missing Error-Screen on UI's Cloud-Page > --- > > Key: SOLR-4264 > URL: https://issues.apache.org/jira/browse/SOLR-4264 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Fix For: 4.1 > > Attachments: SOLR-4264.patch > > > If you're running Solr not in "Cloud-Mode" but you're trying to access UI's > Cloud-Page (for whatever reason) the Page stays blank and doesn't provide any > information about what's happening or not -- 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-4261) Percentage Infos on Dashboard have a fixed width
[ https://issues.apache.org/jira/browse/SOLR-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544817#comment-13544817 ] Commit Tag Bot commented on SOLR-4261: -- [branch_4x commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429257 SOLR-4261: Percentage Infos on Dashboard have a fixed width (merge r1429256) > Percentage Infos on Dashboard have a fixed width > > > Key: SOLR-4261 > URL: https://issues.apache.org/jira/browse/SOLR-4261 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Fix For: 4.1 > > Attachments: SOLR-4261.patch > > > The Percentage Graphs on the Dashboard are calculated with a fixed width, > it's calculated once on Pageload, afterwards it stays fixed even if you > resize the Window. All the other elements are flexible .. -- 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-4045) SOLR admin page returns HTTP 404 on core names containing a '.' (dot)
[ https://issues.apache.org/jira/browse/SOLR-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544816#comment-13544816 ] Commit Tag Bot commented on SOLR-4045: -- [branch_4x commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429260 SOLR-4045: SOLR admin page returns HTTP 404 on core names containing a '.' (dot) (merge r1429259) > SOLR admin page returns HTTP 404 on core names containing a '.' (dot) > - > > Key: SOLR-4045 > URL: https://issues.apache.org/jira/browse/SOLR-4045 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.0 > Environment: Linux, Ubuntu 12.04 >Reporter: Alessandro Tommasi >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Labels: admin, solr, webgui > Fix For: 4.1 > > Attachments: SOLR-4045.patch, SOLR-4045.patch > > > When SOLR is configured in multicore mode, cores with '.' (dot) in their > names are inaccessible via the admin web guy. (localhost:8983/solr). The page > shows an alert with the message (test.test was my core name): > 404 Not Found get #/test.test > To replicate: start solr in multicore mode, go to "localhost:8983/solr", via > core admin create a new core "test.test", then refresh the page. "test.test" > will show under the menu at the bottom left. Clicking on it causes the > message, while no core menu appears. -- 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-4176) analysis ui: javascript not properly handling URL decoding of input
[
https://issues.apache.org/jira/browse/SOLR-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544815#comment-13544815
]
Commit Tag Bot commented on SOLR-4176:
--
[branch_4x commit] Stefan Matheis
http://svn.apache.org/viewvc?view=revision&revision=1429262
SOLR-4176: analysis ui: javascript not properly handling URL decoding of input
(merge r1429261)
> analysis ui: javascript not properly handling URL decoding of input
> ---
>
> Key: SOLR-4176
> URL: https://issues.apache.org/jira/browse/SOLR-4176
> Project: Solr
> Issue Type: Bug
> Components: web gui
>Affects Versions: 4.0
>Reporter: Hoss Man
>Assignee: Stefan Matheis (steffkes)
> Fix For: 4.1
>
> Attachments: SOLR-4176.patch
>
>
> attempting to input values containing "%" in the analysis UI causes errors.
> Example of the bug, using the solr example configs...
> 1) load http://localhost:8983/solr/#/collection1/analysis in a browser
> 2) select field type "text_general"
> 3) enter into either text box: {{{foo%bar}}
> 4) click the "Analyze Values" button.
> results...
> * Window location is updated to be:
> http://localhost:8983/solr/#/collection1/analysis?analysis.fieldvalue=foo%25bar&analysis.query=&analysis.fieldtype=text_general&verbose_output=1
> ** Note: "%" has been properly encoded in URL
> * page does not display any analyis, and text areas are now empty (although
> text_general field type is still selected)
> * web dev error console indicates...{noformat}Error: URIError: malformed URI
> sequence
> Source File: http://localhost:8983/solr/js/scripts/analysis.js
> Line: 132
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3851) create a new core/delete an existing core should also update the main/left list of cores
[ https://issues.apache.org/jira/browse/SOLR-3851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13544814#comment-13544814 ] Commit Tag Bot commented on SOLR-3851: -- [branch_4x commit] Stefan Matheis http://svn.apache.org/viewvc?view=revision&revision=1429287 SOLR-3851: create a new core/delete an existing core should also update the main/left list of cores on the admin UI (merge r1429286) > create a new core/delete an existing core should also update the main/left > list of cores > > > Key: SOLR-3851 > URL: https://issues.apache.org/jira/browse/SOLR-3851 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 4.0-BETA >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Fix For: 4.1 > > Attachments: SOLR-3851.patch, SOLR-3851.patch, SOLR-3851.patch > > > While working on SOLR-3788, i realized that the main/left list of cores > needs/should also be updated when a new core is created / an existing core is > deleted, which is right now not the fact. > On a first quick look that should not be that hard, hopefully we can reuse > existing functionality from app.js, which already generates a list of cores > when the UI is initialized. -- 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
