Return-Path: X-Original-To: apmail-storm-user-archive@minotaur.apache.org Delivered-To: apmail-storm-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 364E910D21 for ; Fri, 4 Apr 2014 18:01:50 +0000 (UTC) Received: (qmail 37525 invoked by uid 500); 4 Apr 2014 18:01:46 -0000 Delivered-To: apmail-storm-user-archive@storm.apache.org Received: (qmail 37125 invoked by uid 500); 4 Apr 2014 18:01:42 -0000 Mailing-List: contact user-help@storm.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@storm.incubator.apache.org Delivered-To: mailing list user@storm.incubator.apache.org Received: (qmail 36225 invoked by uid 99); 4 Apr 2014 18:01:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Apr 2014 18:01:41 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of montedong@gmail.com designates 209.85.216.41 as permitted sender) Received: from [209.85.216.41] (HELO mail-qa0-f41.google.com) (209.85.216.41) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Apr 2014 18:01:35 +0000 Received: by mail-qa0-f41.google.com with SMTP id j5so3494335qaq.28 for ; Fri, 04 Apr 2014 11:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=eMduaeo39TeNhoaDLYh7wm3qE+mysD1aaORenXNhw+E=; b=UAoqvJtyEl6BDiQNlr4fjNWoiFKuUcB5afPV+OGlXKdui2WQf+JPZJCuM96pgZshOL motT2i4bJvL0j55C2F5x1JL9PGpRJHxvA6n8q4q6HLo4PCUHuCwCoIbjLAab5DPd4q2q hZw71MsVPZhAGHutfpGVvzCKlSZjYJZIj4rLYnydCj5h2iZ8JGi3g/HqXMn6ZXbKuJfW 9x45UR/mLA7GdzlKm/r0r3GjYLpF7SYupXN/fXTj9n0UAHhMqymoVOIWC2iyQiCWfs5y YeVk1PdAfd7GQm39Xo3NHyOsmbN8Y9JHaIWD114wueqvOUgcodm6TF6XhJ7nIrV4/hRn 4Yow== MIME-Version: 1.0 X-Received: by 10.224.131.67 with SMTP id w3mr16250245qas.32.1396634473697; Fri, 04 Apr 2014 11:01:13 -0700 (PDT) Received: by 10.96.20.167 with HTTP; Fri, 4 Apr 2014 11:01:13 -0700 (PDT) Date: Fri, 4 Apr 2014 13:01:13 -0500 Message-ID: Subject: Tuple queuing mechanism in storm From: Dong Mo To: user@storm.incubator.apache.org Content-Type: multipart/alternative; boundary=001a11c2c262afb2de04f63b4d3e X-Virus-Checked: Checked by ClamAV on apache.org --001a11c2c262afb2de04f63b4d3e Content-Type: text/plain; charset=ISO-8859-1 Dear list, I would like to know how tuple queuing works in Storm. What is the semantic of emit() exactly when it returns? Does a returned emit mean that the tuple is successfully delivered to the destination or that a tuple is delivered to this bolt's local sending queue waiting for delivery over the network? Is that a blocking function or it has no reliable delivery guarantee at all? More generally, how does storm's receiving and sending queue mechanism works? Say I have a boltA emitting words very quickly and it is connected to another boltB which do super complicated encryption on the words and thus is very slow. In this scenario, where does the "queue" get built up and where does the tuple drop happen? Will boltA get blocked also because the blocking emit? Or boltA will just emit tuple with reliably delivery in sense of TCP and the receiving queue of BoltB will get overflowed? Thanks -Mo --001a11c2c262afb2de04f63b4d3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear list,

I would like to know how tup= le queuing works in Storm.

What is the semantic of = emit() exactly when it returns?
<= br>
Does a returned emit mean that the tuple is successfully delivered = to the destination or that a tuple is delivered to this bolt's local se= nding queue waiting for delivery over the network?
<= br>
Is that a blocking function or it has no reliable delivery guarante= e at all?
<= br>
More generally, how does storm's receiving and sending queue me= chanism works?
<= br>
Say I have a boltA emitting words very quickly and it is connected = to another boltB which do super complicated encryption on the words and thu= s is very slow. In this scenario, where does the "queue" get buil= t up and where does the tuple drop happen? Will boltA get blocked also beca= use the blocking emit? Or boltA will just emit tuple with reliably delivery= in sense of TCP and the receiving queue of BoltB will get overflowed?

Thanks
-Mo

--001a11c2c262afb2de04f63b4d3e--