Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 95055200BFB for ; Wed, 11 Jan 2017 17:53:58 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 93CB6160B4E; Wed, 11 Jan 2017 16:53:58 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id DA18D160B3B for ; Wed, 11 Jan 2017 17:53:57 +0100 (CET) Received: (qmail 25030 invoked by uid 500); 11 Jan 2017 16:53:52 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 25018 invoked by uid 99); 11 Jan 2017 16:53:51 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Jan 2017 16:53:51 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 44638C0254 for ; Wed, 11 Jan 2017 16:53:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.379 X-Spam-Level: X-Spam-Status: No, score=0.379 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id jBTQV0sQO2My for ; Wed, 11 Jan 2017 16:53:50 +0000 (UTC) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 5F9D15F286 for ; Wed, 11 Jan 2017 16:53:49 +0000 (UTC) Received: by mail-yw0-f179.google.com with SMTP id w75so79497315ywg.1 for ; Wed, 11 Jan 2017 08:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=LHy0imjWrJ4kQ22OL9fDhvyCTAITsKCqrS9qfkS/aGY=; b=QIZd4cwlEy5B2yPEVayoI/k+PYEPdrBIFQ7EhGUrN7gRiliDd9ARhZiaTaurCY/ybd HxKmwFi+/U7DnaaF50EsYG0krVIMDzPq1r8+eAg9+MJ+VHIph8gO9aXN5QqBKDAfgSeU GtwcgBqylcjEGQsQ/nfU/Z/5BKnFrdZ1Rg3/2uqNPUcRzs/5HyKnQlZcDXwD9cwvZLi/ OGYxOY+UNIka0uV/znnALQG/y1nkQbWW4FbG9uRdo4xz+dQRASFq1hTv9dNWZxBUQVXN +XOwAc6++5Vh41VHyViShU9AW6fZ18BDbrZdM6KNMYrQuHL3n5p4D2d2ogPYM7y0R5v6 Tprw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=LHy0imjWrJ4kQ22OL9fDhvyCTAITsKCqrS9qfkS/aGY=; b=VuEDQR6CbTk81mqP20x6lPqviIalEpDFmCga84zGQcCE+XIZ9iYIk1kqyvtBdk1xSb +srxb6gtEq9UBmNQz0nHAUydpNHMre7g387luWOvHLbpk4oPW8Ztzk/xgFcF6FYUReoR Hnw/zKrgEa1m3X1iXxV7vF+ft5oIfUq/dgmGVCyuw+tFluHDizEIh7TRZdgZMKlfoGjA MQtl6scnrtd/rnBw9kkFGh39IaWgvi/7M+RQpYggL+2npGj0RcFq4KHG559/X/3lRYd0 rfp1Fl201y2gl3TnEbDb71A0M8wb0uW8l0NCPBc5GVqChWqJ2uhsExyvChaSD3Gmbyzd QQ+w== X-Gm-Message-State: AIkVDXI9n5gSQWXvySRJ6HGege+bBuPmtp6Vtlsnx3H1fqPGnWWrWvNhhT/tGzldpftnCPWNqaDd1NqtY0tX4g== X-Received: by 10.13.204.23 with SMTP id o23mr7588116ywd.47.1484153626513; Wed, 11 Jan 2017 08:53:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.116.77 with HTTP; Wed, 11 Jan 2017 08:53:45 -0800 (PST) In-Reply-To: References: From: Clebert Suconic Date: Wed, 11 Jan 2017 11:53:45 -0500 Message-ID: Subject: Re: Artemis question on JMS clustered topic and high availability To: users@activemq.apache.org Content-Type: text/plain; charset=UTF-8 archived-at: Wed, 11 Jan 2017 16:53:58 -0000 when you have a topic subscription in cluster.. the message will be copied to every subscription on the cluster connection (or network of brokers)... When you have the same subscription among different nodes.. (that is... the same core-queue name on more than one node), then load-balancing will have a play... what you are looking is having a copy of the topic subscription on every node, making it a single cluster among different nodes, and that's not what you have here. You would need a backup to save the acks between two servers. you can have multiple master/slaves on your environment, and even cross them on a colocated environment, having a phisical server with 2 live nodes in case of failures. Don't know if that helps? On Tue, Jan 3, 2017 at 2:30 PM, Bruce Ritchie wrote: > I've been investigating switching from a single activemq server to a > cluster of artemis servers on aws and I have a question on clustered jms > topics and high availability. > > Firstly, I like the idea that the producers/consumers can connect to any > node in the cluster and fail over (client side) to a different node if a > node goes down without loosing any messages with the understanding that the > producers may have to retry submissions. > > In my usage scenario I do not have any queues - just two jms topics. > Multiple producers, multiple consumers. What I've been trying to figure out > is if I can away with not having a . The clustered topic example > seems to indicate that with a message-load-balancing set to STRICT that > it'll copy messages to other nodes in the cluster if a corresponding topic > already exists there. My understanding from reading the docs is that this a > true copy (potentially async I assume) vs something like a read-through > from one node to another when the message doesn't exist on the local node. > Is that correct? > > If the above is correct and the fact that I don't have a requirement to be > able to recover messages after a full cluster restart is there any reason > to have a ha-policy set? The only reason I can think of is to sync messages > in the topic between shutdown and restart of a node in the cluster prior to > clients reconnecting to that node so that the client(s) may not miss > messages (potential dup are ok in my use case). That's pretty important but > I'm not sure I have can both the clustered jms topics in a symmetrical > cluster and have a ha-policy (ala [master0/slave1] <--> [master1/slave0]). > Is that possible? > > Thanks! -- Clebert Suconic