Re: [VOTE] RC8

[x] Ship it! Rajith On Mon, Oct 29, 2012 at 9:32 PM, Rafael Schloming wrote: > I'm optimistically starting an official release vote for RC8 here. I'm > hoping if there is enough support and no procedural objections we can fudge > the 72 hour formal vote process down to 24 hours. I personally thi

[VOTE] RC8

I'm optimistically starting an official release vote for RC8 here. I'm hoping if there is enough support and no procedural objections we can fudge the 72 hour formal vote process down to 24 hours. I personally think this is reasonable because (a) it's a 0.1 release and (b) we've been at the RC thin

RC8

I've posted an RC8 here: http://people.apache.org/~rhs/qpid-proton-0.1rc8/ This is almost identical to RC7 with the following changes, mostly minor fixes shown up by interop testing: 1. added a mapping for the bool type to the python bindings (this was missing from RC7) 2. fixed the comment

[jira] [Created] (PROTON-109) Proton should handle inbound max-frame size violations.

Ken Giusti created PROTON-109: - Summary: Proton should handle inbound max-frame size violations. Key: PROTON-109 URL: https://issues.apache.org/jira/browse/PROTON-109 Project: Qpid Proton Issue T

Re: acks for messenger

For the record, I also like option (2), for the reasons that Justin articulated. -Ted On 10/26/2012 11:24 AM, Justin Ross wrote: I like option 2) for two reasons. One, it produces very straightforward semantics for the various levels of delivery guarantee. Two, it's easy to ignore if you'd

Re: acks for messenger

Am 29.10.2012 um 18:03 schrieb Rafael Schloming: think controlling whether or not the application is required to ack atthe subscription level might be a bit weird since you might or might notneed to ack a message depending on where it has come from and that could beerror prone/confusing.SwiftMQ is

Re: acks for messenger

So for configuring this capability I was thinking of something along the lines of two messenger level settings for reliability, e.g. something for incoming messages controlling at-most-once vs at-least-once vs exactly-once, and likewise for outgoing messages. I think controlling whether or not the

Re: acks for messenger

+1 to Option 2, with Rob's Messenger.ack() capability. -K - Original Message - > I'm taking a look at expanding the messenger API to support > reliability and so far there seem to be two directions to explore > which I'll attempt to describe below: > > Option 1) > > Messenger.ack(Messa