[
https://issues.apache.org/jira/browse/DERBY-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302651#comment-17302651
]
Holger Rehn edited comment on DERBY-7107 at 3/16/21, 4:16 PM:
--------------------------------------------------------------
[~bpendleton] Thank you for taking a look! Maybe I got that wrong, but for
example
{code:java}
NetworkServerControl.runtimeInfo(){code}
is only useful when called on an embedded server instance, right? And as all
other connection dependent methods of class NetworkServerControl it cannot be
called under the conditiones described above, so to me this definitly looks
like a real bug.
Our use case, however, isn't too problematic. Our application starts an
embedded server and uses
{code:java}
NetworkServerControl.ping(){code}
in a loop to wait until the server is up and running. Currently it ends up
looping until hitting an internal timeout, causing the whole application to
abort. The fix is easy, I already modified our code to ping "localhost" instead
(using reflection to set the hostAddress field). This whole topic more or less
only came up due to the increasing number of customers and emplyees in home
office that are forced to disconnect their VPN connection to be able to start
our application.
was (Author: ickzon):
[~bpendleton] Thank you for taking a look! Maybe I got that wrong, but for
example
{code:java}
NetworkServerControl.runtimeInfo(){code}
is only useful when called on an embedded server instance, right? And as all
other connection dependent methods of class NetworkServerControl it cannot be
called under the conditiones described above, so to me this definitly looks
like a real bug.
Our use case, however, isn't too problematic. Our application starts an
embedded server and uses
{code:java}
NetworkServerControl.ping(){code}
in a loop to wait until the server is up and running. Currently it ends up
looping until hitting an internal timeout, causing the whole application to
abort. The fix is easy, I already modified our code to ping "localhost" instead
(using reflection to set the hostAddress field). This whole topic more or less
only came up due to the increasing number of customers and emplyees in home
office that are forced to disconnect ther VPN connection to be able to start
our application.
> NetworkServerControl fails to connect to server started on INADDR_ANY
> ---------------------------------------------------------------------
>
> Key: DERBY-7107
> URL: https://issues.apache.org/jira/browse/DERBY-7107
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.14.2.0, 10.15.2.0
> Reporter: Holger Rehn
> Priority: Critical
>
> If starting a NetworkServerControl on INADDR_ANY (0.0.0.0) it also uses this
> address when connecting to the running server instance (e.g. in method
> ping(), ...).
> Strictly speaking, INADDR_ANY isn't a valid target address. However, under
> normal circumstances, this works anyway. But if you have any "security"
> software in place that blocks such connections (Firewall or VPN, e.g. Cisco
> AnyConnect), you end up with an IOException:
> {code}Could not connect to Derby Network Server on host 0.0.0.0, port 1527:
> Permission denied: connect.{code}
> One simple fix would be to explicitly check the host address 'hostAddress' in
> NetworkServerControlImpl.setUpSocket() and if this is INADDR_ANY, use
> 'localhost' instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
