ApacheCon North America 2015

2015-02-25 Thread Rafael Schloming
Hi Everyone, I'll be attending ApacheCon in April. I was wondering if there are others that plan to go and if so would there be any interest in having an informal BOF/hackathon/get-together either during the conference or after hours? --Rafael

Re: Proposed SASL changes (API and functional)

2015-02-25 Thread Andrew Stitcher
On Tue, 2015-02-24 at 15:48 -0500, Andrew Stitcher wrote: > ... > If you are at all interested please go and look at the proposal and > comment on it there. Thank you very much to Alan and Jakub for commenting on my proposal. The reason I asked people to comment over on the wiki is that it is ver

Re: Proposed SASL changes (API and functional)

2015-02-25 Thread Andrew Stitcher
On Wed, 2015-02-25 at 10:27 +0100, Jakub Scholz wrote: > ... > But I find this part a bit dangerous: > "Classically in protocols where SASL was not optional the way to avoid > double authentication was to use the EXTERNAL SASL mechanism. With AMQP, > SASL is optional, so if SSL is used for client a

Re: Proposed SASL changes (API and functional)

2015-02-25 Thread Andrew Stitcher
On Wed, 2015-02-25 at 10:46 -0500, Alan Conway wrote: > ... > One ignorant question: Qpid has a min/max "Security Strength Factor" for > encryption rather than a binary enable/disable. Is that relevant here? (Hardly an ignorant question!) You make a very good point, and this design may indeed be a

Re: towards releasing the new AMQP 1.0 JMS client

2015-02-25 Thread Rob Godfrey
Personally I'd probably release that client independently from the rest of the java tree unless we happened to coincidentally want a patch release of the rest of the Java tree at the same time. Post 0.32 I think we are probably thinking of doing incremental patch releases off the 0.32 branch for J

Re: towards releasing the new AMQP 1.0 JMS client

2015-02-25 Thread Robbie Gemmell
That suggestion works for me in general. The only question would be around whether the other components in the 'java' tree alongside it currently would have to be released as well (the broker and other client would also be deployed curently by the parent 'java build'), or whether you would trim the

0.32 release content preview

2015-02-25 Thread Justin Ross
The preview is available here: http://people.apache.org/~jross/qpid-site/head/releases/qpid-0.32/ http://people.apache.org/~jross/qpid-site/head/releases/qpid-0.32/release-notes.html You can edit the jira descriptions to control what appears in the final release notes. If you'd like any spe

Re: Proposed SASL changes (API and functional)

2015-02-25 Thread Alan Conway
On Tue, 2015-02-24 at 15:48 -0500, Andrew Stitcher wrote: > As many of you know I've been working on implementing a SASL AMQP > protocol layer that does more than PLAIN and ANONYMOUS for proton-c. > > I'm currently in at a point where the work is reasonably functional > (with some gaps) > > I've

0.32 unresolved issues

2015-02-25 Thread Justin Ross
There are currently 18 unresolved issues against the 0.32 release. If they are not blockers, they should be retargeted for the next release. http://s.apache.org/ZBh Thanks! Justin

Re: Removing old Qpid website content

2015-02-25 Thread Justin Ross
Thanks, Robbie. I didn't end up making a tag. The site code doesn't have a {trunk,branches,tags} structure. For the record, if anyone would like to access the site content before these removals, use revision 1662227. After the deletions, the checkout is down to 970 megabytes. On Fri, Feb 20, 2

Issue with request/response pattern / multithread

2015-02-25 Thread Manuel CISSÉ
Hello, I'm using the request / response pattern with qpid 0.16 as described in the documentation[1]. I'm using timeouts in the fetch calls. My problem is that if 2 threads are making requests to the server, sometimes (maybe every 10 requests) the fetch call of the client waits for the timeou

Re: Proposed SASL changes (API and functional)

2015-02-25 Thread Jakub Scholz
Hi Andrew, I'm definitely not a Proton expert, so please excuse me if I missed something. But I find this part a bit dangerous: "Classically in protocols where SASL was not optional the way to avoid double authentication was to use the EXTERNAL SASL mechanism. With AMQP, SASL is optional, so if S