date:20130227

Alfonso Presa created SOLR-4507:
---

 Summary: Cloud option not showing in admin UI when not using 
-DzkHost command line option
 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Priority: Minor


I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
perfectly but the cloud option in the admin UI doesn't appear.

Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in current 
trunk) when the UI tries to guess if SolrCloud is enabled. Not sure about the 
correct way of detecting if cloud is active but the current implementation is 
inconsistent with the funtionality available in solr.xml to provide the list of 
zkHosts.

{quote}
/*Afected SNIPPET from app.js*/
if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
{
 var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
 environment_args = command_line_args.match( 
/-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
 cloud_args = command_line_args.match( /-Dzk/i );
}
/*//Afected SNIPPET from app.js*/
{quote}

*How to reproduce*
In a Solr ensemble using zookeeper, start up a node specifing the list of hosts 
in the zkHost attribute of the solr tag of solr.xml file and do not provide the 
-DzkHost atribute.

*Result*
The cloud option is not available on the admin UI for that node. Though the 
node is correctly as client in the zk ensemble and is working as expected. In 
fact if you directly access the 'htt://host:port/solr/#/~cloud' url the cloud 
info is shown, but the option is still hidden.

*Excepted result*
When accesing the solr admin UI of the node the cloud menu option should be 
visible.

--
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-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


 [ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alfonso Presa updated SOLR-4507:


Description: 
I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
perfectly but the cloud option in the admin UI doesn't appear.

Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in current 
trunk) when the UI tries to guess if SolrCloud is enabled. Not sure about the 
correct way of detecting if cloud is active but the current implementation is 
inconsistent with the funtionality available in solr.xml to provide the list of 
zkHosts.

{quote}
/*Afected SNIPPET from app.js*/
if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
{
 var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
 environment_args = command_line_args.match( 
/-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
 cloud_args = command_line_args.match( /-Dzk/i );
}
/*//Afected SNIPPET from app.js*/
{quote}

*How to reproduce*
In a Solr ensemble using zookeeper, start up a node specifing the list of hosts 
in the zkHost attribute of the solr tag of solr.xml file and do not provide the 
-DzkHost atribute.

*Result*
The cloud option is not available on the admin UI for that node. Though the 
node is registered correctly as client in the zk ensemble and is working as 
expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
url the cloud info is shown, but the option is still hidden.

*Excepted result*
When accesing the solr admin UI of the node the cloud menu option should be 
visible.

  was:
I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
perfectly but the cloud option in the admin UI doesn't appear.

Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in current 
trunk) when the UI tries to guess if SolrCloud is enabled. Not sure about the 
correct way of detecting if cloud is active but the current implementation is 
inconsistent with the funtionality available in solr.xml to provide the list of 
zkHosts.

{quote}
/*Afected SNIPPET from app.js*/
if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
{
 var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
 environment_args = command_line_args.match( 
/-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
 cloud_args = command_line_args.match( /-Dzk/i );
}
/*//Afected SNIPPET from app.js*/
{quote}

*How to reproduce*
In a Solr ensemble using zookeeper, start up a node specifing the list of hosts 
in the zkHost attribute of the solr tag of solr.xml file and do not provide the 
-DzkHost atribute.

*Result*
The cloud option is not available on the admin UI for that node. Though the 
node is correctly as client in the zk ensemble and is working as expected. In 
fact if you directly access the 'htt://host:port/solr/#/~cloud' url the cloud 
info is shown, but the option is still hidden.

*Excepted result*
When accesing the solr admin UI of the node the cloud menu option should be 
visible.


 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Priority: Minor

 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 {quote}
 /*Afected SNIPPET from app.js*/
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
  var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
  environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
  cloud_args = command_line_args.match( /-Dzk/i );
 }
 /*//Afected SNIPPET from app.js*/
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the

[jira] [Updated] (SOLR-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


 [ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alfonso Presa updated SOLR-4507:


Description: 
I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
perfectly but the cloud option in the admin UI doesn't appear.

Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in current 
trunk) when the UI tries to guess if SolrCloud is enabled. Not sure about the 
correct way of detecting if cloud is active but the current implementation is 
inconsistent with the funtionality available in solr.xml to provide the list of 
zkHosts.

Afected snippet from app.js:
{quote}

if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
{
  var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
  environment_args = command_line_args.match( 
/-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
  cloud_args = command_line_args.match( /-Dzk/i );
}
{quote}

*How to reproduce*
In a Solr ensemble using zookeeper, start up a node specifing the list of hosts 
in the zkHost attribute of the solr tag of solr.xml file and do not provide the 
-DzkHost atribute.

*Result*
The cloud option is not available on the admin UI for that node. Though the 
node is registered correctly as client in the zk ensemble and is working as 
expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
url the cloud info is shown, but the option is still hidden.

*Excepted result*
When accesing the solr admin UI of the node the cloud menu option should be 
visible.

  was:
I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
perfectly but the cloud option in the admin UI doesn't appear.

Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in current 
trunk) when the UI tries to guess if SolrCloud is enabled. Not sure about the 
correct way of detecting if cloud is active but the current implementation is 
inconsistent with the funtionality available in solr.xml to provide the list of 
zkHosts.

Afected SNIPPET from app.js:
{quote}

if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
{
  var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
  environment_args = command_line_args.match( 
/-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
  cloud_args = command_line_args.match( /-Dzk/i );
}
{quote}

*How to reproduce*
In a Solr ensemble using zookeeper, start up a node specifing the list of hosts 
in the zkHost attribute of the solr tag of solr.xml file and do not provide the 
-DzkHost atribute.

*Result*
The cloud option is not available on the admin UI for that node. Though the 
node is registered correctly as client in the zk ensemble and is working as 
expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
url the cloud info is shown, but the option is still hidden.

*Excepted result*
When accesing the solr admin UI of the node the cloud menu option should be 
visible.


 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Priority: Minor

 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected.

[jira] [Updated] (SOLR-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


 [ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alfonso Presa updated SOLR-4507:


Description: 
I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
perfectly but the cloud option in the admin UI doesn't appear.

Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in current 
trunk) when the UI tries to guess if SolrCloud is enabled. Not sure about the 
correct way of detecting if cloud is active but the current implementation is 
inconsistent with the funtionality available in solr.xml to provide the list of 
zkHosts.

Afected SNIPPET from app.js:
{quote}

if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
{
  var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
  environment_args = command_line_args.match( 
/-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
  cloud_args = command_line_args.match( /-Dzk/i );
}
{quote}

*How to reproduce*
In a Solr ensemble using zookeeper, start up a node specifing the list of hosts 
in the zkHost attribute of the solr tag of solr.xml file and do not provide the 
-DzkHost atribute.

*Result*
The cloud option is not available on the admin UI for that node. Though the 
node is registered correctly as client in the zk ensemble and is working as 
expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
url the cloud info is shown, but the option is still hidden.

*Excepted result*
When accesing the solr admin UI of the node the cloud menu option should be 
visible.

  was:
I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
perfectly but the cloud option in the admin UI doesn't appear.

Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in current 
trunk) when the UI tries to guess if SolrCloud is enabled. Not sure about the 
correct way of detecting if cloud is active but the current implementation is 
inconsistent with the funtionality available in solr.xml to provide the list of 
zkHosts.

{quote}
/*Afected SNIPPET from app.js*/
if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
{
 var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
 environment_args = command_line_args.match( 
/-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
 cloud_args = command_line_args.match( /-Dzk/i );
}
/*//Afected SNIPPET from app.js*/
{quote}

*How to reproduce*
In a Solr ensemble using zookeeper, start up a node specifing the list of hosts 
in the zkHost attribute of the solr tag of solr.xml file and do not provide the 
-DzkHost atribute.

*Result*
The cloud option is not available on the admin UI for that node. Though the 
node is registered correctly as client in the zk ensemble and is working as 
expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
url the cloud info is shown, but the option is still hidden.

*Excepted result*
When accesing the solr admin UI of the node the cloud menu option should be 
visible.


 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Priority: Minor

 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected SNIPPET from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk

[jira] [Commented] (SOLR-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


[ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588301#comment-13588301
 ] 

Alfonso Presa commented on SOLR-4507:
-

Doesn't seem that either /solr/admin/system nor /solr/admin/cores provide any 
information about the Solr cloud is active when not using the -DzkHost command 
line argument :-(. 

After doing some researching, may be the easiest way to solve this issue could 
be calling to http://host:port/solr/zookeeper service and checking if response 
does contain a tree element, if so the #cloud element of the menu should be 
displayed.


 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Priority: Minor

 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


[ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588301#comment-13588301
 ] 

Alfonso Presa edited comment on SOLR-4507 at 2/27/13 2:10 PM:
--

Doesn't seem that neither /solr/admin/system nor /solr/admin/cores provide any 
information about the Solr cloud is active when not using the -DzkHost command 
line argument :-(. 

After doing some researching, may be the easiest way to solve this issue could 
be calling to http://host:port/solr/zookeeper service and checking if response 
does contain a tree element, if so the #cloud element of the menu should be 
displayed.


  was (Author: alfonso.presa):
Doesn't seem that either /solr/admin/system nor /solr/admin/cores provide 
any information about the Solr cloud is active when not using the -DzkHost 
command line argument :-(. 

After doing some researching, may be the easiest way to solve this issue could 
be calling to http://host:port/solr/zookeeper service and checking if response 
does contain a tree element, if so the #cloud element of the menu should be 
displayed.

  
 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Priority: Minor

 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
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-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


 [ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-4507:
--

Fix Version/s: 5.0
   4.2

 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Priority: Minor
 Fix For: 4.2, 5.0


 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
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-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


[ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588371#comment-13588371
 ] 

Mark Miller commented on SOLR-4507:
---

Thanks for looking into this Alfonso.

 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Priority: Minor
 Fix For: 4.2, 5.0


 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
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-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


[ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588384#comment-13588384
 ] 

Mark Miller commented on SOLR-4507:
---

I'm thinking I'll just add something to the system output that tells if cloud 
mode is on.

 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Priority: Minor
 Fix For: 4.2, 5.0


 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
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] [Assigned] (SOLR-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


 [ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller reassigned SOLR-4507:
-

Assignee: Mark Miller

 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.2, 5.0


 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
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-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


[ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588389#comment-13588389
 ] 

Alfonso Presa commented on SOLR-4507:
-

That sounds like the perfect solution :-) (way better than mine). Thank you, 
Mark.

 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.2, 5.0


 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
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-4507) Cloud option not showing in admin UI when not using -DzkHost command line option

2013-02-27 Thread Commit Tag Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588416#comment-13588416
 ] 

Commit Tag Bot commented on SOLR-4507:
--

[trunk commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revisionrevision=1450800

SOLR-4507: The Cloud tab does not show up in the Admin UI if you set zkHost in 
solr.xml.


 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.2, 5.0


 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
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-4507) Cloud option not showing in admin UI when not using -DzkHost command line option

2013-02-27 Thread Commit Tag Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588427#comment-13588427
 ] 

Commit Tag Bot commented on SOLR-4507:
--

[branch_4x commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revisionrevision=1450801

SOLR-4507: The Cloud tab does not show up in the Admin UI if you set zkHost in 
solr.xml.


 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.2, 5.0


 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
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-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


 [ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller resolved SOLR-4507.
---

Resolution: Fixed

Thanks Alfonso!

 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.2, 5.0


 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
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-4507) Cloud option not showing in admin UI when not using -DzkHost command line option


[ 
https://issues.apache.org/jira/browse/SOLR-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588432#comment-13588432
 ] 

Alfonso Presa commented on SOLR-4507:
-

Wow that was fast :-). Thank you Mark!

 Cloud option not showing in admin UI when not using -DzkHost command line 
 option
 

 Key: SOLR-4507
 URL: https://issues.apache.org/jira/browse/SOLR-4507
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Linux
Reporter: Alfonso Presa
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.2, 5.0


 I've found out that in Solr 4.1, when using the zkHost attribute of the solr 
 tag in solr.xml, instead of the -DzkHost command line option, SolrCloud works 
 perfectly but the cloud option in the admin UI doesn't appear.
 Bug seems to be on app.js file in lines 316-322 in Solr 4.1 (406-412 in 
 current trunk) when the UI tries to guess if SolrCloud is enabled. Not sure 
 about the correct way of detecting if cloud is active but the current 
 implementation is inconsistent with the funtionality available in solr.xml to 
 provide the list of zkHosts.
 Afected snippet from app.js:
 {quote}
 if( response.jvm  response.jvm.jmx  response.jvm.jmx.commandLineArgs )
 {
   var command_line_args = response.jvm.jmx.commandLineArgs.join( ' | ' );
   environment_args = command_line_args.match( 
 /-Dsolr.environment=((dev|test|prod)?[\w\d]*)/i );
   cloud_args = command_line_args.match( /-Dzk/i );
 }
 {quote}
 *How to reproduce*
 In a Solr ensemble using zookeeper, start up a node specifing the list of 
 hosts in the zkHost attribute of the solr tag of solr.xml file and do not 
 provide the -DzkHost atribute.
 *Result*
 The cloud option is not available on the admin UI for that node. Though the 
 node is registered correctly as client in the zk ensemble and is working as 
 expected. In fact if you directly access the 'htt://host:port/solr/#/~cloud' 
 url the cloud info is shown, but the option is still hidden.
 *Excepted result*
 When accesing the solr admin UI of the node the cloud menu option should be 
 visible.

--
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-4471) Replication occurs even when a slave is already up to date.


[ 
https://issues.apache.org/jira/browse/SOLR-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588450#comment-13588450
 ] 

Mark Miller commented on SOLR-4471:
---

{quote}
When I do http://localhost:17045/solr/replication?command=indexversion response 
is:
long name=generation29037/long
That's the same version than slaves have, but on the UI generation in master is 
now 29082.
{quote}

Sounds like perhaps that needs it's own new JIRA issue?

 Replication occurs even when a slave is already up to date.
 ---

 Key: SOLR-4471
 URL: https://issues.apache.org/jira/browse/SOLR-4471
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 4.1
Reporter: Andre Charton
Assignee: Mark Miller
  Labels: master, replication, slave, version
 Fix For: 4.2, 5.0

 Attachments: SOLR-4471.patch, SOLR-4471.patch, SOLR-4471.patch, 
 SOLR-4471_TestRefactor.diff, SOLR-4471_Tests.patch


 Scenario: master/slave replication, master delta index runs every 10 minutes, 
 slave poll interval is 10 sec.
 There was an issue SOLR-4413 - slave reads index from wrong directory, so 
 slave is full copy index from master every time, which is fixed after 
 applying this patch from 4413 (see script below).
 Now on replication the slave downloads only updated files, but slave is 
 create a new segement file and also a new version of index (generation is 
 identical with master). On next polling the slave is download the full index 
 again, because the new version slave is force a full copy.
 Problem is the new version of index on the slave after first replication.
 {noformat:apply patch SOLR-4413 script, please copy patch into patches 
 directory before useage.}
 mkdir work
 cd work
 svn co http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_1/
 cd lucene_solr_4_1
 patch -p0  ../../patches/SOLR-4413.patch
 cd solr
 ant dist
 {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-4503) Add REST API methods to get schema information: fields, dynamic fields, and field types

2013-02-27 Thread Yonik Seeley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588477#comment-13588477
 ] 

Yonik Seeley commented on SOLR-4503:


Darn... patch is already out of date.
Do you have some examples of what responses look like?

 Add REST API methods to get schema information: fields, dynamic fields, and 
 field types
 ---

 Key: SOLR-4503
 URL: https://issues.apache.org/jira/browse/SOLR-4503
 Project: Solr
  Issue Type: Sub-task
  Components: Schema and Analysis
Affects Versions: 4.1
Reporter: Steve Rowe
Assignee: Steve Rowe
 Attachments: SOLR-4503.patch


 Add REST methods that provide properties for fields, dynamic fields, and 
 field types, using paths:
 /solr/(corename)/schema/fields
 /solr/(corename)/schema/fields/fieldname
 /solr/(corename)/schema/dynamicfields
 /solr/(corename)/schema/dynamicfields/pattern
 /solr/(corename)/schema/fieldtypes
 /solr/(corename)/schema/fieldtypes/typename 

--
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-3843) Add lucene-codecs to Solr libs?

2013-02-27 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588507#comment-13588507
]

Robert Muir commented on SOLR-3843:
---

{quote}
Have you looked at ElasticSearch? Its very tiny (20 MB alltogether), no useless
analyzers for every language on earth. If you need kumoroji, enter:

bin/plugin -install elasticsearch/elasticsearch-analysis-kuromoji

This downloads the plugin and installs it into the ES lib folder. This is how
it should work, instead of one horrible huge war file.
{quote}

But I'm not sure this is a good thing. I did some quick google searches and
found:
* http://www.sentric.ch/blog/why-we-chose-solr-4-0-instead-of-elasticsearch
Better language support out of the box
*
http://blog.sematext.com/2012/09/04/solr-vs-elasticsearch-part-2-data-handling/
Apache Solr 4.0 beta has the advantage over ElasticSearch because it can
handle more languages out of the box

I think both search servers are good for the lucene ecosystem and its not my
intent to stir up some battle about which is better.
I'm guessing that you can access all of the lucene analyzers from either one,
but the *impression* from *packaging* is that Solr
is better.

Lets not make this same mistake with codecs!

Most users probably could care less about SPI etc (this is all implementation
details). They do care about being able to
search different languages and index their content with the appropriate data
structures.

I'm happy to open an issue to refactor our build and tests to internally
reflect the fact that, using solr-core as a library for example, you dont
technically need certain jars.

But can we separate this from *packaging*, at least for now? It would be
depressing to me to see articles like this that say solr has bad support for
flexible indexing.

Add lucene-codecs to Solr libs?
---

Key: SOLR-3843
URL: https://issues.apache.org/jira/browse/SOLR-3843
Project: Solr
Issue Type: Wish
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Critical
Fix For: 4.2, 5.0

Attachments: SOLR-3843.patch, SOLR-3843.patch, SOLR-3843.patch

Solr gives the ability to its users to select the postings format to use on a
per-field basis but only Lucene40PostingsFormat is available by default
(unless users add lucene-codecs to the Solr lib directory). Maybe we should
add lucene-codecs to Solr libs (I mean in the WAR file) so that people can
try our non-default postings formats with minimum effort?

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4503) Add REST API methods to get schema information: fields, dynamic fields, and field types


 [ 
https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-4503:
-

Attachment: coordinate.dynamic.field.json
price.field.json
date.field.type.json
all.fields.json
all.field.types.json
all.dynamic.fields.json

bq. Darn... patch is already out of date.

I'll put up a more modern version, with most tests in place, in a little bit.

bq. Do you have some examples of what responses look like?

Yes, I do, attaching JSON responses for all six requests here.  I haven't 
investigated yet, but I believe there is an issue with copy fields in both the 
/schema/fields/ and /schema/dynamicfields/ responses, probably related to 
SOLR-3798, since I copied the functionality from LukeRequestHandler.  But 
otherwise, I think the response formats are stable now.

 Add REST API methods to get schema information: fields, dynamic fields, and 
 field types
 ---

 Key: SOLR-4503
 URL: https://issues.apache.org/jira/browse/SOLR-4503
 Project: Solr
  Issue Type: Sub-task
  Components: Schema and Analysis
Affects Versions: 4.1
Reporter: Steve Rowe
Assignee: Steve Rowe
 Attachments: all.dynamic.fields.json, all.fields.json, 
 all.field.types.json, coordinate.dynamic.field.json, date.field.type.json, 
 price.field.json, SOLR-4503.patch


 Add REST methods that provide properties for fields, dynamic fields, and 
 field types, using paths:
 /solr/(corename)/schema/fields
 /solr/(corename)/schema/fields/fieldname
 /solr/(corename)/schema/dynamicfields
 /solr/(corename)/schema/dynamicfields/pattern
 /solr/(corename)/schema/fieldtypes
 /solr/(corename)/schema/fieldtypes/typename 

--
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-4508) DIHConfiguration and Document classes are suspiciously similar

2013-02-27 Thread Vadim Kirilchuk (JIRA)

Vadim Kirilchuk created SOLR-4508:
-

 Summary: DIHConfiguration and Document classes are suspiciously 
similar
 Key: SOLR-4508
 URL: https://issues.apache.org/jira/browse/SOLR-4508
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Reporter: Vadim Kirilchuk


Hi, 

I see that there are two classes in dih codebase which are quite similar, and 
looks like the latter (Document.java) has no usages.

trunk/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/config/Document.java

Is it dead code? Should it be removed?

Thanks

--
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-4509) Disable Stale Check - Distributed Search (Performance)

Ryan Zezeski created SOLR-4509:
--

 Summary: Disable Stale Check - Distributed Search (Performance)
 Key: SOLR-4509
 URL: https://issues.apache.org/jira/browse/SOLR-4509
 Project: Solr
  Issue Type: Improvement
  Components: search
 Environment: 5 node SmartOS cluster (all nodes living in same global 
zone - i.e. same physical machine)
Reporter: Ryan Zezeski
Priority: Minor


By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase 
in throughput and reduction of over 100ms.  This patch was made in the context 
of a project I'm leading, called Yokozuna, which relies on distributed search.

Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26

Here's a write-up I did on my findings: 
http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html

I'm happy to answer any questions or make changes to the patch to make it 
acceptable.

--
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-4509) Disable Stale Check - Distributed Search (Performance)


 [ 
https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Zezeski updated SOLR-4509:
---

Attachment: SOLR-4509.patch

 Disable Stale Check - Distributed Search (Performance)
 --

 Key: SOLR-4509
 URL: https://issues.apache.org/jira/browse/SOLR-4509
 Project: Solr
  Issue Type: Improvement
  Components: search
 Environment: 5 node SmartOS cluster (all nodes living in same global 
 zone - i.e. same physical machine)
Reporter: Ryan Zezeski
Priority: Minor
 Attachments: SOLR-4509.patch


 By disabling the Apache HTTP Client stale check I've witnessed a 2-4x 
 increase in throughput and reduction of over 100ms.  This patch was made in 
 the context of a project I'm leading, called Yokozuna, which relies on 
 distributed search.
 Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26
 Here's a write-up I did on my findings: 
 http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html
 I'm happy to answer any questions or make changes to the patch to make it 
 acceptable.

--
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-4509) Disable Stale Check - Distributed Search (Performance)


