[jira] [Comment Edited] (ARTEMIS-2950) Failure of a broker to bind to an address is not propagated

["Robbie Gemmell (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214578#comment-17214578 ] 

Robbie Gemmell edited comment on ARTEMIS-2950 at 10/15/20, 10:01 AM:
---------------------------------------------------------------------

I think it may be more nuanced than that.

It seems the startup isnt expected to be fully synchronous generally (there are various waiting methods/callbacks) and the 'new' behaviour described actually appears to be long expected, both from the recent comment I linked above and the ARTEMIS-388 Jira from 1.3.0 it referenced in turn, that actually seems to precisely match what is being asked about.

[https://github.com/apache/activemq-artemis/pull/381/files]

E.g the mentioned listener it added indicates:
{noformat} * This interface represents a way users can be alerted to activation failures that don't necessarily constitute a
 * fatal problem for the broker (e.g. the failure to start an acceptor){noformat}
You can also see in the diff cases where it was likely emitting logging of similar style to that mentioned, but then also calls the listener, and does nothing else, i.e it didnt alter the startup behaviour.

Then it included a test that does what is described here - binds a port, starts the server without exception from start() method, verifies the listener got called.

Perhaps there are different ways to start it, or perhaps the test has problems, but certainly it seems expected there, and the broker starts up from the command line in this situation also I believe also. Essentially to me it seems its the prior behaviour that was unexpected, possibly an edge case from changes during the time between 1.3.0 and then.

 

(Aside: I personally like port issues to prevent startup by default, I'm just saying it seems here that its not expected)


was (Author: gemmellr):
I think it may be more nuanced than that.

It seems the startup isnt expected to be fully synchronous generally (there are various waiting methods/callbacks) and the 'new' behaviour described actually appears to be long expected, both from the recent comment I linked above and the ARTEMIS-388 Jira from 1.3.0 it referenced in turn, that actually seems to precisely match what is being asked about.

[https://github.com/apache/activemq-artemis/pull/381/files]

E.g the mentioned listener it added indicates:
{quote} * This interface represents a way users can be alerted to activation failures that don't necessarily constitute a
 * fatal problem for the broker (e.g. the failure to start an acceptor){quote}
You can also see in the diff cases where it was likely emitting logging of similar style to that mentioned, but then also calls the listener, and does nothing else, i.e it didnt alter the startup behaviour.

Then it included a test that does what is described here - binds a port, starts the server without exception from start() method, verifies the listener got called.

Perhaps there are different ways to start it, or perhaps the test has problems, but certainly it seems expected there, and the broker starts up from the command line in this situation also I believe also. Essentially to me it seems its the prior behaviour that was unexpected, possibly an edge case from changes during the time between 1.3.0 and then.

 

(Aside: I personally like port issues to prevent startup by default, I'm just saying it seems here that its not expected)

> Failure of a broker to bind to an address is not propagated
> -----------------------------------------------------------
>
>                 Key: ARTEMIS-2950
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2950
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 2.15.0
>            Reporter: Dimos Raptis
>            Priority: Major
>
> While working on an upgrade of our dependency on {{artemis-server}} from version 2.6.2 to 2.15.0, we noticed that while a failure to bind on an address was propagating to the client before, in the newer version it does not propagate anymore.
>  
> More specifically, we are making use of the API {{ActiveMQServerImpl.start()}} that was previously throwing a netty {{NativeIoException}}, but now it is swallowing it and only logging an error instead. We are making use of this exception to react to the failure to bind and we have some automated tests around it that started failing during the upgrade. Our tests are working in the following way:
>  * We first bind a socket to a specific port.
>  * Then, we attempt to start a broker on the same port.
>  * The expectation of the test is that the start() operation will fail with an exception.
> To provide some more context, I managed to track down the ticket that introduced this change in behaviour, which is this one: https://issues.apache.org/jira/browse/ARTEMIS-2106



--
This message was sent by Atlassian Jira
(v8.3.4#803005)