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 2008/04/04 09:21:24 UTC
[jira] Created: (SOLR-533) make tests using JettySolrRunner more
resilient to "BindException: Address already in use"
make tests using JettySolrRunner more resilient to "BindException: Address already in use"
------------------------------------------------------------------------------------------
Key: SOLR-533
URL: https://issues.apache.org/jira/browse/SOLR-533
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man
Something to look into....
tests that use JettySolrRunner frequently fail with stack traces like this...
{code}
java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.<init>(ServerSocket.java:185)
at java.net.ServerSocket.<init>(ServerSocket.java:141)
at org.mortbay.jetty.bio.SocketConnector.newServerSocket(SocketConnector.java:78)
at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:72)
at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:252)
at org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:145)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.Server.doStart(Server.java:221)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:89)
{code}
...because they have a hardcoded port number in them. it occurred to me tonight that java.net.ServerSocket will pick a port for you automaticly if you specify a port of "0", the real port can then be accessed by getLocalPort().
we should see if passing 0 to Jetty's "Server" class works, and if in doing so we can then add a method to JettySolrRunner to introspect the actual port after starting the server (from the Jetty javadocs this seems possible by calling jettyServer.getConnectors()[0].getLocalPort() ... with some error checking of course).
then we could change all the relevant tests so that instead of a hardcoded port number, setUp assigns a value to port *after* the Jetty Server is started.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-533) make tests using JettySolrRunner more
resilient to "BindException: Address already in use"
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man updated SOLR-533:
--------------------------
Attachment: SOLR-533.patch
getLocalPort seems to work .. although it's hard to *prove* this will prevent AllreadyBoundExceptions.
checkpoint patch ... deals ith most usages of JettySolrRunner and applies same meme to JettyWebappTest 9which doesn't use JettySolrRunner but does use Jetty)
TODO: TestDistributedSearch which does some weird stuff so it needs a little more TLC to get it right.
if anyone sees a problem with this approach, speak up or i'll commit once i get TestDistributedSearch figured out.
> make tests using JettySolrRunner more resilient to "BindException: Address already in use"
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-533
> URL: https://issues.apache.org/jira/browse/SOLR-533
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Attachments: SOLR-533.patch
>
>
> Something to look into....
> tests that use JettySolrRunner frequently fail with stack traces like this...
> {code}
> java.net.BindException: Address already in use
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
> at java.net.ServerSocket.bind(ServerSocket.java:319)
> at java.net.ServerSocket.<init>(ServerSocket.java:185)
> at java.net.ServerSocket.<init>(ServerSocket.java:141)
> at org.mortbay.jetty.bio.SocketConnector.newServerSocket(SocketConnector.java:78)
> at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:72)
> at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:252)
> at org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:145)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> at org.mortbay.jetty.Server.doStart(Server.java:221)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> at org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:89)
> {code}
> ...because they have a hardcoded port number in them. it occurred to me tonight that java.net.ServerSocket will pick a port for you automaticly if you specify a port of "0", the real port can then be accessed by getLocalPort().
> we should see if passing 0 to Jetty's "Server" class works, and if in doing so we can then add a method to JettySolrRunner to introspect the actual port after starting the server (from the Jetty javadocs this seems possible by calling jettyServer.getConnectors()[0].getLocalPort() ... with some error checking of course).
> then we could change all the relevant tests so that instead of a hardcoded port number, setUp assigns a value to port *after* the Jetty Server is started.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-533) make tests using JettySolrRunner more
resilient to "BindException: Address already in use"
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man resolved SOLR-533.
---------------------------
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Hoss Man
I couldn't find any reason not to commit both of these patches.
Committed revision 647048.
> make tests using JettySolrRunner more resilient to "BindException: Address already in use"
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-533
> URL: https://issues.apache.org/jira/browse/SOLR-533
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: 1.3
>
> Attachments: SOLR-533--distrib.patch, SOLR-533.patch
>
>
> Something to look into....
> tests that use JettySolrRunner frequently fail with stack traces like this...
> {code}
> java.net.BindException: Address already in use
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
> at java.net.ServerSocket.bind(ServerSocket.java:319)
> at java.net.ServerSocket.<init>(ServerSocket.java:185)
> at java.net.ServerSocket.<init>(ServerSocket.java:141)
> at org.mortbay.jetty.bio.SocketConnector.newServerSocket(SocketConnector.java:78)
> at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:72)
> at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:252)
> at org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:145)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> at org.mortbay.jetty.Server.doStart(Server.java:221)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> at org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:89)
> {code}
> ...because they have a hardcoded port number in them. it occurred to me tonight that java.net.ServerSocket will pick a port for you automaticly if you specify a port of "0", the real port can then be accessed by getLocalPort().
> we should see if passing 0 to Jetty's "Server" class works, and if in doing so we can then add a method to JettySolrRunner to introspect the actual port after starting the server (from the Jetty javadocs this seems possible by calling jettyServer.getConnectors()[0].getLocalPort() ... with some error checking of course).
> then we could change all the relevant tests so that instead of a hardcoded port number, setUp assigns a value to port *after* the Jetty Server is started.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-533) make tests using JettySolrRunner more
resilient to "BindException: Address already in use"
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man updated SOLR-533:
--------------------------
Attachment: SOLR-533--distrib.patch
isolated patch just for TestDistributedSearch .. it had a chicken/egg problem of wanting to use the port number as the data dir name for all the shards. i had to switch to using an arbitrary shard# counter.
As successive iterations of doTest are run (each with an increased number of shards) the old dirs are reused -- but that's consistent with the existing test (where port numbers are reused)
if no objections, i'll commit both batches as soon as i have a chance to review on my own and convince myself this is all kosher.
> make tests using JettySolrRunner more resilient to "BindException: Address already in use"
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-533
> URL: https://issues.apache.org/jira/browse/SOLR-533
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Attachments: SOLR-533--distrib.patch, SOLR-533.patch
>
>
> Something to look into....
> tests that use JettySolrRunner frequently fail with stack traces like this...
> {code}
> java.net.BindException: Address already in use
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
> at java.net.ServerSocket.bind(ServerSocket.java:319)
> at java.net.ServerSocket.<init>(ServerSocket.java:185)
> at java.net.ServerSocket.<init>(ServerSocket.java:141)
> at org.mortbay.jetty.bio.SocketConnector.newServerSocket(SocketConnector.java:78)
> at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:72)
> at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:252)
> at org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:145)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> at org.mortbay.jetty.Server.doStart(Server.java:221)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> at org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:89)
> {code}
> ...because they have a hardcoded port number in them. it occurred to me tonight that java.net.ServerSocket will pick a port for you automaticly if you specify a port of "0", the real port can then be accessed by getLocalPort().
> we should see if passing 0 to Jetty's "Server" class works, and if in doing so we can then add a method to JettySolrRunner to introspect the actual port after starting the server (from the Jetty javadocs this seems possible by calling jettyServer.getConnectors()[0].getLocalPort() ... with some error checking of course).
> then we could change all the relevant tests so that instead of a hardcoded port number, setUp assigns a value to port *after* the Jetty Server is started.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.