[ 
https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588561#comment-13588561
 ] 

Ryan Zezeski commented on SOLR-4509:


I generated the patch from my clone of the git mirror.  If this patch is 
unacceptable in anyway I'm willing to redo.  Just thought I'd take the easy 
route first.

 Disable Stale Check - Distributed Search (Performance)
 --

 Key: SOLR-4509
 URL: https://issues.apache.org/jira/browse/SOLR-4509
 Project: Solr
  Issue Type: Improvement
  Components: search
 Environment: 5 node SmartOS cluster (all nodes living in same global 
 zone - i.e. same physical machine)
Reporter: Ryan Zezeski
Priority: Minor
 Attachments: SOLR-4509.patch


 By disabling the Apache HTTP Client stale check I've witnessed a 2-4x 
 increase in throughput and reduction of over 100ms.  This patch was made in 
 the context of a project I'm leading, called Yokozuna, which relies on 
 distributed search.
 Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26
 Here's a write-up I did on my findings: 
 http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html
 I'm happy to answer any questions or make changes to the patch to make it 
 acceptable.

--
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-4505) Deadlock around SolrCoreState update lock.


 [ 
https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-4505:
-

Attachment: newstack.txt

Unfortunately, same thing. It's so similar that I had to double-check to see if 
I'd actually applied the latest patch

 Deadlock around SolrCoreState update lock.
 --

 Key: SOLR-4505
 URL: https://issues.apache.org/jira/browse/SOLR-4505
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: newstack.txt, newstack.txt, SOLR-4505.patch, 
 SOLR-4505.patch


 Erick found a deadlock with his core stress tool - see 
 http://markmail.org/message/aq5hghbqia2uimgl

--
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-4509) Disable Stale Check - Distributed Search (Performance)

