You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2009/01/14 03:34:59 UTC
[jira] Created: (SOLR-959) Remove hardcoded port numbers from
TestReplicationHandler
Remove hardcoded port numbers from TestReplicationHandler
---------------------------------------------------------
Key: SOLR-959
URL: https://issues.apache.org/jira/browse/SOLR-959
Project: Solr
Issue Type: Test
Components: replication (java)
Reporter: Hoss Man
Priority: Minor
TestReplicationHandler has a hardcoded port of 9999 in it for the "master". hardcoding port numbers in unit tests is very brittle and error prone and can cause problems. Ideally tests that aren't explicitly testing network related functionality should avoid dealing with the network at all, but when neccessary it's much better to let the OS pick any available port (as most other solr tests do) then to hardcoded it.
in TestReplicationHandler things are a little more complicated because the master port number needs to be refered to in the slave config files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-959) Remove hardcoded port numbers from
TestReplicationHandler
Posted by "Shalin Shekhar Mangar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671257#action_12671257 ]
Shalin Shekhar Mangar commented on SOLR-959:
--------------------------------------------
Thanks Hoss and Akshay.
bq. The most alarming thing at this point is that several other test methods do similar stop/start of the master, and yet they work fine (even though the slave has no knowledge of the new master port) which suggests to me that the tests may be false positives making flawed assumptions.
Hoss, perhaps the master's port did not change for these tests? It would be best to stop the slaves and re-create their solrconfig using the new master instance's port which is what Akshay has done in the latest patch.
The latest patch looks good, works well. I'll commit this shortly.
> Remove hardcoded port numbers from TestReplicationHandler
> ---------------------------------------------------------
>
> Key: SOLR-959
> URL: https://issues.apache.org/jira/browse/SOLR-959
> Project: Solr
> Issue Type: Test
> Components: replication (java)
> Reporter: Hoss Man
> Priority: Minor
> Attachments: replicationtest-port-refactor.patch, SOLR-959.patch
>
>
> TestReplicationHandler has a hardcoded port of 9999 in it for the "master". hardcoding port numbers in unit tests is very brittle and error prone and can cause problems. Ideally tests that aren't explicitly testing network related functionality should avoid dealing with the network at all, but when neccessary it's much better to let the OS pick any available port (as most other solr tests do) then to hardcoded it.
> in TestReplicationHandler things are a little more complicated because the master port number needs to be refered to in the slave config files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-959) Remove hardcoded port numbers from
TestReplicationHandler
Posted by "Akshay K. Ukey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Akshay K. Ukey updated SOLR-959:
--------------------------------
Attachment: SOLR-959.patch
Patch with re-factoring from previous patch and few more changes.
> Remove hardcoded port numbers from TestReplicationHandler
> ---------------------------------------------------------
>
> Key: SOLR-959
> URL: https://issues.apache.org/jira/browse/SOLR-959
> Project: Solr
> Issue Type: Test
> Components: replication (java)
> Reporter: Hoss Man
> Priority: Minor
> Attachments: replicationtest-port-refactor.patch, SOLR-959.patch
>
>
> TestReplicationHandler has a hardcoded port of 9999 in it for the "master". hardcoding port numbers in unit tests is very brittle and error prone and can cause problems. Ideally tests that aren't explicitly testing network related functionality should avoid dealing with the network at all, but when neccessary it's much better to let the OS pick any available port (as most other solr tests do) then to hardcoded it.
> in TestReplicationHandler things are a little more complicated because the master port number needs to be refered to in the slave config files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-959) Remove hardcoded port numbers from
TestReplicationHandler
Posted by "Shalin Shekhar Mangar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shalin Shekhar Mangar resolved SOLR-959.
----------------------------------------
Resolution: Fixed
Fix Version/s: 1.4
Assignee: Shalin Shekhar Mangar
Committed revision 741684.
Thanks Hoss and Akshay!
> Remove hardcoded port numbers from TestReplicationHandler
> ---------------------------------------------------------
>
> Key: SOLR-959
> URL: https://issues.apache.org/jira/browse/SOLR-959
> Project: Solr
> Issue Type: Test
> Components: replication (java)
> Reporter: Hoss Man
> Assignee: Shalin Shekhar Mangar
> Priority: Minor
> Fix For: 1.4
>
> Attachments: replicationtest-port-refactor.patch, SOLR-959.patch
>
>
> TestReplicationHandler has a hardcoded port of 9999 in it for the "master". hardcoding port numbers in unit tests is very brittle and error prone and can cause problems. Ideally tests that aren't explicitly testing network related functionality should avoid dealing with the network at all, but when neccessary it's much better to let the OS pick any available port (as most other solr tests do) then to hardcoded it.
> in TestReplicationHandler things are a little more complicated because the master port number needs to be refered to in the slave config files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-959) Remove hardcoded port numbers from
TestReplicationHandler
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man updated SOLR-959:
--------------------------
Attachment: replicationtest-port-refactor.patch
first pass at a refactoring to clean up the hardcoded ports -- takes advantage of the copyFile function that was already in the test to replace a marker token in the config with the real port number.
at first glance this refactoring *should* work, but testIndexAndConfigAliasReplication errors with this patch --i believe the problem is because it expects the slave to pull files from a master after the master server has been stoped and then restarted -- which fails because the new master won't have the same port number. we could try explicitly creating the new master with the same port as the old master, but there's no guarantee the os won't have already allocated that port to a new process at that point. A better solution is to eliminate the need to stop/start the master by using core reload or something similar instead.
The most alarming thing at this point is that several other test methods do similar stop/start of the master, and yet they work fine (even though the slave has no knowledge of the new master port) which suggests to me that the tests may be false positives making flawed assumptions.
unfortunately i don't have any more time to look into this at the moment ... attaching patch as a checkpoint in case someone else wants to look into it (or i get hit by a bus)
> Remove hardcoded port numbers from TestReplicationHandler
> ---------------------------------------------------------
>
> Key: SOLR-959
> URL: https://issues.apache.org/jira/browse/SOLR-959
> Project: Solr
> Issue Type: Test
> Components: replication (java)
> Reporter: Hoss Man
> Priority: Minor
> Attachments: replicationtest-port-refactor.patch
>
>
> TestReplicationHandler has a hardcoded port of 9999 in it for the "master". hardcoding port numbers in unit tests is very brittle and error prone and can cause problems. Ideally tests that aren't explicitly testing network related functionality should avoid dealing with the network at all, but when neccessary it's much better to let the OS pick any available port (as most other solr tests do) then to hardcoded it.
> in TestReplicationHandler things are a little more complicated because the master port number needs to be refered to in the slave config files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.