-1037
--Rafael
commit 115bd26cbc5501d5bbf850fb8b7811aaf17ba507
Author: Rafael Schloming r...@alum.mit.edu
Date: Tue Jul 21 12:22:14 2015 -0400
Release 0.10
commit 8f82638b7e8299c8c3544516e4b8a18d185d3325
Author: Kenneth Giusti kgiu...@apache.org
Date: Mon Jul 20 15:08:54 2015 -0400
, 2015 12:03:06 PM
Subject: Re: proton 0.10 blocker
On 17 July 2015 at 23:32, Gordon Sim g...@redhat.com wrote:
On 07/17/2015 10:04 PM, Rafael Schloming wrote:
On Fri, Jul 17, 2015 at 12:47 PM, Gordon Sim g...@redhat.com wrote:
On 07/17/2015 08:15 PM, Rafael Schloming wrote
so I wouldn't block it if it is an
effective workaround, but it would be helpful to see the stack trace to figure
out what is actually going on.
- Rafael Schloming
On July 15, 2015, 3:55 p.m., Gordon Sim wrote
Hi Gordon,
I did my best to dump some useful info on the refcounting stuff in the
other thread. I also posted a comment on the review. As I said there it
would be helpful to see the stack trace from the crash in order to figure
out if the fix is merely a workaround.
--Rafael
On Wed, Jul 15,
On Fri, Jul 17, 2015 at 11:56 AM, Gordon Sim g...@redhat.com wrote:
On 07/17/2015 07:17 PM, Rafael Schloming wrote:
Given this I believe the incref/decref pair is indeed running into
problems
when being invoked from inside a finalizer. I'd be curious if an
alternative fix would work. I
specific state.
--Rafael
On Fri, Jul 17, 2015 at 10:12 AM, Gordon Sim g...@redhat.com wrote:
On 07/17/2015 05:36 PM, Rafael Schloming wrote:
Hi Gordon,
I did my best to dump some useful info on the refcounting stuff in the
other thread. I also posted a comment on the review. As I said
On Fri, Jul 17, 2015 at 12:47 PM, Gordon Sim g...@redhat.com wrote:
On 07/17/2015 08:15 PM, Rafael Schloming wrote:
On Fri, Jul 17, 2015 at 11:56 AM, Gordon Sim g...@redhat.com wrote:
On 07/17/2015 07:17 PM, Rafael Schloming wrote:
Given this I believe the incref/decref pair is indeed
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/34511/#review84645
---
Ship it!
Ship It!
- Rafael Schloming
On May 21, 2015, 12:13 a.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/34229/#review83914
---
Ship it!
Ship It!
- Rafael Schloming
On May 15, 2015, 9:40 a.m
On May 6, 2015, 5:49 p.m., Rafael Schloming wrote:
proton-c/src/reactor/acceptor.c, line 95
https://reviews.apache.org/r/33902/diff/1/?file=951321#file951321line95
Any particular reason to make this a weakref?
Gordon Sim wrote:
I initially made it a PN_OBJECT
Hi Gordon,
Sorry about the late comment on the review. I think you want PN_VOID, not
PN_WEAKREF. I thought I had replied promptly, but apparently I had
forgotten to click publish and so my comment lingered in reviewboard for
quite a while.
--Rafael
On Thu, May 14, 2015 at 8:34 AM,
/#comment133486
Any particular reason to make this a weakref?
- Rafael Schloming
On May 6, 2015, 5:37 p.m., Gordon Sim wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33902
The recent landing of the Go changes make me think that we should be more
explicit about our development process with respect to new language
bindings (or possibly in general). There are two problems I would like to
address.
First, a bunch of code just landed on trunk without prior
/33758/#comment133046
This shouldn't close at all, pn_do_error will send a close frame if
necessary. This call is mutating the local top-half endpoint state which makes
no sense here.
- Rafael Schloming
On May 1, 2015, 5:34 p.m., michael goulish wrote
optimization and
render this one all but inert.
- Rafael Schloming
On May 1, 2015, 9:59 a.m., Gordon Sim wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33750
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33623/#review81958
---
Ship it!
Ship It!
- Rafael Schloming
On April 29, 2015, 11:53
to deterministically recreate the collisions resulting
in this bug.
- Rafael Schloming
On April 28, 2015, 12:50 p.m., Gordon Sim wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r
are complete before
that can happen.
- Rafael Schloming
On April 28, 2015, 10:57 a.m., Gordon Sim wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33623
is also aborting with the assert failure.
It occurs to me if we install a handler for the abort signal and print a
stack trace then it would be a lot more obvious what is going on here.
- Rafael Schloming
On April 28, 2015, 6:35 p.m., Gordon Sim wrote
this area for detach/reattach
semantics, but we can cross that bridge when we come to it.
- Rafael Schloming
On April 17, 2015, 11:24 a.m., Gordon Sim wrote:
---
This is an automatically generated e-mail. To reply, visit:
https
. To reply, visit:
https://reviews.apache.org/r/33304/
---
(Updated April 17, 2015, 1:17 p.m.)
Review request for qpid, Alan Conway, Gordon Sim, Rafael Schloming, and
Robbie Gemmell.
Bugs: PROTON-490
https://issues.apache.org/jira
://reviews.apache.org/r/33304/#comment130374
This next stuff looks suspicious to me, porticularly if this is indeed a
mechanical change resulting from the 2to3 tool.
Is this really supposed to recursively call itself in this way?
- Rafael Schloming
On April 17, 2015, 1:17 p.m., Kenneth Giusti wrote
Hi Alan,
It's nice to see work starting in this area.
I'm wondering what your plan is in terms of timeline. I'm thinking if you
aren't explicitly targeting this for the 0.9 release, then maybe a feature
branch would be in order, just until we branch for the release? Otherwise
we may end up with
On Tue, Feb 24, 2015 at 8:25 AM, Alan Conway acon...@redhat.com wrote:
On Tue, 2015-02-24 at 07:59 -0500, Rafael Schloming wrote:
This commit doesn't make sense to me for a couple of reasons. First, the
way applications deal with the effects of events *is* by handling them.
Secondly
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30898/#review73279
---
Ship it!
Ship It!
- Rafael Schloming
On Feb. 19, 2015, 8:26 p.m
On Feb. 12, 2015, 3:11 p.m., Rafael Schloming wrote:
tests/tools/apps/c/reactor-recv.c, line 300
https://reviews.apache.org/r/30898/diff/1/?file=861148#file861148line300
Why are you creating a new handler for each incoming connection? Unless
the handler holds per connection state
On Fri, Feb 20, 2015 at 11:29 AM, Chuck Rolke cro...@redhat.com wrote:
It's not working because of an admin setting and not a functional error.
Would you consider skipping tests that can't open 5678?
Sure, if there's a good way to catch the error that won't mask anything
else, then you can
Parents: e2f5844
Author: Rafael Schloming r...@alum.mit.edu
Authored: Sun Jan 11 08:43:46 2015 -0500
Committer: Rafael Schloming r...@alum.mit.edu
Committed: Sun Jan 11 08:43:46 2015 -0500
--
proton-c
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31112/#review72726
---
Ship it!
Ship It!
- Rafael Schloming
On Feb. 17, 2015, 2:26 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31090/#review72636
---
Ship it!
Ship It!
- Rafael Schloming
On Feb. 16, 2015, 5:23 p.m
I believe this commit broke the javascript build. I'm guessing you didn't
have the javascript build enabled when you tested this?
--Rafael
On Mon, Feb 16, 2015 at 2:20 PM, g...@apache.org wrote:
Repository: qpid-proton
Updated Branches:
refs/heads/master cb5023d60 - 913a6fb6b
...@redhat.com wrote:
On 02/16/2015 08:09 PM, Rafael Schloming wrote:
I believe this commit broke the javascript build. I'm guessing you didn't
have the javascript build enabled when you tested this?
Sorry! The BUILD_JAVASCRIPT is indeed off - I assume that is because of
some missing
overall to use
a single handler for this purpose.
- Rafael Schloming
On Feb. 12, 2015, 2:58 a.m., Cliff Jansen wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30898
On Feb. 2, 2015, 9:41 p.m., Rafael Schloming wrote:
proton-j/src/main/java/org/apache/qpid/proton/amqp/transport2/Flow.java,
line 217
https://reviews.apache.org/r/30379/diff/2/?file=843887#file843887line217
I'm not sure we should do this kind of validation here. This is really
/TypeRegistry.java
https://reviews.apache.org/r/30379/#comment115886
DescriptorRegistry might be a bit more precise as a name for this
- Rafael Schloming
On Feb. 2, 2015, 6:38 p.m., rajith attapattu wrote:
---
This is an automatically
also work fine.
Thanks,
Rafael Schloming
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30438/#review70343
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 30, 2015, 1:46 a.m
On Jan. 27, 2015, 7:37 p.m., Rafael Schloming wrote:
proton-c/bindings/python/proton/__init__.py, line 2701
https://reviews.apache.org/r/30318/diff/1/?file=836290#file836290line2701
This seems to change the semantics of send in a subtle but odd way. If
you pass in something
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30318/#review70001
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 28, 2015, 12:17
On Jan. 27, 2015, 7:37 p.m., Rafael Schloming wrote:
proton-c/bindings/python/proton/__init__.py, line 2701
https://reviews.apache.org/r/30318/diff/1/?file=836290#file836290line2701
This seems to change the semantics of send in a subtle but odd way. If
you pass in something
, since you could just have a general
purpose decoder that holds a map from a descriptor to a factory. Then in your
decoder when you get the descriptor callback you can lookup and construct the
appropriate Encodable and delegate to it.
- Rafael Schloming
On Jan. 28, 2015, 8:04 p.m., rajith
please ignore
This looks like a pretty isolated change. If you want to pull it in prior
to 0.9, I would be in favor of getting it in sooner rather than later.
--Rafael
On Tue, Jan 27, 2015 at 11:18 AM, dnwe g...@git.apache.org wrote:
GitHub user dnwe opened a pull request:
On Tue, Jan 27, 2015 at 2:38 PM, Fraser Adams fraser.ad...@blueyonder.co.uk
wrote:
Hi Dominic,
I guess that my main concern is the potential for confusion :-)
I'm actually a bit curious/confused - when I took a peek at the patch
there wasn't much in there and looked mostly makefile related,
On Jan. 27, 2015, 7:37 p.m., Rafael Schloming wrote:
proton-c/bindings/python/proton/__init__.py, line 2701
https://reviews.apache.org/r/30318/diff/1/?file=836290#file836290line2701
This seems to change the semantics of send in a subtle but odd way. If
you pass in something
On Tue, Jan 27, 2015 at 4:03 PM, Gordon Sim g...@redhat.com wrote:
On 01/27/2015 07:38 PM, Fraser Adams wrote:
Hi Dominic,
I guess that my main concern is the potential for confusion :-)
I'm actually a bit curious/confused - when I took a peek at the patch
there wasn't much in there and
: 081336f24c62253d2ea702ffb43235a2afa75771
Parents: fc66f4c
Author: Rafael Schloming r...@alum.mit.edu
Authored: Tue Jan 13 14:23:22 2015 -0500
Committer: Rafael Schloming r...@alum.mit.edu
Committed: Tue Jan 13 14:27:35 2015 -0500
[...]
The change below breaks the API, is that deliberate? It will affect at
least
: ebe4e3d3676d8fcceb3016d7e0b2abb2deff7927
Parents: 86e08ba
Author: Rafael Schloming r...@alum.mit.edu
Authored: Sun Jan 4 22:38:28 2015 -0500
Committer: Rafael Schloming r...@alum.mit.edu
Committed: Sun Jan 4 22:38:28 2015 -0500
--
proton-c
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29637/#review66981
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 6, 2015, 8:57 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29636/#review66982
---
Ship it!
Ship It!
- Rafael Schloming
On Jan. 6, 2015, 8:51 p.m
On Tue, Jan 6, 2015 at 3:36 PM, Gordon Sim g...@redhat.com wrote:
On 01/06/2015 07:39 PM, Rafael Schloming wrote:
Hey, I made a bunch of updates to them, can you do a pull and see if this
is still an issue?
That seems to fix it. (A separate issue I just discovered by accident
Hi Alan,
I'm seeing a whole bunch of errors like this which I believe are a result
of this commit:
Exception AttributeError: 'Selectable' object has no attribute '_impl'
in bound method Selectable.__del__ of proton.Selectable object at
0x122d810 ignored
As an aside, I've just pushed a change
Hi Alan,
Sorry to pick on you again, but it looks like this commit broke the build
when you have javascript enabled:
/home/rhs/proton/proton-c/include/proton/log.h:57:32: error: token pasting
of
',' and __VA_ARGS__ is a GNU extension [-Werror,-Wgnu]
pn_logf_impl(fmt ,
It works for me once I added log.c to the javascript build.
--Rafael
On Fri, Dec 12, 2014 at 3:50 PM, Alan Conway acon...@redhat.com wrote:
On Fri, 2014-12-12 at 09:56 -0500, Rafael Schloming wrote:
Hi Alan,
Sorry to pick on you again, but it looks like this commit broke the build
when
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770/#review64860
---
Ship it!
Ship It!
- Rafael Schloming
On Dec. 9, 2014, 11:56 a.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28928/#review64864
---
Ship it!
Ship It!
- Rafael Schloming
On Dec. 11, 2014, 4:44 a.m
On Dec. 5, 2014, 10:24 p.m., Rafael Schloming wrote:
proton-c/bindings/python/proton/__init__.py, line 3542
https://reviews.apache.org/r/28770/diff/1/?file=784021#file784021line3542
To expand on my question here, I'd also like to understand if this
__getattr__ is just
redundant now.
proton-c/bindings/python/proton/__init__.py
https://reviews.apache.org/r/28770/#comment106520
Can you point me to some examples of why you collapsed the context
namespace into the event?
- Rafael Schloming
On Dec. 5, 2014, 8:55 p.m., Gordon Sim wrote
into the event object.
- Rafael Schloming
On Dec. 5, 2014, 8:55 p.m., Gordon Sim wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28770
I commented on the pull request already, but for good measure I'll add my
Ship It! here also.
BTW, I should say despite my prior grumbles on a few of the API choices,
the change significantly improves a number of brittle areas and I'm very
happy to see this kind of work being done.
--Rafael
On
On Mon, Nov 17, 2014 at 4:48 PM, Andrew Stitcher astitc...@redhat.com
wrote:
On Mon, 2014-11-17 at 20:56 +, Gordon Sim wrote:
On 11/17/2014 08:14 PM, Andrew Stitcher wrote:
As we currently don't have reviewboard set up for Qpid Proton (since
the
git migration).
I've posted a
On Tue, Nov 18, 2014 at 1:07 PM, Andrew Stitcher astitc...@redhat.com
wrote:
On Tue, 2014-11-18 at 17:41 +, Gordon Sim wrote:
On 11/18/2014 05:29 PM, Andrew Stitcher wrote:
On Tue, 2014-11-18 at 09:35 -0500, Rafael Schloming wrote:
2. Given that we have a distinct configuration phase
On Tue, Nov 18, 2014 at 12:29 PM, Andrew Stitcher astitc...@redhat.com
wrote:
On Tue, 2014-11-18 at 09:35 -0500, Rafael Schloming wrote:
On Mon, Nov 17, 2014 at 4:48 PM, Andrew Stitcher astitc...@redhat.com
wrote:
...
There are a couple things I don't like about the API after the change
Hi Everyone,
Qpid Proton 0.8 is now officially available. You can find it here:
- http://qpid.apache.org/releases/qpid-proton-0.8/index.html
The release includes numerous bug fixes and improvements. Full details can
be found here:
-
Hi Everyone,
I'd like to try to get the proton releases to be a bit more frequent, and
I'm also trying to get a bit more up front planning into them. To that end
I've put together a quick description of what I'd propose for timeline and
scope of the next release here:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26773/#review56801
---
Ship it!
Ship It!
- Rafael Schloming
On Oct. 15, 2014, 8:22 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26142/#review54855
---
Ship it!
Ship It!
- Rafael Schloming
On Sept. 29, 2014, 6:33
://reviews.apache.org/r/26050/#comment95180
should use pni_foo for internal stuff, not pn_i_foo
Looks good to me modulo the prefix for internal stuff.
- Rafael Schloming
On Sept. 26, 2014, 11:28 a.m., bozzo bozzo wrote:
---
This is an automatically
There should be a backwards compatible pn_transport_error on trunk now.
--Rafael
On Fri, Sep 26, 2014 at 11:29 AM, Gordon Sim g...@redhat.com wrote:
On 09/26/2014 11:43 AM, Rafael Schloming wrote:
I removed it because a previous commit had changed it to just return NULL.
I figured it would
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26075/#review54666
---
Ship it!
Ship It!
- Rafael Schloming
On Sept. 26, 2014, 6:46
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26013/#review54495
---
Ship it!
Ship It!
- Rafael Schloming
On Sept. 25, 2014, 1:39
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/25790/#review53866
---
Ship it!
Ship It!
- Rafael Schloming
On Sept. 18, 2014, 8:01
The Qpid PMC has voted to grant Bozo Dragojevic commit rights to Qpid for
his long standing interest in and involvement in Proton.
Welcome Bozo, and thanks for all the contributions!
--Rafael
notice
PROTON-651 has a couple of commits on it already to do at least part of what is
in this patch.
- Rafael Schloming
On Aug. 27, 2014, 3:31 p.m., Kenneth Giusti wrote:
---
This is an automatically generated e-mail. To reply, visit
/proton-c/include/proton/sasl.h
https://reviews.apache.org/r/24381/#comment87045
I'd suggest adding a true/false parameter here. I think we do (or probably
should do that) for most other boolean options.
- Rafael Schloming
On Aug. 6, 2014, 1:27 p.m., Ted Ross wrote
by deleting from the map. To deal with that case we probably want the hashtable
data structures to be in a fully modified and in a consistent state before
calling decref.
- Rafael Schloming
On July 2, 2014, 4:18 p.m., Cliff Jansen wrote
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23122/#review47224
---
Ship it!
Ship It!
- Rafael Schloming
On July 2, 2014, 7:06 p.m
could do that by just
creating a second pn_class_t for string and just override the hash function.
- Rafael Schloming
On June 27, 2014, 7:24 a.m., Cliff Jansen wrote:
---
This is an automatically generated e-mail. To reply, visit:
https
. I withdraw my
previous comment.
- Rafael Schloming
On June 27, 2014, 7:24 a.m., Cliff Jansen wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23122
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23130/#review46894
---
Ship it!
Ship It!
- Rafael Schloming
On June 27, 2014, 5:06 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22724/#review46065
---
Ship it!
Ship It!
- Rafael Schloming
On June 18, 2014, 11:07
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22273/#review45520
---
Ship it!
+1 to andrew's comment
- Rafael Schloming
On June 11
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22231/#review44710
---
Ship it!
Ship It!
- Rafael Schloming
On June 4, 2014, 1:47 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22212/#review44645
---
Ship it!
Ship It!
- Rafael Schloming
On June 3, 2014, 5:13 p.m
, and
ConnectionEventHandler seem to all be using different terms to refer to
similar/the same thing.
- Rafael Schloming
On May 29, 2014, 3:07 p.m., rajith attapattu wrote:
---
This is an automatically generated e-mail. To reply, visit:
https
.
- Rafael Schloming
On May 30, 2014, 12:47 p.m., Kenneth Giusti wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22024
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22024/#review44363
---
Ship it!
Ship It!
- Rafael Schloming
On May 30, 2014, 12:47 p.m
) may hold no meaningful bytes.
I'm thinking a different name might better reflect the usage and also make
the split seem less ugly. Maybe pn_mem_t or something along those lines?
- Rafael Schloming
On May 29, 2014, 4:58 a.m., Andrew Stitcher wrote
to go.
- Rafael Schloming
On May 29, 2014, 4:58 a.m., Andrew Stitcher wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21929
If you're strictly concerned about C - Python interop and not concerned
with providing bindings in other languages, there are a number of other
tools that could help (cffi, ctypes, and Cython). This page lists them and
talks about some of their pros and cons:
://reviews.apache.org/r/21929/#comment78463
I believe there is a central location you can put %ignore pn_bytes_t rather
than repeating it in all the different lang.i files. Look for cproton.i
underneath include/proton
- Rafael Schloming
On May 27, 2014, 4:32 p.m., Andrew Stitcher wrote
be most useful for users if we could define broker/client
behaviour such that it is robust to randomized startup order.
--Rafael
On Mon, May 19, 2014 at 5:22 AM, Gordon Sim g...@redhat.com wrote:
On 05/15/2014 12:48 PM, Rafael Schloming wrote:
On Wed, May 14, 2014 at 4:33 PM, Alan Conway
On Mon, May 19, 2014 at 11:59 AM, Gordon Sim g...@redhat.com wrote:
On 05/19/2014 04:25 PM, Rafael Schloming wrote:
FWIW I tend to think using subscribe in that way is really a bit of an
anti-pattern because it imposes a strict ordering requirement on the
startup sequence of the various
On Mon, May 19, 2014 at 4:14 PM, Gordon Sim g...@redhat.com wrote:
On 05/19/2014 06:57 PM, Rafael Schloming wrote:
That doesn't require the same kind of synchronization, it just requires
that the client implementation doesn't internally reorder execution of the
given API requests
On Thu, May 15, 2014 at 10:35 AM, Ted Ross tr...@redhat.com wrote:
On 05/14/2014 04:12 PM, Alan Conway wrote:
I'm getting up to speed with the router code, I had a couple of
questions:
alloc.c: Do we have performance data that shows this is better than
malloc?
Modern malloc() has
On Wed, May 14, 2014 at 4:33 PM, Alan Conway acon...@redhat.com wrote:
I've been playing with Messenger and I've found I need to do this if I
want to be sure it has done what I've asked it to do:
def flush(self):
Call work() till there is no work left.
while
On Thu, May 1, 2014 at 8:14 PM, Michael Goulish mgoul...@redhat.com wrote:
- Original Message -
On 05/01/2014 08:55 PM, Rafael Schloming wrote:
On Thu, May 1, 2014 at 3:42 PM, Michael Goulish mgoul...@redhat.com
wrote:
I tried firing up my messenger-based receivers, each
, Rafael Schloming r...@alum.mit.edu wrote:
On Thu, May 1, 2014 at 8:14 PM, Michael Goulish mgoul...@redhat.comwrote:
- Original Message -
On 05/01/2014 08:55 PM, Rafael Schloming wrote:
On Thu, May 1, 2014 at 3:42 PM, Michael Goulish mgoul...@redhat.com
wrote:
I tried
On Thu, May 1, 2014 at 9:36 AM, Michael Goulish mgoul...@redhat.com wrote:
- Original Message -
On 05/01/2014 02:09 AM, Michael Goulish wrote:
I just had a successful test in which a single dispatch router
handled 100,000 unique addresses.
The router was running on
On Thu, May 1, 2014 at 10:23 AM, Michael Goulish mgoul...@redhat.comwrote:
Ah, good. Care to give a free example?
The big hammer would be:
messenger.route(*, amqp://hostname)
This will funnel every single address you use into a single link to the
anonymous terminus on the given
1 - 100 of 439 matches
Mail list logo