2013-02-27 Thread Shawn Heisey (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588597#comment-13588597
]

Shawn Heisey commented on SOLR-4509:

Interested user here, not anyone linked to Solr or Lucene.

Would the 100ms latency you have described here show up in QTime values or be
purely client-side? I ask because the median (not average) QTime value I see
in disributed searches (seven shards on two servers) on Solr 3.5.0 is about 10
milliseconds, and even faster on 4.2-SNAPSHOT ... and that involves the stale
check both on the client side and the seven shards. The client is SolrJ 4.1,
with max retries (2) and connection timeout (5000ms) being the only low-level
parameters that are set. SolrCloud is not involved here.

The idea of a sweeper thread makes me nervous, given the project's general
reaction to the background threads created by an intermediate SOLR-1972 patch.
Also, with 5000 milliseconds between executions of the sweeper thread and an
assumption of a server timeout of 50 milliseconds, will it be able to
effectively avoid problems in all environments? If these are not actual
worries, then I can be quiet.

Disable Stale Check - Distributed Search (Performance)
--

Key: SOLR-4509
URL: https://issues.apache.org/jira/browse/SOLR-4509
Project: Solr
Issue Type: Improvement
Components: search
Environment: 5 node SmartOS cluster (all nodes living in same global
zone - i.e. same physical machine)
Reporter: Ryan Zezeski
Priority: Minor
Attachments: SOLR-4509.patch

