From users-return-51655-archive-asf-public=cust-asf.ponee.io@activemq.apache.org Mon Jul 8 23:35:53 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id D4519180665 for ; Tue, 9 Jul 2019 01:35:52 +0200 (CEST) Received: (qmail 88162 invoked by uid 500); 8 Jul 2019 23:35:51 -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 Delivered-To: moderator for users@activemq.apache.org Received: (qmail 85647 invoked by uid 99); 8 Jul 2019 23:33:11 -0000 X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 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=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.com Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=81.3.6.162; helo=w1.tutanota.de; envelope-from=warm-sun2@tutanota.com; receiver= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tutanota.com; s=20161216; t=1562628787; bh=myQ4ygs72Hoz6cF05oFdscoRTqAbl3Vnj2TKx/g4NFI=; h=Date:From:To:Subject:From; b=GmtIqCGZVgj5B9uGUWy7EXibQP0OHpRDsfQTQvfNb2tvlz7Mir8M/s4X+mg7pn0G6 w18BD6fy1XYKaMrIM3oFkWyQdAxP8sqLfE4vMDJtwA0i3xCW2JUA/ef3bEPdjYxzXh W0FFyKa57hIBjGRw6FJhb2s9kt09Wt+zmC6jl3dzf5otmnwm5vXkslTBHd6lFYd8Ui LPpharTgxIlTIITsVuE8HRzA5/gk+WViFmVxYAwYbljPN0YQ77PV1arpaTFM4k3j7/ zLEn9P48jkbOcgboYz+9Tq/zlwuNZmA4zOaivAsrYU66i93HfVF5neBBVH45NwNhzA 52/IvVKuwA1gQ== Date: Tue, 9 Jul 2019 01:33:07 +0200 (CEST) From: To: Message-ID: Subject: Re: DR: Queue backup / replay architecture (Artemis) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16620_1712472549.1562628787146" ------=_Part_16620_1712472549.1562628787146 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I wasn't clear enough ;) We are a service provider. This particular DR scenario is: if the clients lose the data/transactions (on their end) and need a replay of the transactions (messages). Clients have independent platforms to us. (Our DR, on our sites, is having 2 data centers and replication) On traditional brokers: messages are designed to be sent and forgotten... In this scenario, described above, we are sending the message -- but want to keep a backup for 1 month, in case the client will need a replay. Is there any other more suitable pattern for this scenario? (I can't think of any and didn't find any in my research, eg EIP: Enterprise Integration Patterns). Any other pattern would involve consuming messages from the broker and storing them in some other back-end and if the clients ask for a replay -- re-enqueing the messages back on to the broker, which would be inefficient (compared to the ones I'm proposing). Would be interested in your opinions. Thanks for answering all the other questions so perfectly! Also, do you think having an option to shallow-copy messages in divert use cases like the above is a valid feature for Artemis? It would save 1/2 the disk space in our use case, because we are not transforming message bodies. ------=_Part_16620_1712472549.1562628787146--