[
https://issues.apache.org/jira/browse/ARTEMIS-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214650#comment-17214650
]
Robbie Gemmell commented on ARTEMIS-2950:
-----------------------------------------
{quote}I have the following questions/comments:
* Could you confirm these are the right callbacks to hook on both for success
& failure? I couldn't find a definitive answer on the documentation.
* If I understand correctly the Netty pieces, the acceptors are also started
synchronously. So, the whole infrastructure under the hood is synchronous and
forcing _all_ clients to use an asynchronous, callback-based method also seems
suboptimal. Is there an issue with surfacing the error as before and letting
clients choose what they want to use?{quote}
I was simply commenting from recent observation of one main broker maintainer
indicating it was meant to behave that way and to use those callbacks for this
purpose (plus the JIRA+PR he mentioned/wrote that seems to show it to be true,
where another maintainers comments look to indicate the same). I cant really
confirm anything.
I think there are async areas involved in the startup, so I dont think its as
fully synchronous as you believe, plus there are the 'await activation' and
'register activation callback' style methods that further imply it isnt
synchronous, at least not always.
The main issue I see with 'surfacing the error as before and letting clients
choose' like you want, is that the other stuff so far indicates it was
unexpected it did that, and the activate failure listener clearly wasnt
intended as an either-or choice when added, as the PR shows it didnt seem to
alter the startup behaviour at all (other than also firing the listener) and it
tests the bind case doesnt throw so it presumably didnt at the time. Something
later may have changed. Or again maybe there are nuances where different
configs behave differently. I dont know, I'm not actually familiar with any of
this code, I was simply commenting to point out recent discussion I thought
could be helpful (and now somewhat wishing I hadnt hehe).
Perhaps it can be changed (though that would likely affect everything using it
expecting it to behave the current way it has for years now), or another API
added. Regardless, if there are areas in the docs you think are misleading, you
can always point that out here and/or raise a PR for that too.
> 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)