By disabling the Apache HTTP Client stale check I've witnessed a 2-4x
increase in throughput and reduction of over 100ms. This patch was made in
the context of a project I'm leading, called Yokozuna, which relies on
distributed search.
Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26
Here's a write-up I did on my findings:
http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html
I'm happy to answer any questions or make changes to the patch to make it
acceptable.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4503) Add REST API methods to get schema information: fields, dynamic fields, and field types


 [ 
https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated SOLR-4503:
-

Attachment: SOLR-4503.patch

Here's my current state.  

I refactored REST-friendly stuff out of TestHarness into BaseHarness, which is 
now extended by TestHarness and a new RestTestHarness. RestTestBase extends 
SolrJettyTestBase to provide HTTP-based (no SolrServer) test sugar: assertU, 
assertQ, assertJQ, etc.  

I've also added the ability to JettySolrRunner to add extra passed-in servlets, 
and I use this functionality to add the Restlet servlet that services the six 
schema resource requests. 

There is a test suite for each of the six resources, configured over 
schema15.xml and solrconfig.xml from solr/src/test-files/. 

'ant test' and 'ant precommit' pass for me.

Left to do:
 
* Add checks for copy fields
* Add checks for the includeDynamic=true functionality for the /schema/fields/ 
resources - this triggers a search for fields in the index that match dynamic 
field patterns and are not explicitly defined in the schema.  If fl fields 
are specified in the request, only those fields are sought in the index.
* Add Maven dependencies for Restlet and the Restlet servlet extension

 Add REST API methods to get schema information: fields, dynamic fields, and 
 field types
 ---

 Key: SOLR-4503
 URL: https://issues.apache.org/jira/browse/SOLR-4503
 Project: Solr
  Issue Type: Sub-task
  Components: Schema and Analysis
Affects Versions: 4.1
Reporter: Steve Rowe
Assignee: Steve Rowe
 Attachments: all.dynamic.fields.json, all.fields.json, 
 all.field.types.json, coordinate.dynamic.field.json, date.field.type.json, 
 price.field.json, SOLR-4503.patch, SOLR-4503.patch


 Add REST methods that provide properties for fields, dynamic fields, and 
 field types, using paths:
 /solr/(corename)/schema/fields
 /solr/(corename)/schema/fields/fieldname
 /solr/(corename)/schema/dynamicfields
 /solr/(corename)/schema/dynamicfields/pattern
 /solr/(corename)/schema/fieldtypes
 /solr/(corename)/schema/fieldtypes/typename 

--
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-4503) Add REST API methods to get schema information: fields, dynamic fields, and field types


