Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b58) - Build # 1917 - Failure!
It's a JVM crash, you can see the hs dump above in the logs (a copy below). It's a bug on my part that this doesn't complete with a more informational exception message though -- I'll take a look and fix for the next release. Dawid [junit4:junit4] >>> JVM J1: stdout (verbatim) [junit4:junit4] # [junit4:junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4:junit4] # [junit4:junit4] # SIGSEGV (0xb) at pc=0x7fd3893f9058, pid=13675, tid=140546309019392 [junit4:junit4] # [junit4:junit4] # JRE version: Java(TM) SE Runtime Environment (8.0-b58) [junit4:junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b02 mixed mode linux-amd64 compressed oops) [junit4:junit4] # Problematic frame: [junit4:junit4] # V [libjvm.so+0x7da058] ParRootScanWithBarrierTwoGensClosure::do_oop(unsigned int*)+0x78 [junit4:junit4] # [junit4:junit4] # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4:junit4] # [junit4:junit4] # An error report file with more information is saved as: [junit4:junit4] # /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/analysis/common/test/J1/hs_err_pid13675.log [junit4:junit4] # [junit4:junit4] # If you would like to submit a bug report, please visit: [junit4:junit4] # http://bugreport.sun.com/bugreport/crash.jsp [junit4:junit4] # [junit4:junit4] <<< JVM J1: EOF - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3973) Cross facet, faceting on multiple columns.
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Comment: was deleted (was: the patch of cross facet.) > Cross facet, faceting on multiple columns. > -- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > Attachments: crossfacet.patch > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross.you can facet on multiple columns, and get > the count result of multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet, faceting on multiple columns.
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481198#comment-13481198 ] ZhengBowen commented on SOLR-3973: -- We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table group by A,B. so, this patch is to surport faceting on multiple columns, and you can get the counts result of multi-faceted cross. i come from alipay in china, we use Solr to build multidimensional analysis platform for mass data. > Cross facet, faceting on multiple columns. > -- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > Attachments: crossfacet.patch > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross.you can facet on multiple columns, and get > the count result of multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet, faceting on multiple columns.
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Comment: was deleted (was: the patche of cross facet.) > Cross facet, faceting on multiple columns. > -- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > Attachments: crossfacet.patch > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross.you can facet on multiple columns, and get > the count result of multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet, faceting on multiple columns.
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Description: We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross.you can facet on multiple columns, and get the count result of multi-faceted cross. Request parameters are as follows： &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, The original effect is as follows: 16852 16787 12950 11667 9997 7624 7082 6894 6528 5822 48621 34634 28748 20389 18508 16852 16787 15227 15112 13793 The effect of the new features are as follows： 16852 16787 12950 11667 9997 7624 7082 6894 6528 was: We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross.you can facet on Request parameters are as follows： &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, The original effect is as follows: 16852 16787 12950 11667 9997 7624 7082 6894 6528 5822 48621 34634 28748 20389 18508 16852 16787 15227 15112 13793 The effect of the new features are as follows： 16852 16787 12950 11667 9997 7624 7082 6894 6528 > Cross facet, faceting on multiple columns. > -- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > Attachments: crossfacet.patch > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross.you can facet on multiple columns, and get > the count result of multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet, faceting on multiple columns.
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Description: We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross.you can facet on Request parameters are as follows： &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, The original effect is as follows: 16852 16787 12950 11667 9997 7624 7082 6894 6528 5822 48621 34634 28748 20389 18508 16852 16787 15227 15112 13793 The effect of the new features are as follows： 16852 16787 12950 11667 9997 7624 7082 6894 6528 was: We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross. Request parameters are as follows： &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, The original effect is as follows: 16852 16787 12950 11667 9997 7624 7082 6894 6528 5822 48621 34634 28748 20389 18508 16852 16787 15227 15112 13793 The effect of the new features are as follows： 16852 16787 12950 11667 9997 7624 7082 6894 6528 > Cross facet, faceting on multiple columns. > -- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > Attachments: crossfacet.patch > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross.you can facet on > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet, faceting on multiple columns.
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Attachment: crossfacet.patch the patche of cross facet. > Cross facet, faceting on multiple columns. > -- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > Attachments: crossfacet.patch > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet, faceting on multiple columns.
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Attachment: (was: crossfacet.patch) > Cross facet, faceting on multiple columns. > -- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet, faceting on multiple columns.
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Summary: Cross facet, faceting on multiple columns. (was: Cross facet, facet on multiple columns.) > Cross facet, faceting on multiple columns. > -- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet, facet on multiple columns.
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Summary: Cross facet, facet on multiple columns. (was: Cross facet) > Cross facet, facet on multiple columns. > --- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > Attachments: crossfacet.patch > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Description: We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross. Request parameters are as follows： &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, The original effect is as follows: 16852 16787 12950 11667 9997 7624 7082 6894 6528 5822 48621 34634 28748 20389 18508 16852 16787 15227 15112 13793 The effect of the new features are as follows： 16852 16787 12950 11667 9997 7624 7082 6894 6528 was: We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table1 group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross. Request parameters are as follows： &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, The original effect is as follows: 16852 16787 12950 11667 9997 7624 7082 6894 6528 5822 48621 34634 28748 20389 18508 16852 16787 15227 15112 13793 The effect of the new features are as follows： 16852 16787 12950 11667 9997 7624 7082 6894 6528 > Cross facet > --- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > Attachments: crossfacet.patch > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Description: We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table1 group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross. Request parameters are as follows： &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, The original effect is as follows: 16852 16787 12950 11667 9997 7624 7082 6894 6528 5822 48621 34634 28748 20389 18508 16852 16787 15227 15112 13793 The effect of the new features are as follows： 16852 16787 12950 11667 9997 7624 7082 6894 6528 was: We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table1 group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross. Request parameters are as follows： &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, The effect of the new features are as follows： 0 84 true true 10.253.93.71:62511/solr,10.253.93.71:62512/solr,10.253.93.71:62513/solr,10.253.93.71:62514/solr, , 0 *:* 10 user_city user_province 0 16852 16787 12950 11667 9997 7624 7082 6894 6528 > Cross facet > --- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > Attachments: crossfacet.patch > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table1 group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The original effect is as follows: > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > 5822 > > > 48621 > 34634 > 28748 > 20389 > 18508 > 16852 > 16787 > 15227 > 15112 > 13793 > > > > > > > The effect of the new features are as follows： > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3963) SOLR: map() does not allow passing recip() sub-functions
[ https://issues.apache.org/jira/browse/SOLR-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481191#comment-13481191 ] Bill Bell commented on SOLR-3963: - Yep. Enhancement request. Bill Bell Sent from mobile > SOLR: map() does not allow passing recip() sub-functions > > > Key: SOLR-3963 > URL: https://issues.apache.org/jira/browse/SOLR-3963 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Bill Bell > > I want to do: > boost=map(achievement_count,1,1000,recip(achievement_count,-.5,10,25),1) > I want to return recip(achievement_count,-.5,10,25) if achievement_count is > between 1 and 1,000. FOr any other values I want to return 1. > I cannot get it to work. I get the error below. Interesting this does work: > boost=recip(map(achievement_count,0,0,-200),-.5,10,25) > It almost appears that map() cannot take a function. > Specified argument was out of the range of valid values. > Parameter name: value > Description: An unhandled exception occurred during the execution of the > current web request. Please review the stack trace for more information about > the error and where it originated in the code. > Exception Details: System.ArgumentOutOfRangeException: Specified argument was > out of the range of valid values. > Parameter name: value > Source Error: > An unhandled exception was generated during the execution of the current web > request. Information regarding the origin and location of the exception can > be identified using the exception stack trace below. > Stack Trace: > [ArgumentOutOfRangeException: Specified argument was out of the range of > valid values. > Parameter name: value] >System.Web.HttpResponse.set_StatusDescription(String value) +5200522 >FacilityService.Controllers.FacilityController.ActionCompleted(String > actionName, IFacilityResults results) +265 > > FacilityService.Controllers.FacilityController.SearchByPointCompleted(IFacilityResults > results) +25 >lambda_method(Closure , ControllerBase , Object[] ) +114 >System.Web.Mvc.Async.<>c__DisplayClass7.b__5(IAsyncResult > asyncResult) +283 > > System.Web.Mvc.Async.<>c__DisplayClass41.b__40(IAsyncResult > asyncResult) +22 > > System.Web.Mvc.Async.<>c__DisplayClass3b.b__35() > +120 > > System.Web.Mvc.Async.<>c__DisplayClass51.b__4b() > +452 > > System.Web.Mvc.Async.<>c__DisplayClass39.b__38(IAsyncResult > asyncResult) +15 >System.Web.Mvc.Async.<>c__DisplayClass2c.b__22() +33 > > System.Web.Mvc.Async.<>c__DisplayClass27.b__24(IAsyncResult > asyncResult) +240 >System.Web.Mvc.<>c__DisplayClass19.b__14(IAsyncResult > asyncResult) +28 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.Mvc.AsyncController.EndExecuteCore(IAsyncResult asyncResult) +63 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.Mvc.<>c__DisplayClassb.b__4(IAsyncResult > asyncResult) +42 > > System.Web.Mvc.Async.<>c__DisplayClass4.b__3(IAsyncResult > ar) +15 >System.Web.CallHandlerExecutionStep.OnAsyncHandlerCompletion(IAsyncResult > ar) +282 -- 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-3973) Cross facet
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Attachment: crossfacet.patch the patch of cross facet. > Cross facet > --- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > Attachments: crossfacet.patch > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table1 group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The effect of the new features are as follows： > > > 0 > 84 > > true > true > > 10.253.93.71:62511/solr,10.253.93.71:62512/solr,10.253.93.71:62513/solr,10.253.93.71:62514/solr, > > , > 0 > *:* > 10 > > user_city > user_province > > 0 > > > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Description: We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table1 group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross. Request parameters are as follows： &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, The effect of the new features are as follows： 0 84 true true 10.253.93.71:62511/solr,10.253.93.71:62512/solr,10.253.93.71:62513/solr,10.253.93.71:62514/solr, , 0 *:* 10 user_city user_province 0 16852 16787 12950 11667 9997 7624 7082 6894 6528 was: We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table1 group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross. The effect of the new features are as follows： 0 84 true true 10.253.93.71:62511/solr,10.253.93.71:62512/solr,10.253.93.71:62513/solr,10.253.93.71:62514/solr, , 0 *:* 10 user_city user_province 0 16852 16787 12950 11667 9997 7624 7082 6894 6528 > Cross facet > --- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table1 group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross. > Request parameters are as follows： > &start=0&rows=0&q=*:*&facet=true&facet.field=user_city&facet.field=user_province&facet.limit=10&facet.cross=true&facet.cross.sep=, > The effect of the new features are as follows： > > > 0 > 84 > > true > true > > 10.253.93.71:62511/solr,10.253.93.71:62512/solr,10.253.93.71:62513/solr,10.253.93.71:62514/solr, > > , > 0 > *:* > 10 > > user_city > user_province > > 0 > > > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet
[ https://issues.apache.org/jira/browse/SOLR-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhengBowen updated SOLR-3973: - Issue Type: Improvement (was: New Feature) > Cross facet > --- > > Key: SOLR-3973 > URL: https://issues.apache.org/jira/browse/SOLR-3973 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 3.5 >Reporter: ZhengBowen > Labels: cross, facet, solr > Fix For: 3.5 > > > We often come across the scene of the multi-faceted cross, For example, the > SQL statement, select count( * ) from table1 group by A,B. > Now we slightly modified for FacetComponent, this component to be able to > support the multi-faceted cross. > The effect of the new features are as follows： > > > 0 > 84 > > true > true > > 10.253.93.71:62511/solr,10.253.93.71:62512/solr,10.253.93.71:62513/solr,10.253.93.71:62514/solr, > > , > 0 > *:* > 10 > > user_city > user_province > > 0 > > > min="Infinity"/> > > > > > 16852 > 16787 > 12950 > 11667 > 9997 > 7624 > 7082 > 6894 > 6528 > > > > > > > -- 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-3973) Cross facet
ZhengBowen created SOLR-3973: Summary: Cross facet Key: SOLR-3973 URL: https://issues.apache.org/jira/browse/SOLR-3973 Project: Solr Issue Type: New Feature Components: SearchComponents - other Affects Versions: 3.5 Reporter: ZhengBowen Fix For: 3.5 We often come across the scene of the multi-faceted cross, For example, the SQL statement, select count( * ) from table1 group by A,B. Now we slightly modified for FacetComponent, this component to be able to support the multi-faceted cross. The effect of the new features are as follows： 0 84 true true 10.253.93.71:62511/solr,10.253.93.71:62512/solr,10.253.93.71:62513/solr,10.253.93.71:62514/solr, , 0 *:* 10 user_city user_province 0 16852 16787 12950 11667 9997 7624 7082 6894 6528 -- 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-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:all-tabpanel ] Shawn Heisey updated SOLR-1972: --- Attachment: SOLR-1972-branch4x.patch New patch against branch_4x. The code hasn't changed, just the example solrconfig.xml. The config is now commented out and says EXPERIMENTAL. No performance impact should occur when the config is not used. The metrics package Alan mentioned looks like a better long-term solution, but in the meantime, we have this. It hasn't received widespread testing, but I've been using a previous version of the patch in 3.x for a very long time (16384 samples on two handlers) with no trouble. Our query volume is low, so we have never noticed any performance impact. It's provided a lot of valuable insight into Solr performance. I think a lot of other people would get value out of this. > 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 >Affects Versions: 1.4 >Reporter: Shawn Heisey >Priority: Minor > Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, > elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, > SOLR-1972-branch3x-url_pattern.patch, SOLR-1972-branch4x.patch, > SOLR-1972-branch4x.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, > SOLR-1972.patch, SOLR-1972-url_pattern.patch > > > 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] [Updated] (LUCENE-4496) Don't decode unnecessary freq blocks in 4.1 codec
[ https://issues.apache.org/jira/browse/LUCENE-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4496: Attachment: LUCENE-4496.patch same trick for .pay blocks when they arent needed. > Don't decode unnecessary freq blocks in 4.1 codec > - > > Key: LUCENE-4496 > URL: https://issues.apache.org/jira/browse/LUCENE-4496 > Project: Lucene - Core > Issue Type: Improvement > Components: core/codecs >Affects Versions: 4.1 >Reporter: Robert Muir > Attachments: LUCENE-4496.patch, LUCENE-4496.patch > > > TermsEnum.docs() has an expert flag to specify you don't require frequencies. > This is currently set by some things that don't need it: we should call > ForUtil.skipBlock instead of ForUtil.readBlock in this case. -- 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] (LUCENE-4496) Don't decode unnecessary freq blocks in 4.1 codec
[ https://issues.apache.org/jira/browse/LUCENE-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4496: Attachment: LUCENE-4496.patch All tests pass, not sure I trust they really test this case well or even how much it helps, but its a simple fix. > Don't decode unnecessary freq blocks in 4.1 codec > - > > Key: LUCENE-4496 > URL: https://issues.apache.org/jira/browse/LUCENE-4496 > Project: Lucene - Core > Issue Type: Improvement > Components: core/codecs >Affects Versions: 4.1 >Reporter: Robert Muir > Attachments: LUCENE-4496.patch > > > TermsEnum.docs() has an expert flag to specify you don't require frequencies. > This is currently set by some things that don't need it: we should call > ForUtil.skipBlock instead of ForUtil.readBlock in this case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4496) Don't decode unnecessary freq blocks in 4.1 codec
Robert Muir created LUCENE-4496: --- Summary: Don't decode unnecessary freq blocks in 4.1 codec Key: LUCENE-4496 URL: https://issues.apache.org/jira/browse/LUCENE-4496 Project: Lucene - Core Issue Type: Improvement Components: core/codecs Affects Versions: 4.1 Reporter: Robert Muir TermsEnum.docs() has an expert flag to specify you don't require frequencies. This is currently set by some things that don't need it: we should call ForUtil.skipBlock instead of ForUtil.readBlock in this case. -- 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
Lucene build & ivy problems
If I have all of the dependencies downloaded, how can I tell the build to skip checking the repositories? I'm working on a somewhat dodgy internet connection. I ran 'ant example' a hundred times. On the 101st, I had an internet outage and the Ivy stuff blocked. Ever after that the resolver hangs. I had to remove the home/.ivy2 directory and start over. And now all of the dependencies are slowly downloading again over a dodgy internet cafe connection. Is there some flag to the ant build that says "just pretend everything is downloaded"?
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b58) - Build # 1917 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/1917/ Java: 64bit/jdk1.8.0-ea-b58 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 4816 lines...] [junit4:junit4] ERROR: JVM J1 ended with an exception, command line: /mnt/ssd/jenkins/tools/java/64bit/jdk1.8.0-ea-b58/jre/bin/java -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/heapdumps -Dtests.prefix=tests -Dtests.seed=95A43BC92E34ADC8 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.lockdir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build -Dtests.codec=random -Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. -Djava.io.tmpdir=. -Dtests.sandbox.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/analysis/common -Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/tests.policy -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Dfile.encoding=ISO-8859-1 -classpath /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/analysis/common/classes/test:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/junit-4.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.3.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/analysis/common/classes/java:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.2.0.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-jdepend.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-netrexx.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-antlr.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-commons-net.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-regexp.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-jsch.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-junit4.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-junit.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-bcel.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-swing.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-bsf.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-log4j.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-testutil.jar:/mnt/ssd/jenkins/tools/java/64bit/jdk1.8.0-ea-b58/lib/tools.jar:/var/lib/jenkins/.ivy2/cache/com.carrotsearch.randomizedtesting/junit4-ant/jars/junit4-ant-2.0.3.jar -ea:org.apache.lucene... -ea:org.apache.solr... com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe -eventsfile /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/analysis/common/test/junit4-J1-20121022_024025_927.events @/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/analysis/common/test/junit4-J1-20121022_024025_927.suites [junit4:junit4] ERROR: JVM J1 ended with an exception: Forked process exited with an error code: 134 [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4.forkProcess(JUnit4.java:1312) [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4.executeSlave(JUnit4.java:1178) [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4.access$000(JUnit4.java:65) [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4$2.call(JUnit4.java:813) [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4$2.call(JUnit4.java:810) [junit4:junit4] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [junit4:junit4] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
[jira] [Commented] (LUCENE-4476) maven deployment scripts dont work (except from the machine you made the RC from)
[
https://issues.apache.org/jira/browse/LUCENE-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481129#comment-13481129
]
Steven Rowe commented on LUCENE-4476:
-
bq. Does this also happen on windows if you sign artifacts with your GPG key?
Yes.
bq. We should do the same here if this is also the case on windows (IF USING
WINDOWS...) and also add this warning back to our current codebase for gpg
signing too!
+1
bq. updated patch with my suggested improvements.
+1
> maven deployment scripts dont work (except from the machine you made the RC
> from)
> -
>
> Key: LUCENE-4476
> URL: https://issues.apache.org/jira/browse/LUCENE-4476
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-4476.patch, LUCENE-4476.patch, LUCENE-4476.patch
>
>
> Currently the maven process described in
> http://wiki.apache.org/lucene-java/PublishMavenArtifacts does not work (on
> mac)
> It worked fine for the 4.0-alpha and 4.0-beta releases.
> NOTE: This appears to be working on linux so I am going with that. But this
> seems strange it doesnt work on mac.
>
> {noformat}
> artifact:install-provider] Installing provider:
> org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-7:runtime
> [artifact:pom] Downloading:
> org/apache/lucene/lucene-parent/4.0.0/lucene-parent-4.0.0.pom from repository
> sonatype.releases at http://oss.sonatype.org/content/repositories/releases
> [artifact:pom] Unable to locate resource in repository
> [artifact:pom] [INFO] Unable to find resource
> 'org.apache.lucene:lucene-parent:pom:4.0.0' in repository sonatype.releases
> (http://oss.sonatype.org/content/repositories/releases)
> [artifact:pom] Downloading:
> org/apache/lucene/lucene-parent/4.0.0/lucene-parent-4.0.0.pom from repository
> central at http://repo1.maven.org/maven2
> [artifact:pom] Unable to locate resource in repository
> [artifact:pom] [INFO] Unable to find resource
> 'org.apache.lucene:lucene-parent:pom:4.0.0' in repository central
> (http://repo1.maven.org/maven2)
> [artifact:pom] An error has occurred while processing the Maven artifact
> tasks.
> [artifact:pom] Diagnosis:
> [artifact:pom]
> [artifact:pom] Unable to initialize POM lucene-test-framework-4.0.0.pom:
> Cannot find parent: org.apache.lucene:lucene-parent for project:
> org.apache.lucene:lucene-test-framework:jar:null for project
> org.apache.lucene:lucene-test-framework:jar:null
> [artifact:pom] Unable to download the artifact from any repository
> BUILD FAILED
> {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] [Updated] (LUCENE-4476) maven deployment scripts dont work (except from the machine you made the RC from)
[
https://issues.apache.org/jira/browse/LUCENE-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-4476:
Attachment: LUCENE-4476.patch
updated patch with my suggested improvements.
> maven deployment scripts dont work (except from the machine you made the RC
> from)
> -
>
> Key: LUCENE-4476
> URL: https://issues.apache.org/jira/browse/LUCENE-4476
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-4476.patch, LUCENE-4476.patch, LUCENE-4476.patch
>
>
> Currently the maven process described in
> http://wiki.apache.org/lucene-java/PublishMavenArtifacts does not work (on
> mac)
> It worked fine for the 4.0-alpha and 4.0-beta releases.
> NOTE: This appears to be working on linux so I am going with that. But this
> seems strange it doesnt work on mac.
>
> {noformat}
> artifact:install-provider] Installing provider:
> org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-7:runtime
> [artifact:pom] Downloading:
> org/apache/lucene/lucene-parent/4.0.0/lucene-parent-4.0.0.pom from repository
> sonatype.releases at http://oss.sonatype.org/content/repositories/releases
> [artifact:pom] Unable to locate resource in repository
> [artifact:pom] [INFO] Unable to find resource
> 'org.apache.lucene:lucene-parent:pom:4.0.0' in repository sonatype.releases
> (http://oss.sonatype.org/content/repositories/releases)
> [artifact:pom] Downloading:
> org/apache/lucene/lucene-parent/4.0.0/lucene-parent-4.0.0.pom from repository
> central at http://repo1.maven.org/maven2
> [artifact:pom] Unable to locate resource in repository
> [artifact:pom] [INFO] Unable to find resource
> 'org.apache.lucene:lucene-parent:pom:4.0.0' in repository central
> (http://repo1.maven.org/maven2)
> [artifact:pom] An error has occurred while processing the Maven artifact
> tasks.
> [artifact:pom] Diagnosis:
> [artifact:pom]
> [artifact:pom] Unable to initialize POM lucene-test-framework-4.0.0.pom:
> Cannot find parent: org.apache.lucene:lucene-parent for project:
> org.apache.lucene:lucene-test-framework:jar:null for project
> org.apache.lucene:lucene-test-framework:jar:null
> [artifact:pom] Unable to download the artifact from any repository
> BUILD FAILED
> {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-4476) maven deployment scripts dont work (except from the machine you made the RC from)
[
https://issues.apache.org/jira/browse/LUCENE-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481109#comment-13481109
]
Robert Muir commented on LUCENE-4476:
-
Seems to work! I nuked .m2 completely before running.
It succeeded and I checked repository.apache.org. Thank you!
A few minor nits below:
Correct, there was no echoing of password on linux! Though, I'm still concerned
here.
Does this also happen on windows if you sign artifacts with your GPG key?
For the 3.6 releases I added the following to sign-artifacts-macro:
{noformat}
WARNING: IF USING JAVA5 YOUR PASSPHRASE WILL BE ECHOED BACK!
{noformat}
We should do the same here if this is also the case on windows (IF USING
WINDOWS...)
and also add this warning back to our current codebase for gpg signing too!
This is really not
a problem except when you dont expect it and people are looking over your
shoulder,
then it can be a HUGE hassle.
one minor thing i ran into was that line 1381 redirects output so if it fails
you dont know why... this happens e.g. if the
directory is typoed or something.
{noformat}
-Dmaven.dist.dir=~/rc2/lucene
Buildfile: /home/rmuir/workspace/lucene-trunk/lucene/build.xml
clean:
stage-maven-artifacts:
BUILD FAILED
/home/rmuir/workspace/lucene-trunk/lucene/common-build.xml:1381: exec returned:
2
Total time: 0 seconds
{noformat}
I know its redirecting output, just didnt know if there was some simple way
instead of
failOnError=true if we could instead fail on a property with the captured
output?
> maven deployment scripts dont work (except from the machine you made the RC
> from)
> -
>
> Key: LUCENE-4476
> URL: https://issues.apache.org/jira/browse/LUCENE-4476
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-4476.patch, LUCENE-4476.patch
>
>
> Currently the maven process described in
> http://wiki.apache.org/lucene-java/PublishMavenArtifacts does not work (on
> mac)
> It worked fine for the 4.0-alpha and 4.0-beta releases.
> NOTE: This appears to be working on linux so I am going with that. But this
> seems strange it doesnt work on mac.
>
> {noformat}
> artifact:install-provider] Installing provider:
> org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-7:runtime
> [artifact:pom] Downloading:
> org/apache/lucene/lucene-parent/4.0.0/lucene-parent-4.0.0.pom from repository
> sonatype.releases at http://oss.sonatype.org/content/repositories/releases
> [artifact:pom] Unable to locate resource in repository
> [artifact:pom] [INFO] Unable to find resource
> 'org.apache.lucene:lucene-parent:pom:4.0.0' in repository sonatype.releases
> (http://oss.sonatype.org/content/repositories/releases)
> [artifact:pom] Downloading:
> org/apache/lucene/lucene-parent/4.0.0/lucene-parent-4.0.0.pom from repository
> central at http://repo1.maven.org/maven2
> [artifact:pom] Unable to locate resource in repository
> [artifact:pom] [INFO] Unable to find resource
> 'org.apache.lucene:lucene-parent:pom:4.0.0' in repository central
> (http://repo1.maven.org/maven2)
> [artifact:pom] An error has occurred while processing the Maven artifact
> tasks.
> [artifact:pom] Diagnosis:
> [artifact:pom]
> [artifact:pom] Unable to initialize POM lucene-test-framework-4.0.0.pom:
> Cannot find parent: org.apache.lucene:lucene-parent for project:
> org.apache.lucene:lucene-test-framework:jar:null for project
> org.apache.lucene:lucene-test-framework:jar:null
> [artifact:pom] Unable to download the artifact from any repository
> BUILD FAILED
> {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] [Updated] (LUCENE-4476) maven deployment scripts dont work (except from the machine you made the RC from)
[
https://issues.apache.org/jira/browse/LUCENE-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-4476:
Attachment: LUCENE-4476.patch
{quote}
I think the next thing to try is to explicitly point to all parent POMs via
{{}}.
{quote}
This patch takes the parent POMs {{}} approach, and works for me.
I think this is ready to go. Robert, can you give it a try?
FYI, the secure input handler on Win7+Cygwin echos the password to the console
instead of hiding it - apparently this is a known issue. Robert, if you give
it a try on a non-Windows OS, can you confirm that the password is not echoed?
{quote}
So if you nest the artifact:pom with the exact location, the deploy target
doesnt use localRepository?
Or does maybe it need both?
{quote}
AFAICT, the deploy target ignores localRepository entirely - my guess is that,
regardless of maven-ant-tasks documentation, only the install target actually
respects a specified localRepository.
> maven deployment scripts dont work (except from the machine you made the RC
> from)
> -
>
> Key: LUCENE-4476
> URL: https://issues.apache.org/jira/browse/LUCENE-4476
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-4476.patch, LUCENE-4476.patch
>
>
> Currently the maven process described in
> http://wiki.apache.org/lucene-java/PublishMavenArtifacts does not work (on
> mac)
> It worked fine for the 4.0-alpha and 4.0-beta releases.
> NOTE: This appears to be working on linux so I am going with that. But this
> seems strange it doesnt work on mac.
>
> {noformat}
> artifact:install-provider] Installing provider:
> org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-7:runtime
> [artifact:pom] Downloading:
> org/apache/lucene/lucene-parent/4.0.0/lucene-parent-4.0.0.pom from repository
> sonatype.releases at http://oss.sonatype.org/content/repositories/releases
> [artifact:pom] Unable to locate resource in repository
> [artifact:pom] [INFO] Unable to find resource
> 'org.apache.lucene:lucene-parent:pom:4.0.0' in repository sonatype.releases
> (http://oss.sonatype.org/content/repositories/releases)
> [artifact:pom] Downloading:
> org/apache/lucene/lucene-parent/4.0.0/lucene-parent-4.0.0.pom from repository
> central at http://repo1.maven.org/maven2
> [artifact:pom] Unable to locate resource in repository
> [artifact:pom] [INFO] Unable to find resource
> 'org.apache.lucene:lucene-parent:pom:4.0.0' in repository central
> (http://repo1.maven.org/maven2)
> [artifact:pom] An error has occurred while processing the Maven artifact
> tasks.
> [artifact:pom] Diagnosis:
> [artifact:pom]
> [artifact:pom] Unable to initialize POM lucene-test-framework-4.0.0.pom:
> Cannot find parent: org.apache.lucene:lucene-parent for project:
> org.apache.lucene:lucene-test-framework:jar:null for project
> org.apache.lucene:lucene-test-framework:jar:null
> [artifact:pom] Unable to download the artifact from any repository
> BUILD FAILED
> {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-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=13481079#comment-13481079 ] Alan Woodward commented on SOLR-1972: - > and it would bloat the .war somewhat metrics-core is only 81kb :-) And its only dependency is slf4j-api, which is already included. I think this might be an easy win, actually. Replacing the requests, errors and timeouts counts with Counters, and adding a TimerContext reproduces all the existing stats and gives you the histogram of request times. Plus it's extensible, as you say. > 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 >Affects Versions: 1.4 >Reporter: Shawn Heisey >Priority: Minor > Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, > elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, > SOLR-1972-branch3x-url_pattern.patch, SOLR-1972-branch4x.patch, > SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, > SOLR-1972-url_pattern.patch > > > 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] [Updated] (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:all-tabpanel ] Shawn Heisey updated SOLR-1972: --- Attachment: SOLR-1972-branch4x.patch An updated patch against branch_4x. I massaged the solrconfig.xml options a bit trying to make them a bit easier to understand. I also fixed all the statistics reporting glitches I could find. > 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 >Affects Versions: 1.4 >Reporter: Shawn Heisey >Priority: Minor > Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, > elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, > SOLR-1972-branch3x-url_pattern.patch, SOLR-1972-branch4x.patch, > SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, > SOLR-1972-url_pattern.patch > > > 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] (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=13481058#comment-13481058 ] Shawn Heisey commented on SOLR-1972: bq. I wonder if Coda Hale's Metrics library might be worth using here? That does look really interesting. Perhaps a bit above my skill set, and it would bloat the .war somewhat. It would provide the opportunity to record metrics all over the place, not just the things we originally cooked up here. In the meantime, I have updated the current patch to branch_4x. > 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 >Affects Versions: 1.4 >Reporter: Shawn Heisey >Priority: Minor > Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, > elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, > SOLR-1972-branch3x-url_pattern.patch, SOLR-1972.patch, SOLR-1972.patch, > SOLR-1972.patch, SOLR-1972.patch, SOLR-1972-url_pattern.patch > > > 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] [Updated] (SOLR-2052) Allow for a list of filter queries and a single docset filter in QueryComponent
[ https://issues.apache.org/jira/browse/SOLR-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Daubman updated SOLR-2052: Attachment: SOLR-2052-3-6-1.patch Attaching the patch updated for 3.6.1 > Allow for a list of filter queries and a single docset filter in > QueryComponent > --- > > Key: SOLR-2052 > URL: https://issues.apache.org/jira/browse/SOLR-2052 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 4.0-ALPHA > Environment: Mac OS X, Java 1.6 >Reporter: Stephen Green >Priority: Minor > Fix For: 4.1 > > Attachments: SOLR-2052-2.patch, SOLR-2052-3-6-1.patch, > SOLR-2052-3.patch, SOLR-2052-4.patch, SOLR-2052.patch > > > SolrIndexSearcher.QueryCommand allows you to specify a list of filter queries > or a single filter (as a DocSet), but not both. This restriction seems > arbitrary, and there are cases where we can have both a list of filter > queries and a DocSet generated by some other non-query process (e.g., > filtering documents according to IDs pulled from some other source like a > database.) > Fixing this requires a few small changes to SolrIndexSearcher to allow both > of these to be set for a QueryCommand and to take both into account when > evaluating the query. It also requires a modification to ResponseBuilder to > allow setting the single filter at query time. > I've run into this against 1.4, but the same holds true for the trunk. -- 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-3939) Solr Cloud recovery and leader election when unloading leader core
[ https://issues.apache.org/jira/browse/SOLR-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481008#comment-13481008 ] Yonik Seeley commented on SOLR-3939: Actually, even if we someday replicate recent versions along with the index (by adding them to the commitData in the index, etc), it may still be good to support indexes w/o version info. On the other side of the spectrum from having indexing completely automated, some people may want the ability to create a new shard off-line and then insert it into the cluster as read-only. > Solr Cloud recovery and leader election when unloading leader core > -- > > Key: SOLR-3939 > URL: https://issues.apache.org/jira/browse/SOLR-3939 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0-BETA, 4.0 >Reporter: Joel Bernstein >Assignee: Mark Miller >Priority: Critical > Labels: 4.0.1_Candidate > Fix For: 4.1, 5.0 > > Attachments: cloud2.log, cloud.log, SOLR-3939.patch, SOLR-3939.patch > > > When a leader core is unloaded using the core admin api, the followers in the > shard go into recovery but do not come out. Leader election doesn't take > place and the shard goes down. > This effects the ability to move a micro-shard from one Solr instance to > another Solr instance. > The problem does not occur 100% of the time but a large % of the time. > To setup a test, startup Solr Cloud with a single shard. Add cores to that > shard as replicas using core admin. Then unload the leader core using core > admin. -- 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] (LUCENE-4481) AnalyzingSuggester may fail to return correct topN suggestions
[ https://issues.apache.org/jira/browse/LUCENE-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-4481. Resolution: Fixed > AnalyzingSuggester may fail to return correct topN suggestions > -- > > Key: LUCENE-4481 > URL: https://issues.apache.org/jira/browse/LUCENE-4481 > Project: Lucene - Core > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.1, 5.0 > > Attachments: LUCENE-4481.patch, LUCENE-4481.patch, LUCENE-4481.patch, > LUCENE-4481.patch, LUCENE-4481.patch > > > I hit this when working on LUCENE-4480. > Because AnalyzingSuggester may prune some of the topN paths found by FST's > Util.TopNSearcher, this means the queue size limit of topN makes the overall > search inadmissible, ie it may incorrectly prune paths that would have lead > to a competitive path. > However, such pruning is rare: it happens only for graph token streams, and > even then only when competitive analyzed forms share the same surface forms. > The simplest way to fix this is to make the queue unbounded but this is > likely a sizable performance hit ... I haven't tested yet. It's even > possible the way the dups happen (always at the "end" of the suggestion, > because we tack on 0 byte followed by ord dedup byte) prevent this bug from > even occurring and so this could all be a false alarm! I have to try to make > a test case showing it ... > A cop-out solution would be to expose a separate queueSize or queueMultiplier > (over the topN) so that if users are affected by this they could crank up the > queue size or multiplier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 1896 - Still Failing!
Hi,
OK, fixed by installing the unlimited strength patch. It is not good that IBM
does not provide a download with unlimited strength of the whole JDK like
Oracle does (Oracle in fact no longer has limited strength versions).
Mike, Shai - can you ask why this is the case? Oracle no longer offers the
limited strength JDKs anymore, so this seems to be a relic from older times.
Unfortunately, Apache's JIRA uses a 4096 bit signature, which is quite uncommon
on the web... (the signer companies like Thawte suggest to use 2048 bit
only...) - Not even extended security certificates like those from banks use
4096 bits!
I also updated to newest J9 bugfix versions.
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Sunday, October 21, 2012 12:32 PM
> To: dev@lucene.apache.org
> Subject: RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build #
> 1896 - Still Failing!
>
> I am now installing the updates for J9 (there is already update 2 available
> for
> Java 7 and update 11 for Java 6, both one more than currently installed),
> maybe the FST.pack() failure is gone.
>
> I will also install
> https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=
> jcesdk for all 4 installations of IBM J9.
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > Sent: Sunday, October 21, 2012 12:13 PM
> > To: dev@lucene.apache.org
> > Subject: RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) -
> > Build #
> > 1896 - Still Failing!
> >
> > See:
> > http://stackoverflow.com/questions/6481627/java-security-illegal-key-
> > size-or-default-parameters
> >
> > It seems that this IBM JDK does not have unlimited strength... I'll dig.
> > This error did not happen before, because I did not build docs on J9,
> > no I
> > *only* don't lint it, but still build it.
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Robert Muir [mailto:rm...@apache.org]
> > > Sent: Sunday, October 21, 2012 5:35 AM
> > > To: dev@lucene.apache.org
> > > Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) -
> > > Build #
> > > 1896 - Still Failing!
> > >
> > > Does anyone know what is causing these SSL failures when retrieving
> > > the JIRA stuff for changes-to-html?
> > >
> > > I tried the obvious workaround (changing it to just use http) but it
> > > forwards to https anyway.
> > > And it doesnt fail on my machine in any case
> > >
> > > changes-to-html:
> > > [get] Getting:
> http://issues.apache.org/jira/rest/api/2/project/LUCENE
> > > [get] To:
> > > /home/rmuir/workspace/lucene-
> > > trunk/lucene/build/docs/changes/jiraVersionList.json
> > > [get] http://issues.apache.org/jira/rest/api/2/project/LUCENE
> > > moved to https://issues.apache.org/jira/rest/api/2/project/LUCENE
> > >[delete] Deleting:
> > > /home/rmuir/workspace/lucene-
> > > trunk/lucene/build/docs/changes/jiraVersionList.json
> > >
> > > BUILD SUCCESSFUL
> > > Total time: 3 seconds
> > >
> > >
> > > On Sat, Oct 20, 2012 at 11:27 PM, Policeman Jenkins Server
> > > wrote:
> > > > Build:
> > > > http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/189
> > > > 6/
> > > > Java: 32bit/ibm-j9-jdk7
> > > > -Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache
> > > > /l
> > > > uc
> > > > ene/util/fst/FST;}
> > > >
> > > > All tests passed
> > > >
> > > > Build Log:
> > > > [...truncated 24172 lines...]
> > > > BUILD FAILED
> > > > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60:
> > > > The
> > > following error occurred while executing this line:
> > > > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-
> > > Linux/lucene/build.xml:517: The following error occurred while
> > > executing this
> > > line:
> > > > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/common-
> > > build.xml:1937: javax.net.ssl.SSLKeyException: RSA premaster secret
> > > error
> > > > at com.ibm.jsse2.z.(z.java:32)
> > > > at com.ibm.jsse2.bb.a(bb.java:233)
> > > > at com.ibm.jsse2.bb.a(bb.java:113)
> > > > at com.ibm.jsse2.ab.r(ab.java:75)
> > > > at com.ibm.jsse2.ab.a(ab.java:532)
> > > > at com.ibm.jsse2.qc.a(qc.java:158)
> > > > at com.ibm.jsse2.qc.h(qc.java:272)
> > > > at com.ibm.jsse2.qc.a(qc.java:234)
> > > > at com.ibm.jsse2.qc.startHandshake(qc.java:8)
> > > > at
> > > > com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:111)
> > > > at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:18)
> > > > at com.ibm.net.ssl.www2.protocol.https.b.connect(b.java:28)
> > >
RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 1896 - Still Failing!
I am now installing the updates for J9 (there is already update 2 available for
Java 7 and update 11 for Java 6, both one more than currently installed), maybe
the FST.pack() failure is gone.
I will also install
https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk for all
4 installations of IBM J9.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Sunday, October 21, 2012 12:13 PM
> To: dev@lucene.apache.org
> Subject: RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build #
> 1896 - Still Failing!
>
> See: http://stackoverflow.com/questions/6481627/java-security-illegal-key-
> size-or-default-parameters
>
> It seems that this IBM JDK does not have unlimited strength... I'll dig.
> This error did not happen before, because I did not build docs on J9, no I
> *only* don't lint it, but still build it.
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Robert Muir [mailto:rm...@apache.org]
> > Sent: Sunday, October 21, 2012 5:35 AM
> > To: dev@lucene.apache.org
> > Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) -
> > Build #
> > 1896 - Still Failing!
> >
> > Does anyone know what is causing these SSL failures when retrieving
> > the JIRA stuff for changes-to-html?
> >
> > I tried the obvious workaround (changing it to just use http) but it
> > forwards to https anyway.
> > And it doesnt fail on my machine in any case
> >
> > changes-to-html:
> > [get] Getting: http://issues.apache.org/jira/rest/api/2/project/LUCENE
> > [get] To:
> > /home/rmuir/workspace/lucene-
> > trunk/lucene/build/docs/changes/jiraVersionList.json
> > [get] http://issues.apache.org/jira/rest/api/2/project/LUCENE
> > moved to https://issues.apache.org/jira/rest/api/2/project/LUCENE
> >[delete] Deleting:
> > /home/rmuir/workspace/lucene-
> > trunk/lucene/build/docs/changes/jiraVersionList.json
> >
> > BUILD SUCCESSFUL
> > Total time: 3 seconds
> >
> >
> > On Sat, Oct 20, 2012 at 11:27 PM, Policeman Jenkins Server
> > wrote:
> > > Build:
> > > http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/1896/
> > > Java: 32bit/ibm-j9-jdk7
> > > -Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/l
> > > uc
> > > ene/util/fst/FST;}
> > >
> > > All tests passed
> > >
> > > Build Log:
> > > [...truncated 24172 lines...]
> > > BUILD FAILED
> > > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The
> > following error occurred while executing this line:
> > > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-
> > Linux/lucene/build.xml:517: The following error occurred while
> > executing this
> > line:
> > > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-
> > build.xml:1937: javax.net.ssl.SSLKeyException: RSA premaster secret
> > error
> > > at com.ibm.jsse2.z.(z.java:32)
> > > at com.ibm.jsse2.bb.a(bb.java:233)
> > > at com.ibm.jsse2.bb.a(bb.java:113)
> > > at com.ibm.jsse2.ab.r(ab.java:75)
> > > at com.ibm.jsse2.ab.a(ab.java:532)
> > > at com.ibm.jsse2.qc.a(qc.java:158)
> > > at com.ibm.jsse2.qc.h(qc.java:272)
> > > at com.ibm.jsse2.qc.a(qc.java:234)
> > > at com.ibm.jsse2.qc.startHandshake(qc.java:8)
> > > at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:111)
> > > at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:18)
> > > at com.ibm.net.ssl.www2.protocol.https.b.connect(b.java:28)
> > > at
> >
> org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:66
> > 0
> > )
> > > at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579)
> > > at
> > > org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569)
> > > Caused by: java.security.InvalidKeyException: Illegal key size or
> > > default
> > parameters
> > > at javax.crypto.Cipher.a(Unknown Source)
> > > at javax.crypto.Cipher.a(Unknown Source)
> > > at javax.crypto.Cipher.a(Unknown Source)
> > > at javax.crypto.Cipher.init(Unknown Source)
> > > at com.ibm.jsse2.z.(z.java:12)
> > > ... 14 more
> > >
> > > Total time: 29 minutes 58 seconds
> > > Build step 'Invoke Ant' marked build as failure Archiving artifacts
> > > Recording test results Description set: Java: 32bit/ibm-j9-jdk7
> > > -Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/l
> > > uc
> > > ene/util/fst/FST;}
> > > Email was triggered for: Failure
> > > Sending email for trigger: Failure
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 1896 - Still Failing!
See:
http://stackoverflow.com/questions/6481627/java-security-illegal-key-size-or-default-parameters
It seems that this IBM JDK does not have unlimited strength... I'll dig.
This error did not happen before, because I did not build docs on J9, no I
*only* don't lint it, but still build it.
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Robert Muir [mailto:rm...@apache.org]
> Sent: Sunday, October 21, 2012 5:35 AM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build #
> 1896 - Still Failing!
>
> Does anyone know what is causing these SSL failures when retrieving the
> JIRA stuff for changes-to-html?
>
> I tried the obvious workaround (changing it to just use http) but it forwards
> to https anyway.
> And it doesnt fail on my machine in any case
>
> changes-to-html:
> [get] Getting: http://issues.apache.org/jira/rest/api/2/project/LUCENE
> [get] To:
> /home/rmuir/workspace/lucene-
> trunk/lucene/build/docs/changes/jiraVersionList.json
> [get] http://issues.apache.org/jira/rest/api/2/project/LUCENE
> moved to https://issues.apache.org/jira/rest/api/2/project/LUCENE
>[delete] Deleting:
> /home/rmuir/workspace/lucene-
> trunk/lucene/build/docs/changes/jiraVersionList.json
>
> BUILD SUCCESSFUL
> Total time: 3 seconds
>
>
> On Sat, Oct 20, 2012 at 11:27 PM, Policeman Jenkins Server datasolutions.de> wrote:
> > Build:
> > http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/1896/
> > Java: 32bit/ibm-j9-jdk7
> > -Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/luc
> > ene/util/fst/FST;}
> >
> > All tests passed
> >
> > Build Log:
> > [...truncated 24172 lines...]
> > BUILD FAILED
> > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The
> following error occurred while executing this line:
> > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-
> Linux/lucene/build.xml:517: The following error occurred while executing this
> line:
> > /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-
> build.xml:1937: javax.net.ssl.SSLKeyException: RSA premaster secret error
> > at com.ibm.jsse2.z.(z.java:32)
> > at com.ibm.jsse2.bb.a(bb.java:233)
> > at com.ibm.jsse2.bb.a(bb.java:113)
> > at com.ibm.jsse2.ab.r(ab.java:75)
> > at com.ibm.jsse2.ab.a(ab.java:532)
> > at com.ibm.jsse2.qc.a(qc.java:158)
> > at com.ibm.jsse2.qc.h(qc.java:272)
> > at com.ibm.jsse2.qc.a(qc.java:234)
> > at com.ibm.jsse2.qc.startHandshake(qc.java:8)
> > at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:111)
> > at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:18)
> > at com.ibm.net.ssl.www2.protocol.https.b.connect(b.java:28)
> > at
> org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660
> )
> > at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579)
> > at
> > org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569)
> > Caused by: java.security.InvalidKeyException: Illegal key size or default
> parameters
> > at javax.crypto.Cipher.a(Unknown Source)
> > at javax.crypto.Cipher.a(Unknown Source)
> > at javax.crypto.Cipher.a(Unknown Source)
> > at javax.crypto.Cipher.init(Unknown Source)
> > at com.ibm.jsse2.z.(z.java:12)
> > ... 14 more
> >
> > Total time: 29 minutes 58 seconds
> > Build step 'Invoke Ant' marked build as failure Archiving artifacts
> > Recording test results Description set: Java: 32bit/ibm-j9-jdk7
> > -Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/luc
> > ene/util/fst/FST;}
> > Email was triggered for: Failure
> > Sending email for trigger: Failure
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
