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

ASF GitHub Bot commented on ARTEMIS-1112:
-----------------------------------------

Github user jbertram commented on the issue:

    https://github.com/apache/activemq-artemis/pull/1204
  
    To be clear, the issue isn't one of "backwards compatibility." The issue is 
that there are tests which rely specifically on the blocking behavior. 
Therefore, if you change the blocking behavior (i.e. remove it) then you can 
address it one of several ways...
    
    - change the tests so they don't rely on start() blocking and pass when 
start() is non-blocking
    - allow start() to block so the tests still pass and introduce a way to 
make start() non-blocking via configuration (which is what you suggested 
earlier)
    - change some other behavior to get the functionality you're looking for 
(which is what I suggested in regards to making stop() non-blocking)
    
    If you're satisfied with your current solution (i.e. checking the bindings 
directory) that's fine, but it's worth noting that this could change (but 
probably won't) at any time. In other words, you're relying on something that 
is not guaranteed.


> EmbeddedJMS.start() doesn't return if shared-store master starts as backup 
> server
> ---------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-1112
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1112
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 1.5.4, 2.0.0
>            Reporter: Bernd Gutjahr
>            Priority: Minor
>
> EmbeddedServer.start() doesn't return when a share-store master server has 
> been configured, but at startup another server is already running as live 
> server (i.e. another previously started master).
> In that case, this server becomes a backup server for the currently running 
> live server. The start() method hangs until the currently running live server 
> stops and this server actually becomes the new live server.
> This is inconsistent with starting a server as slave server, where the start 
> method returns and doesn't wait until the slave took over as live server.
> It also blocks the application that called EmbeddedServer.start() to proceed 
> it's normal operation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to