[ 
https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588610#comment-13588610
 ] 

Steve Rowe commented on SOLR-4503:
--

One question: both /schema/fields and /schema/dynamicfields accept a fl query 
parameter to restrict the response to the given field(s)/pattern(s), but I 
didn't do the same for /schema/fieldtypes/, since that didn't seem to fit quite 
right.  Should I add this capability there, maybe with some other query 
parameter?

 Add REST API methods to get schema information: fields, dynamic fields, and 
 field types
 ---

 Key: SOLR-4503
 URL: https://issues.apache.org/jira/browse/SOLR-4503
 Project: Solr
  Issue Type: Sub-task
  Components: Schema and Analysis
Affects Versions: 4.1
Reporter: Steve Rowe
Assignee: Steve Rowe
 Attachments: all.dynamic.fields.json, all.fields.json, 
 all.field.types.json, coordinate.dynamic.field.json, date.field.type.json, 
 price.field.json, SOLR-4503.patch, SOLR-4503.patch


 Add REST methods that provide properties for fields, dynamic fields, and 
 field types, using paths:
 /solr/(corename)/schema/fields
 /solr/(corename)/schema/fields/fieldname
 /solr/(corename)/schema/dynamicfields
 /solr/(corename)/schema/dynamicfields/pattern
 /solr/(corename)/schema/fieldtypes
 /solr/(corename)/schema/fieldtypes/typename 

--
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-4505) Deadlock around SolrCoreState update lock.


[ 
https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588611#comment-13588611
 ] 

Mark Miller commented on SOLR-4505:
---

The lines from your stack traces dont line up with the code I have in 
DefaultSolrCoreState, so it seems something must be different...

 Deadlock around SolrCoreState update lock.
 --

 Key: SOLR-4505
 URL: https://issues.apache.org/jira/browse/SOLR-4505
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: newstack.txt, newstack.txt, SOLR-4505.patch, 
 SOLR-4505.patch


 Erick found a deadlock with his core stress tool - see 
 http://markmail.org/message/aq5hghbqia2uimgl

--
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-4505) Deadlock around SolrCoreState update lock.


[ 
https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588613#comment-13588613
 ] 

Mark Miller commented on SOLR-4505:
---

Hmm...or I'm just reading it wrong - it must be waiting on the sync of the 
getIndexWriter itself...let me think about it for a bit.

 Deadlock around SolrCoreState update lock.
 --

 Key: SOLR-4505
 URL: https://issues.apache.org/jira/browse/SOLR-4505
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: newstack.txt, newstack.txt, SOLR-4505.patch, 
 SOLR-4505.patch


 Erick found a deadlock with his core stress tool - see 
 http://markmail.org/message/aq5hghbqia2uimgl

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)

2013-02-27 Thread Shawn Heisey (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588597#comment-13588597
]

Shawn Heisey edited comment on SOLR-4509 at 2/27/13 6:43 PM:
-

Interested user here, not anyone linked to Solr or Lucene.

Would the 100ms latency you have described here show up in QTime values or be
purely client-side? I ask because the median (not average) QTime value I see
in disributed searches (seven shards on two servers) on Solr 3.5.0 is about 10
milliseconds, and even faster on 4.2-SNAPSHOT ... and that involves the stale
check both on the client side and the seven shards. The client is SolrJ 4.1,
with max retries (1) and connection timeout (5000ms) being the only low-level
parameters that are set. SolrCloud is not involved here.

was (Author: elyograg):
Interested user here, not anyone linked to Solr or Lucene.

Disable Stale Check - Distributed Search (Performance)
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2677) timesFailed is incrementing, without a real error

2013-02-27 Thread Brian Lenz (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588614#comment-13588614
 ] 

Brian Lenz commented on SOLR-2677:
--

Any prospect of getting this fixed? We also are experiencing this issue, and 
it's preventing us from properly monitoring that Solr replication is indeed 
working. Since there are false positives (errors reported when there really are 
no errors), we have no way of knowing when replication is truly working.

 timesFailed is incrementing, without a real error
 -

 Key: SOLR-2677
 URL: https://issues.apache.org/jira/browse/SOLR-2677
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 3.3
 Environment: Tomcat6, Debian Squeeze
Reporter: Mark Plomer
Assignee: Shalin Shekhar Mangar
Priority: Trivial
 Attachments: successfulInstall.patch


 The counters timesFailed and replicationFailedAtList on slave replication 
 details page indicate errors on every poll, but in log file there is only:
 INFO: Slave in sync with master.
 This happens until the first real replication of files.
 I tracked things down and it seems that in SnapPuller.java the 
 successfulInstall is initialized with false and not set to true when 
 indexes are in sync.
 I'll attach a small patch (untested).

--
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-4505) Deadlock around SolrCoreState update lock.


 [ 
https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-4505:
--

Attachment: SOLR-4505.patch

We need an alternate approach it seems. Can you try this patch?

 Deadlock around SolrCoreState update lock.
 --

 Key: SOLR-4505
 URL: https://issues.apache.org/jira/browse/SOLR-4505
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: newstack.txt, newstack.txt, SOLR-4505.patch, 
 SOLR-4505.patch, SOLR-4505.patch


 Erick found a deadlock with his core stress tool - see 
 http://markmail.org/message/aq5hghbqia2uimgl

--
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-4509) Disable Stale Check - Distributed Search (Performance)

[
https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588657#comment-13588657
]

Ryan Zezeski commented on SOLR-4509:

Would the 100ms latency you have described here show up in QTime values or be
purely client-side?

So my latency measurements include end-to-end from client-yokozuna-solr
coordinator-shards-solr coordinator-yokozuna-client. I didn't track the
QTimes, but in benchmarks I ran months ago I saw the same results whether I
went through Yokozuna or hit Solr directly with the distributed search. I
could probably re-run to report QTime changes.

