This isn't necessarily a proton bug. Nothing in the referenced checkin
actually touches the logic around allocating/freeing error strings, it
merely causes pn_send/pn_recv to make use of pn_io_t's pn_error_t where
previously it threw away the error information. This would suggest that
there is
Good point! I'm afraid it will take me the rest of my life
to reproduce under valgrind .. but ... I'll see what I can do
In the meantime -- I'm not sure what to do with a Jira if the
provenance is in doubt...
- Original Message -
This isn't necessarily a proton bug. Nothing in
[
https://issues.apache.org/jira/browse/PROTON-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336569#comment-14336569
]
Rajkumar commented on PROTON-614:
-
Does anyone know why this error is coming? I am getting
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 put
On Wed, Feb 25, 2015 at 9:53 AM, Alan Conway acon...@redhat.com wrote:
On Wed, 2015-02-25 at 09:04 -0500, Michael Goulish wrote:
Good point! I'm afraid it will take me the rest of my life
to reproduce under valgrind .. but ... I'll see what I can do
Try this in your environment:
Would it be safe to assume that any operations on driver-io are not
thread safe?
Dispatch is a multi-threaded application. It looks to me as though
io-error is a resource shared across the threads in an unsafe way.
-Ted
On 02/25/2015 08:55 AM, Rafael Schloming wrote:
This isn't
On Wed, Feb 25, 2015 at 10:49 AM, Ted Ross tr...@redhat.com wrote:
Would it be safe to assume that any operations on driver-io are not
thread safe?
Dispatch is a multi-threaded application. It looks to me as though
io-error is a resource shared across the threads in an unsafe way.
On 02/25/2015 11:52 AM, Rafael Schloming wrote:
On Wed, Feb 25, 2015 at 10:49 AM, Ted Ross tr...@redhat.com wrote:
Would it be safe to assume that any operations on driver-io are not
thread safe?
Dispatch is a multi-threaded application. It looks to me as though
io-error is a resource
A pn_io_t is heavyweight in Windows, because it has an opposite usage
pattern and moves a lot of kernel stuff into user space compared to
POSIX.
The quoted documentation was my attempt to capture the Dispatch usage
pattern, which I assumed would be typical of an application trying to
spread
I plan to start working on a go golang.org binding for proton. I
envisage a SWIG binding similar to the other swig-based bindings
(python, ruby, etc.) and an API layer similar to the new reactive Python
API (based on the C reactor.)
This will be an exploratory effort to begin with, I'd like to
[
https://issues.apache.org/jira/browse/PROTON-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336824#comment-14336824
]
michael goulish commented on PROTON-826:
It looks like the problem here is just
Alan Conway created PROTON-827:
--
Summary: Reactive client binding for the go programming language.
Key: PROTON-827
URL: https://issues.apache.org/jira/browse/PROTON-827
Project: Qpid Proton
On Wed, Feb 25, 2015 at 12:48 PM, Ted Ross tr...@redhat.com wrote:
On 02/25/2015 11:52 AM, Rafael Schloming wrote:
On Wed, Feb 25, 2015 at 10:49 AM, Ted Ross tr...@redhat.com wrote:
Would it be safe to assume that any operations on driver-io are not
thread safe?
Dispatch is a
Maybe my head is just thick today, but even staring at the docs a couple
times and reading through what you have below, I can't say I quite
understand what you're going for. What are the actual constraints for the
windows APIs and what is the heavyweight stuff pn_io_t is doing?
--Rafael
On Wed,
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
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 very
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
Ken Giusti created PROTON-828:
-
Summary: Python binding does not support MODIFIED delivery state
Key: PROTON-828
URL: https://issues.apache.org/jira/browse/PROTON-828
Project: Qpid Proton
Issue
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
+1
Have you thought about how to integrate Go channels with AMQP links?
Richard
On Wed, Feb 25, 2015 at 12:13 PM, Alan Conway acon...@redhat.com wrote:
I plan to start working on a go golang.org binding for proton. I
envisage a SWIG binding similar to the other swig-based bindings
(python,
Alan Conway created PROTON-829:
--
Summary: Possible reference counting bug in pn_clear_tpwork
Key: PROTON-829
URL: https://issues.apache.org/jira/browse/PROTON-829
Project: Qpid Proton
Issue
[
https://issues.apache.org/jira/browse/PROTON-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14338047#comment-14338047
]
ASF subversion and git services commented on PROTON-818:
Commit
[
https://issues.apache.org/jira/browse/PROTON-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336311#comment-14336311
]
ASF subversion and git services commented on PROTON-824:
Commit
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
24 matches
Mail list logo
