activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-1112) EmbeddedJMS.start() doesn't return if shared-store master starts as backup server
Date Wed, 03 May 2017 15:51:04 GMT

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

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

GitHub user bgutjahr opened a pull request:

    https://github.com/apache/activemq-artemis/pull/1246

    ARTEMIS-1112: Added wait-for-activation option to shared-store master config

    Added a wait-for-activation option to shared-store master HA policies.
    This option is enabled by default to ensure unchanged server startup behavior.
    
    If this option is enabled, ActiveMQServer.start() with a shared-store master server will
not return
    before the server has been activated.
    If this options is disabled, start() will return after a background activation thread
has been started.
    The caller can use waitForActivation() to wait until server is activated, or just check
the current activation status.
    
    This is slightly different from the previous proposal of having a wait-for-failback option
to just run backup startup in the background in case there is already another live server
running. The implementation for the previous idea had a race condition: if 2 masters were
started simultaneously, both might not see the other and one would still infinitely wait to
obtain the live lock. So my new solution is to decouple startup into a background activation
thread in all cases, similar to how a backup server is started. I have called the option wait-for-activation
to be aligned with the waitForActivation() method.
    
    Please run the integration tests, since many of then fail on Windows. I hope I didn't
break something else.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/bgutjahr/activemq-artemis enhanced-shared-store

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/activemq-artemis/pull/1246.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1246
    
----
commit 481486d14c4a9f27ba55ec31bcda188e4aaa9542
Author: Bernd Gutjahr <bernd.gutjahr@hpe.com>
Date:   2017-05-03T12:46:47Z

    ARTEMIS-1112: Added wait-for-activation option to shared-store-master config
    
    Added a wait-for-activation option to shared-store master HA policies.
    This option is enabled by default to ensure unchanged server startup behavior.
    
    If this option is enabled, ActiveMQServer.start() with a shared-store master server will
not return
    before the server has been activated.
    If this options is disabled, start() will return after a background activation thread
has been started.
    The caller can use waitForActivation() to wait until server is activated, or just check
the current activation status.

----


> 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)

Mime
View raw message