I ask because the median (not average)...

I'm also reporting median latency, not mean. In my first link you can also
find graphs with 95th, 99th, 99.9 percentiles.

...an assumption of a server timeout of 50 milliseconds

The assumption is 50s, but yes, it is an assumption. A better patch would make
the idle timeout configurable as well as the period.

If these are not actual worries, then I can be quiet.

No, these are great points. This patch, as it sits now, is for a specific
context. I did what I needed to do to improve my specific situation.
Honestly, I would like to see another person run this patch and verify at least
some amount of speed-up. Otherwise, it might best stay downstream.

Disable Stale Check - Distributed Search (Performance)
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4496) Support for faceting on the start of values

2013-02-27 Thread Teun Duynstee (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588688#comment-13588688
 ] 

Teun Duynstee commented on SOLR-4496:
-

Wow, thanks for your excellent comment. I will have a thorough look at these 
issues and your blog.

 Support for faceting on the start of values
 ---

 Key: SOLR-4496
 URL: https://issues.apache.org/jira/browse/SOLR-4496
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Teun Duynstee
Priority: Minor
 Attachments: limitLength-limitDelim-1st.patch


 The SimpleFacets component supports the prefix parameter to return only 
 facets starting with that prefix. This feature should (IMO) be complemented 
 by two more parameters to make it much more usefull (names could be improved 
 on of course):
 - limitLength: will return facets for only the first x characters of the real 
 facets. If the real values are AAA, CC and CCC, the limitLength=1 parameter 
 would cause the facets A and C to be returned, with the sum of the counts. 
 This could typpically be used for a UI that allows you to select a first 
 letter for fields with many facets.
 - limitDelim: this would not truncate on a fixed length, but on the occurence 
 of a certain character after the prefix. This would allow the user to search 
 for hierarchical fields without having to resort to including each level of 
 the hierarchy at index analysis. This way, the value of the filed cat would 
 be 'ComicsMarvelBatman' and this would be found using 
 prefix=ComicslimitDelim=. This would return the facet Marvel with the 
 combined count for all undelying cat values.
 I am working on a patch that would achieve this by postprocessing the 
 resulting counts in getTermCounts(). However, this will not return the 
 correct counts for multivalued fields. Also, the combination with field.limit 
 is not easy. Any tips for how to implement this? I'm available to work on a 
 patch. Or is it a bad idea anyway?

--
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-4505) Deadlock around SolrCoreState update lock.


[ 
https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588708#comment-13588708
 ] 

Erick Erickson commented on SOLR-4505:
--

As long as you're willing to do the heavy lifting, I'm willing to test G

Trying now.

 Deadlock around SolrCoreState update lock.
 --

 Key: SOLR-4505
 URL: https://issues.apache.org/jira/browse/SOLR-4505
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: newstack.txt, newstack.txt, SOLR-4505.patch, 
 SOLR-4505.patch, SOLR-4505.patch


 Erick found a deadlock with his core stress tool - see 
 http://markmail.org/message/aq5hghbqia2uimgl

--
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-4509) Disable Stale Check - Distributed Search (Performance)

2013-02-27 Thread Markus Jelsma (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588743#comment-13588743
]

Markus Jelsma commented on SOLR-4509:
-

Ryan, this is very interesting indeed! I've read your patch and it looks good,
i'll be testing this in the next few days.

I'm not very sure enabling TCP_NODELAY (e.g. disable Nagle's algorithm) will
help a lot. In theory it could but we already did performance tests a few
months ago on two clusters where one had it enabled and the other didn't. I
could not measure a significant difference, my tests may have been bad of
course :)

Disable Stale Check - Distributed Search (Performance)
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)

[
https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588787#comment-13588787
]

Ryan Zezeski commented on SOLR-4509:

...i'll be testing this in the next few days.

Great, I would love to see these results reproduced by someone else.

I'm not very sure enabling TCP_NODELAY (e.g. disable Nagle's algorithm) will
help a lot

I agree, it probably doesn't matter but I disabled it anyways given that nagle
is really meant for things like telnet and such. I figured it couldn't hurt to
disable.

Disable Stale Check - Distributed Search (Performance)
--

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3755) shard splitting

2013-02-27 Thread Yonik Seeley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588809#comment-13588809
 ] 

Yonik Seeley commented on SOLR-3755:


{quote}
The collections api may be invoked as follows:
http://host:port/solr/admin/collections?action=SPLITshard=shard_1shard=shard_2
{quote}

Ok, I assume this is for splitting more than one shard (i.e. both shard_1 and 
shard_2 in this example will be split?)
How do we know what collection?  I assume there will be a collection 
parameter?

Related: SOLR-4503 - we now have the capability to use restlet, and should 
consider doing so for new APIs like this.

{quote}
Sometimes, shard names are automatically assigned by SolrCloud and it may be 
more convenient for users to specify shards by shard keys instead of shard 
names e.g.
http://host:port/solr/admin/collections?action=SPLITshard.keys=shardKey1,shardKey2;
{quote}

shard.keys is currently used in routing request (and the values are often not 
shard names), so we probably shouldn't overload it here.  After all, it may 
make sense in the future to be able to use shard.keys to specify which shard 
you want to split!



 shard splitting
 ---

 Key: SOLR-3755
 URL: https://issues.apache.org/jira/browse/SOLR-3755
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: SOLR-3755-CoreAdmin.patch, SOLR-3755.patch, 
 SOLR-3755.patch, SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch


 We can currently easily add replicas to handle increases in query volume, but 
 we should also add a way to add additional shards dynamically by splitting 
 existing shards.

--
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-MAVEN] Lucene-Solr-Maven-trunk #785: POMs out of sync

2013-02-27 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/785/

1 tests failed.
REGRESSION:  org.apache.solr.cloud.SyncSliceTest.testDistribSearch

