From users-return-52847-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Wed Oct 7 12:46:36 2020 Return-Path: X-Original-To: apmail-activemq-users-archive@www.apache.org Delivered-To: apmail-activemq-users-archive@www.apache.org Received: from mxout1-he-de.apache.org (mxout1-he-de.apache.org [95.216.194.37]) by minotaur.apache.org (Postfix) with ESMTP id 46D7F1A0D5 for ; Wed, 7 Oct 2020 12:46:36 +0000 (UTC) Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mxout1-he-de.apache.org (ASF Mail Server at mxout1-he-de.apache.org) with SMTP id 46B8B64219 for ; Wed, 7 Oct 2020 12:46:35 +0000 (UTC) Received: (qmail 58094 invoked by uid 500); 7 Oct 2020 12:46:33 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 58038 invoked by uid 500); 7 Oct 2020 12:46:33 -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 58026 invoked by uid 99); 7 Oct 2020 12:46:32 -0000 Received: from spamproc1-he-de.apache.org (HELO spamproc1-he-de.apache.org) (116.203.196.100) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Oct 2020 12:46:32 +0000 Received: from localhost (localhost [127.0.0.1]) by spamproc1-he-de.apache.org (ASF Mail Server at spamproc1-he-de.apache.org) with ESMTP id 1E4DD1FF3A7 for ; Wed, 7 Oct 2020 12:46:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamproc1-he-de.apache.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamproc1-he-de.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-ec2-va.apache.org ([116.203.227.195]) by localhost (spamproc1-he-de.apache.org [116.203.196.100]) (amavisd-new, port 10024) with ESMTP id qVHHZEXViaqj for ; Wed, 7 Oct 2020 12:46:30 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.218.46; helo=mail-ej1-f46.google.com; envelope-from=fosminclorea@gmail.com; receiver= Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 42787BB8AB for ; Wed, 7 Oct 2020 12:46:30 +0000 (UTC) Received: by mail-ej1-f46.google.com with SMTP id qp15so2765743ejb.3 for ; Wed, 07 Oct 2020 05:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=uZa5HVlZQ7V2hDl5Q/KI5B1dp3BT/XudU2gIbGxxviw=; b=MbbQFwIgmf+0eP7ikJqhG06NPMbxVgRU30B+kxuee5FohRNZgUsCxj0PVdhfK2d5iC W+evonXDw6iFqZaUIyTg/G1InbvdsS6HwKtec4ramT50BB1uLh8Z4iHV6bcX83Y6DVma KTRZQoUWRRQESoD6Rj1xLaoLGdNdKlqyCALQxy6GnMpshMlIaawsED7D5idVhDjq8qii 5lRbdZ4a3G1yF6NZEdGQ983d125ipPjNjmPA3+bYgDk8DvJ05WeBB7vp6tICdFZ0VmJa 7r6jqkgbXL4xssISmTkSXbjZGU5QEtlyw1LIt4jUa3e5561zj9XjEn/MlKVSzqW19jbH 1czw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=uZa5HVlZQ7V2hDl5Q/KI5B1dp3BT/XudU2gIbGxxviw=; b=A/TIEq6vCx4kJGs1lVFP7C3mvTuX5vsayrNx8i1sCHvZ7qW6eA9IS3wdxlYrbsjv+z 4io9kpSnJJNfyE9DHrHswPWcTmX74HK4phYQN1tBZuQ8cW5T9r/YiNKABbSpd9hFhoy3 Q6RbRcnpLuLxLlXTtXfXbLyIxS22UvO4QnJtmLIJJXi2gxwLI/zyKf+GUdTsp+g4eFa+ vAEwdfvpVmEBmd99e2CJievQwSWyK8X16OWuZowhaTaLhFSZbcQMJbgKrtwzrxhUxbkh EU18dkhZ1pdjitjWVvmvWuhybEaFZGDRxk5b+G+yH0vaLt78opaIW+wwqlfc1MWQPYWY 1EmA== X-Gm-Message-State: AOAM531bBMlVtScaY/cANN1PFiH0JPrXMbDT0TnEyqkfaySfz2zrqPU2 keKow1B2ZSAET5Qj5O7JIX50g7VsU47JBQ== X-Google-Smtp-Source: ABdhPJyFD40LVuLCzWU7Cl7VoBHg1ExSbHj03WNhBZw2tR/N94hOfmznr24jQ7eA8M+adJJMP/WnOA== X-Received: by 2002:a17:906:685a:: with SMTP id a26mr3269473ejs.458.1602074788657; Wed, 07 Oct 2020 05:46:28 -0700 (PDT) Received: from ?IPv6:2a02:2f0c:710e:5500:ed76:d754:e1f2:4445? ([2a02:2f0c:710e:5500:ed76:d754:e1f2:4445]) by smtp.gmail.com with ESMTPSA id v2sm1452763ejh.57.2020.10.07.05.46.27 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2020 05:46:28 -0700 (PDT) To: users@activemq.apache.org From: Cosmin Petre Florea Subject: ActiveMQ advisory message and failover Message-ID: <03f11365-23f4-5e28-7c8d-d822446da748@gmail.com> Date: Wed, 7 Oct 2020 15:46:26 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------927E6C9567BE5F8A623AA0F5" Content-Language: en-US --------------927E6C9567BE5F8A623AA0F5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi,  We are using ActiveMQ C++ library with failover transport. We have:  - 2  brokers configured in "shared file system master slave" (only 1 is active at a time) -  2 clients connected to the active broker Broker_1:     Client_1 has a consumer for |ActiveMQ.Advisory.Consumer.Topic|     Client_2 has a consumer C2 for Topic_2;  When Client_1 finds out that C2 is no longer a consumer on Topic_2 (via ConsumerInfo/RemoveInfo), Client_1 assumes that Client_2 has suddenly died and stops communication with Client_2. We want that to happens only when Client_2 is down.  If the Broker_1 is up and Client_2 stops, Client_1 receives the RemoveInfo and everything OK.  if Broker_1 goes down and Client_1 and Client_2 keep running but move to Broker_2, then Client_1 receives a RemoveInfo + ConsumerInfo for C2 and the  content of the advisory is the same as when the Client_2 actually went down  (we don't know by just reading the Advisory message if the broker went down or the client went down). We noticed that, at failover, we receive in Client_1 first a RemoveInfo, then a TransportListener::transportInterrupted() so in order to "ignore" the RemoveInfo , we don't process it when it arrives, but wait (N milliseconds) to see if transportInterrupted() is called too. This works almost all the time, only that under heavy loads the distance in time between the 2 events tends to get bigger than our configured N (sometimes more than 3 seconds), so maybe we need something else. Do you know of any approach to distinguish between a client failure and a broker failure when failover is activated? Is there a "separated" channel for advisory messages or they are sent in the same stream as regular data? How reliable are the advisory messages sent during failover - should we always expect a RemoveInfo+ConsumerInfo (sometimes we don't receive the ConsumerInfo, don't know if bug in our application)? Thank you, Cosmin --------------927E6C9567BE5F8A623AA0F5--