From users-return-18228-archive-asf-public=cust-asf.ponee.io@qpid.apache.org Mon Jan 29 21:30:24 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 77FCE180654 for ; Mon, 29 Jan 2018 21:30:24 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 671EA160C31; Mon, 29 Jan 2018 20:30:24 +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 ADCAF160C2F for ; Mon, 29 Jan 2018 21:30:23 +0100 (CET) Received: (qmail 34101 invoked by uid 500); 29 Jan 2018 20:30:22 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 34090 invoked by uid 99); 29 Jan 2018 20:30:22 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Jan 2018 20:30:22 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id A1D431A31ED for ; Mon, 29 Jan 2018 20:30:21 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id GB5U0hYiMzdj for ; Mon, 29 Jan 2018 20:30:19 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 8FE425F23D for ; Mon, 29 Jan 2018 20:30:19 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1D46C7266C for ; Mon, 29 Jan 2018 20:30:19 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-56.phx2.redhat.com [10.3.116.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id B5423609B6 for ; Mon, 29 Jan 2018 20:30:18 +0000 (UTC) Subject: Re: Link handling after detach(close=false) To: users@qpid.apache.org References: From: Gordon Sim Organization: Red Hat UK Ltd, Registered in England and Wales under Company Registration No. 3798903, Directors: Michael Cunningham, Michael O'Neill, Eric Shander Message-ID: <4e58aea5-9e08-a684-0ef1-c24e1e651ee4@redhat.com> Date: Mon, 29 Jan 2018 20:30:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 29 Jan 2018 20:30:19 +0000 (UTC) On 29/01/18 17:28, Marc Pellmann wrote: > Hi, > > I work on the Eclipse Hono project, where we use the qpid router. > > In a specific situation, I am not sure about the expected behavior and hope > you can help me out. > > In our default/example setup there is a qpid router in front of a Artemis > broker and a client, which opens a receiver link to qpid (and qpid creates > a link to Artemis for this address). > > Initially all works as expected and messages, wich are send to the Artemis > address are received by the receiver. > > When the broker is killed, the qpid sends a detach with closed=false (on > this I would assume that also a detach with closed=false should be send > back from the receiver). > > If now, the broker is started again, the receiver gets no attach frame and > does not receive messages. (It gets an attach and receive messages, if it > is also restarted.) > > My expectation was, that qpid would establish the link with the broker and > send an attach frame to the receiver. > > Is the expected behavior from the receiver, that after a detach with > closed=false it need to close and try to open until the Broker is available > again? It shouldn't have to close, but it will need to try to re-attach the link. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org