From users-return-18655-archive-asf-public=cust-asf.ponee.io@qpid.apache.org Mon Apr 16 19:11:54 2018 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 [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id C863E180608 for ; Mon, 16 Apr 2018 19:11:53 +0200 (CEST) Received: (qmail 80865 invoked by uid 500); 16 Apr 2018 17:11:52 -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 80841 invoked by uid 99); 16 Apr 2018 17:11:52 -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; Mon, 16 Apr 2018 17:11:52 +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 936D3C013E for ; Mon, 16 Apr 2018 17:11:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_HI=-5, 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 (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 2E25HuDWviog for ; Mon, 16 Apr 2018 17:11:50 +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 5EFCF5FE39 for ; Mon, 16 Apr 2018 17:11:50 +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 D90EA8046E for ; Mon, 16 Apr 2018 17:11:49 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-71.phx2.redhat.com [10.3.116.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7970E5E9D1 for ; Mon, 16 Apr 2018 17:11:49 +0000 (UTC) Subject: Re: Proposed Feature Removal from Dispatch Router To: users@qpid.apache.org References: <1726768165.19267411.1523648333256.JavaMail.zimbra@redhat.com> 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: Date: Mon, 16 Apr 2018 18:11:48 +0100 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, 16 Apr 2018 17:11:49 +0000 (UTC) On 16/04/18 17:39, Ken Giusti wrote: > On Mon, Apr 16, 2018 at 12:11 PM, Alan Conway wrote: >> On Mon, Apr 16, 2018 at 11:00 AM, Ken Giusti wrote: >> >>> Yeah, exactly. >>> >>> It's as if you applied a priority to each disposition in the following >>> order (highest first): >>> REJECTED >>> ACCEPTED >>> MODIFIED >>> RELEASED >>> >>> The router returns the highest priority disposition from all >>> consumer's returned dispositions. >>> >>> >> What if some consumer never returns a disposition? > > Right - or classic 'slow consumer'. Without some sort of timeout > mechanism the transfer would stall indefinitely. > But doesn't the same apply for unicast? With multicast, all the messages go to all receivers, so a slow consumer will stall *all* transfers which eventually will prevent other consumers getting any more messages. One use of multicast is for a pub-sub style communication pattern where you want the publishers and subscribers to be decoupled. Allowing one subscriber to bring message flow to a halt for publishers and all other subscribers might not be desirable in those cases. > In the oslo.messaging driver, all message operations have a timeout > and TTL. In that > case the sender would abort and drop the link. Will any application > expect to wait forever? > Hold on - I meant to say "any well designed application" ;) > > >> What if all consumers never return a disposition? > > Same deal. > >> What if there are no consumers? > > We have that now - credit is never granted and a sender can block indefinitely. That is how anycast works now (if you already have credit then the messages are released). I don't think there is any credit propagation for multicast at present is there? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org