Error Message:
Test Setup Failure: shard1 should have just been set up to be inconsistent - 
but it's still consistent. Leader:http://127.0.0.1:11146/tu/d/collection1skip 
list:[CloudJettyRunner [url=http://127.0.0.1:11150/tu/d/collection1], 
CloudJettyRunner [url=http://127.0.0.1:11150/tu/d/collection1]]

Stack Trace:
java.lang.AssertionError: Test Setup Failure: shard1 should have just been set 
up to be inconsistent - but it's still consistent. 
Leader:http://127.0.0.1:11146/tu/d/collection1skip list:[CloudJettyRunner 
[url=http://127.0.0.1:11150/tu/d/collection1], CloudJettyRunner 
[url=http://127.0.0.1:11150/tu/d/collection1]]
at 
__randomizedtesting.SeedInfo.seed([55107A7DB4415343:D4F6F465C31E337F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.apache.solr.cloud.SyncSliceTest.doTest(SyncSliceTest.java:212)




Build Log:
[...truncated 22410 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

2013-02-27 Thread Rene Nederhand (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rene Nederhand updated LUCENE-2899:
---

Attachment: LUCENE-2899-RJN.patch

New patch for both trunk and 4.1 stable. Tested on revision 1450998.

{code}
ant compile
cd solr/contrib/src/test-files/training
sh bin/trainall.sh
cd ../../../../../../solr
ant example test-contrib
{code} 

Hope this helps more people in testing OpenNLP integration with Solr.

TODO: 
* Implementing dev-tools
* Include references to javadocs

 Add OpenNLP Analysis capabilities as a module
 -

 Key: LUCENE-2899
 URL: https://issues.apache.org/jira/browse/LUCENE-2899
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
 LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
 LUCENE-2899-RJN.patch, OpenNLPFilter.java, OpenNLPTokenizer.java, 
 opennlp_trunk.patch


 Now that OpenNLP is an ASF project and has a nice license, it would be nice 
 to have a submodule (under analysis) that exposed capabilities for it. Drew 
 Farris, Tom Morton and I have code that does:
 * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
 would have to change slightly to buffer tokens)
 * NamedEntity recognition as a TokenFilter
 We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
 either payloads (PartOfSpeechAttribute?) on a token or at the same position.
 I'd propose it go under:
 modules/analysis/opennlp

--
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-2899) Add OpenNLP Analysis capabilities as a module

2013-02-27 Thread Rene Nederhand (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588855#comment-13588855
 ] 

Rene Nederhand commented on LUCENE-2899:


New patch for both trunk and 4.1 stable. Tested on revision 1450998.

{code}
ant compile
cd solr/contrib/src/test-files/training
sh bin/trainall.sh
cd ../../../../../../solr
ant example test-contrib
{code} 

Hope this helps more people in testing OpenNLP integration with Solr.

TODO: 
* Implementing dev-tools
* Include references to javadocs

 Add OpenNLP Analysis capabilities as a module
 -

 Key: LUCENE-2899
 URL: https://issues.apache.org/jira/browse/LUCENE-2899
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
 LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
 LUCENE-2899-RJN.patch, OpenNLPFilter.java, OpenNLPTokenizer.java, 
 opennlp_trunk.patch


 Now that OpenNLP is an ASF project and has a nice license, it would be nice 
 to have a submodule (under analysis) that exposed capabilities for it. Drew 
 Farris, Tom Morton and I have code that does:
 * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
 would have to change slightly to buffer tokens)
 * NamedEntity recognition as a TokenFilter
 We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
 either payloads (PartOfSpeechAttribute?) on a token or at the same position.
 I'd propose it go under:
 modules/analysis/opennlp

--
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-4505) Deadlock around SolrCoreState update lock.


 [ 
https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-4505:
-

Attachment: newstack.txt

Latest lockup stack

 Deadlock around SolrCoreState update lock.
 --

 Key: SOLR-4505
 URL: https://issues.apache.org/jira/browse/SOLR-4505
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: newstack.txt, newstack.txt, newstack.txt, 
 SOLR-4505.patch, SOLR-4505.patch, SOLR-4505.patch


 Erick found a deadlock with his core stress tool - see 
 http://markmail.org/message/aq5hghbqia2uimgl

--
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-4505) Deadlock around SolrCoreState update lock.


[ 
https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588878#comment-13588878
 ] 

Mark Miller commented on SOLR-4505:
---

Hmm...this time the lines are diff slightly off from my src - do you have any 
custom changes in those couple classes?

 Deadlock around SolrCoreState update lock.
 --

 Key: SOLR-4505
 URL: https://issues.apache.org/jira/browse/SOLR-4505
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: newstack.txt, newstack.txt, newstack.txt, 
 SOLR-4505.patch, SOLR-4505.patch, SOLR-4505.patch


 Erick found a deadlock with his core stress tool - see 
 http://markmail.org/message/aq5hghbqia2uimgl

--
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-4505) Deadlock around SolrCoreState update lock.


[ 
https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1355#comment-1355
 ] 

Mark Miller commented on SOLR-4505:
---

Do you have the latest of your test up, or can you put it up? Then I can try 
some various things more quickly perhaps.

 Deadlock around SolrCoreState update lock.
 --

 Key: SOLR-4505
 URL: https://issues.apache.org/jira/browse/SOLR-4505
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: newstack.txt, newstack.txt, newstack.txt, 
 SOLR-4505.patch, SOLR-4505.patch, SOLR-4505.patch


 Erick found a deadlock with his core stress tool - see 
 http://markmail.org/message/aq5hghbqia2uimgl

--
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 # 1026 - Failure

2013-02-27 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/1026/

1 tests failed.
REGRESSION:  org.apache.lucene.facet.search.TestDrillSideways.testRandom

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([BC1B11849F37130F:CE57348B2E57A57C]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.lucene.facet.search.TestDrillSideways.verifyEquals(TestDrillSideways.java:810)
at 
org.apache.lucene.facet.search.TestDrillSideways.testRandom(TestDrillSideways.java:630)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)




Build Log:
[...truncated 6729 lines...]
[junit4:junit4] Suite: org.apache.lucene.facet.search.TestDrillSideways
[junit4:junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=TestDrillSideways -Dtests.method=testRandom 
-Dtests.seed=BC1B11849F37130F -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=ko_KR -Dtests.timezone=America/Argentina/Ushuaia 
-Dtests.file.encoding=ISO-8859-1
[junit4:junit4] FAILURE 4.10s J0 | TestDrillSideways.testRandom

[jira] [Updated] (SOLR-4196) Untangle XML-specific nature of Config and Container classes


 [ 
https://issues.apache.org/jira/browse/SOLR-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-4196:
-

Attachment: SOLR-4196.patch

Also attached is latest jar of the stress test program as well as sources.

 Untangle XML-specific nature of Config and Container classes
 

 Key: SOLR-4196
 URL: https://issues.apache.org/jira/browse/SOLR-4196
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, 
 SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, 
 SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, 
 SOLR-4196.patch, SOLR-4196.patch, StressTest.zip, StressTest.zip, 
 StressTest.zip


 sub-task for SOLR-4083. If we're going to try to obsolete solr.xml, we need 
 to pull all of the specific XML processing out of Config and Container. 
 Currently, we refer to xpaths all over the place. This JIRA is about 
 providing a thunking layer to isolate the XML-esque nature of solr.xml and 
 allow a simple properties file to be used instead which will lead, 
 eventually, to solr.xml going away.

--
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-4196) Untangle XML-specific nature of Config and Container classes


 [ 
https://issues.apache.org/jira/browse/SOLR-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-4196:
-

Attachment: StressTest.zip

Oops, fat fingers, sent too soon. Jar file is too big (zips up SolJ stuff), so 
src attached in zip file

 Untangle XML-specific nature of Config and Container classes
 

 Key: SOLR-4196
 URL: https://issues.apache.org/jira/browse/SOLR-4196
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, 
 SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, 
 SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, 
 SOLR-4196.patch, SOLR-4196.patch, StressTest.zip, StressTest.zip, 
 StressTest.zip, StressTest.zip


 sub-task for SOLR-4083. If we're going to try to obsolete solr.xml, we need 
 to pull all of the specific XML processing out of Config and Container. 
 Currently, we refer to xpaths all over the place. This JIRA is about 
 providing a thunking layer to isolate the XML-esque nature of solr.xml and 
 allow a simple properties file to be used instead which will lead, 
 eventually, to solr.xml going away.

--
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-4505) Deadlock around SolrCoreState update lock.


[ 
https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588928#comment-13588928
 ] 

Mark Miller commented on SOLR-4505:
---

Yeah, I'm happy to have your help :) Once I get something that looks better 
I'll ask you to blast it too - but at this rate, I'd like to be able to try 
some things out - I've also noticed sometimes I different hardware can trigger 
these things faster. My suped up linux box could cause the previous deadlock 
you found pretty fast.

 Deadlock around SolrCoreState update lock.
 --

 Key: SOLR-4505
 URL: https://issues.apache.org/jira/browse/SOLR-4505
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: newstack.txt, newstack.txt, newstack.txt, 
 SOLR-4505.patch, SOLR-4505.patch, SOLR-4505.patch


 Erick found a deadlock with his core stress tool - see 
 http://markmail.org/message/aq5hghbqia2uimgl

--
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-2996) make q=* not suck in the lucene and edismax parsers

2013-02-27 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SOLR-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588929#comment-13588929
 ] 

Jan Høydahl commented on SOLR-2996:
---

Who knows QueryParser.jj grammar well enough to know where to fix this so that 
a bare * gets translated to *:*? Would make a great fix for 4.2 if it's a 
15-min fix?

 make q=* not suck in the lucene and edismax parsers
 -

 Key: SOLR-2996
 URL: https://issues.apache.org/jira/browse/SOLR-2996
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Reporter: Hoss Man

 More then a few users have gotten burned by thinking that {{\*}} is the 
 appropriate syntax for match all docs when what it really does (unless i'm 
 mistaken) is create a prefix query on the default search field using a blank 
 string as the prefix.
 since it seems very unlikely that anyone has a genuine usecase for making a 
 prefix query with a blank prefix, we should change the default behavior of 
 the LuceneQParser and EDismaxQParsers (and any other Qparsers that respect 
 {{\*:\*}} if i'm forgetting them) to treat this situation the same as 
 {{\*:\*}}.  we can offer a (local)param to force the old behavior if someone 
 really wants it.

--
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-4505) Deadlock around SolrCoreState update lock.


[ 
https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588938#comment-13588938
 ] 

Erick Erickson commented on SOLR-4505:
--

P.S. I'll see what I can do to get the stress-test program in as a unit test by 
Monday FWIW.


 Deadlock around SolrCoreState update lock.
 --

 Key: SOLR-4505
 URL: https://issues.apache.org/jira/browse/SOLR-4505
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: newstack.txt, newstack.txt, newstack.txt, 
 SOLR-4505.patch, SOLR-4505.patch, SOLR-4505.patch


 Erick found a deadlock with his core stress tool - see 
 http://markmail.org/message/aq5hghbqia2uimgl

--
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-4401) Move the stress test in SOLR-4196 into a junit test

[
https://issues.apache.org/jira/browse/SOLR-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588947#comment-13588947
]

Erick Erickson commented on SOLR-4401:
--

I'm going to try to put this into a junit test over the weekend. It can run
really long or really short. I'm thinking of providing three methods, one that
runs all the time and takes 30 seconds? a minute? Label it as slow either way.

A nightly that runs for 10 minutes

A weekly that runs for an hour

The background here is that I see issues after 1-2 hours running on my machine,
occasionally as little as 30 minutes. I suppose if it runs more often it'd have
a better chance of hitting at shorter intervals. I'm open to suggestions, so
let me know I really don't have a sense of how onerous a really
long-running test would be

Mark:
When I mentioned prior art it was mostly a shorthand to myself that there
seemed to be code I could use as a model in TestReplicationHandler in terms of
starting up servers and all that rot. But I'll look at JettySolrRunner as you
indicated, thanks for the pointer.

Move the stress test in SOLR-4196 into a junit test
---

Key: SOLR-4401
URL: https://issues.apache.org/jira/browse/SOLR-4401
Project: Solr
Issue Type: Test
Affects Versions: 4.2, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
Fix For: 4.2, 5.0

Attachments: StressTest.zip

As part of SOLR-4196, I created a stress test proces for rapidly opening and
closing cores. It'd probably be useful to make this into a junit test that
ran nightly (it needs some time in order to show anything, as in minutes).
Typical failures are 20 minutes into the run, but occasionally they're faster.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-Tests-4.x-java7 - Build # 1026 - Failure

2013-02-27 Thread Michael McCandless

This repros ... I'll dig.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Feb 27, 2013 at 6:18 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/1026/

 1 tests failed.
 REGRESSION:  org.apache.lucene.facet.search.TestDrillSideways.testRandom

 Error Message:


 Stack Trace:
 java.lang.AssertionError
 at 
 __randomizedtesting.SeedInfo.seed([BC1B11849F37130F:CE57348B2E57A57C]:0)
 at org.junit.Assert.fail(Assert.java:92)
 at org.junit.Assert.assertTrue(Assert.java:43)
 at org.junit.Assert.assertTrue(Assert.java:54)
 at 
 org.apache.lucene.facet.search.TestDrillSideways.verifyEquals(TestDrillSideways.java:810)
 at 
 org.apache.lucene.facet.search.TestDrillSideways.testRandom(TestDrillSideways.java:630)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at java.lang.Thread.run(Thread.java:722)




 Build Log:
 [...truncated 6729 lines...]
 [junit4:junit4] Suite: org.apache.lucene.facet.search.TestDrillSideways
 [junit4:junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=TestDrillSideways

[jira] [Commented] (SOLR-4401) Move the stress test in SOLR-4196 into a junit test

[
https://issues.apache.org/jira/browse/SOLR-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588960#comment-13588960
]

Mark Miller commented on SOLR-4401:
---

The times seem reasonable to me. I'm not so worried about it running forever -
we can always do that manually. You will still get a lot of testing out of the
many different envs and the fact that those jenkins are cranking all day long.
You are probably just as likely to find it cranking for 30 seconds on 20 vm's
15 timdes a day as on one machine cranking for 6 hours or whatever.

Move the stress test in SOLR-4196 into a junit test
---

Attachments: StressTest.zip

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3798) copyField logic in LukeRequestHandler is primitive, doesn't work well with dynamicFields