Re: [VOTE] merge the proton mailing list into the users/dev lists

[Ted Ross]

+1

And a separate +1 to Rob's suggestion.

-Ted

On 03/30/2016 06:30 AM, Rob Godfrey wrote:

+1

Additionally it might make sense to write a paragraph somewhere on
suggestions for best practice on mailing the list (like including
components / languages in use in the title or the body of the e-mail :-) ).

-- Rob

On 30 March 2016 at 11:25, Robbie Gemmell  wrote:


Hello folks,

Many moons ago, a seperate mailing list was established for Proton,
back when it was purely a protocol engine other components would use.
Its scope has since expanded beyond that and the separate mailing list
has I feel been an increasing source of confusion and hassle of late
more than anything else. Collapsing it into the other larger existing
lists we have (that the traffic would otherwise have been on) seems to
me like it would be an improvement across the board, and as such I
have called this vote.

I would propose that discussion (such as this) would head to the
users@q.a.o list to join the similar/related/duplicate traffic already
present, with remaining things going to the dev@q.a.o list as
consistent with that list (e.g JIRA, GitHub integration mails,
ReviewBoard, though the latter was never actually directed to proton@
to begin with..).

Whilst redirecting JIRA etc emails should be easy enough (has been
done before), I dont know what the precise options are regarding
existing mail subscriptions to the list. There are significantly more
subscribers to users@ than proton@, and many are duplicates, but some
are not. I'd need to discuss options with infra, but first things
first, the vote.

I have gone straight to a vote on this because I feel this has already
been discussed enough previously over time that many people will have
already thought about it enough to quickly vote one way or the other,
and it is past time to act on it if things head that way. Obviously
things can be further discusssed at this point also if desired.

Note that both users@ and proton@ are in the recipients. I expect the
thread will splinter when someone forgets to reply-all, as almost all
cross-posted thread on the lists do, but at least it can start on both
for visibility to all.

Robbie

Re: Issues with Qpid dispatch make

[Ted Ross]

Hi Paul,

Which version did you download and on what platform are you attempting 
to build it?


-Ted

On 02/01/2016 05:45 PM, Paul Flores wrote:

Hi,

Downloaded qpid_dispatch.  Have run into issues with Building C object
src/CMakeFiles/qpid-dispatch.dir/compose.c.o
  at container.h ( at lines 178 and 182) along with error:
‘qd_field_location_t’ has no member named ‘parsed’ in compose (152 and
162).  I downloaded the tar file less that 30 minutes ago.

Is there a fix?

Thanks.

Paul

[jira] [Resolved] (PROTON-510) hostname field in the Open command is not set

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross resolved PROTON-510.
-
Resolution: Fixed

This is working properly as of 0.11.  I assume it was fixed much earlier but I 
haven't determined which release it was fixed in.

> hostname field in the Open command is not set
> -
>
> Key: PROTON-510
> URL: https://issues.apache.org/jira/browse/PROTON-510
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.6
>Reporter: Ted Ross
>
> If an address of the form "amqp://dns.domain.com/path" is used in 
> Proton/Messenger, when the connection is opened, the hostname field in the 
> Open should contain "dns.domain.com".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross resolved PROTON-485.
-
   Resolution: Fixed
Fix Version/s: 0.10

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Priority: Minor
> Fix For: 0.10
>
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-1088:
-
Priority: Major  (was: Minor)

> Add convenience functions to obtain the client certificate fingerprint, 
> subject subfields
> -
>
> Key: PROTON-1088
> URL: https://issues.apache.org/jira/browse/PROTON-1088
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.11.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.12.0
>
>
> 1. Provide a convenience function which will return a an ssl certificate 
> fingerprint (a sha1 or sha256 hash of the certificate). 
> -- When you look go to a https site via a web browser, you can look at the 
> certificate fingerprint by clicking the View Certificate button on the 
> browser. Add a convenience function to proton which will return the char 
> array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a 
> 32 octet hash. The function signature should approximately look like this - 
> void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* 
> digest_name)
> 2. The subject field on the SSL cert has many subfields like - 
> C = ISO3166 two character country code
> ST = state or province
> L = Locality; generally means city
> O = Organization - Company Name
> OU = Organization Unit - division or unit
> CN = CommonName - end entity name e.g. www.example.com
> Provide convenience functions to obtain values of the above subfields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-1088:
-
Assignee: Ganesh Murthy

> Add convenience functions to obtain the client certificate fingerprint, 
> subject subfields
> -
>
> Key: PROTON-1088
> URL: https://issues.apache.org/jira/browse/PROTON-1088
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.11.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 0.12.0
>
>
> 1. Provide a convenience function which will return a an ssl certificate 
> fingerprint (a sha1 or sha256 hash of the certificate). 
> -- When you look go to a https site via a web browser, you can look at the 
> certificate fingerprint by clicking the View Certificate button on the 
> browser. Add a convenience function to proton which will return the char 
> array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a 
> 32 octet hash. The function signature should approximately look like this - 
> void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* 
> digest_name)
> 2. The subject field on the SSL cert has many subfields like - 
> C = ISO3166 two character country code
> ST = state or province
> L = Locality; generally means city
> O = Organization - Company Name
> OU = Organization Unit - division or unit
> CN = CommonName - end entity name e.g. www.example.com
> Provide convenience functions to obtain values of the above subfields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-1088:
-
Fix Version/s: 0.12.0

> Add convenience functions to obtain the client certificate fingerprint, 
> subject subfields
> -
>
> Key: PROTON-1088
> URL: https://issues.apache.org/jira/browse/PROTON-1088
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.11.1
>Reporter: Ganesh Murthy
>Priority: Minor
> Fix For: 0.12.0
>
>
> 1. Provide a convenience function which will return a an ssl certificate 
> fingerprint (a sha1 or sha256 hash of the certificate). 
> -- When you look go to a https site via a web browser, you can look at the 
> certificate fingerprint by clicking the View Certificate button on the 
> browser. Add a convenience function to proton which will return the char 
> array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a 
> 32 octet hash. The function signature should approximately look like this - 
> void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* 
> digest_name)
> 2. The subject field on the SSL cert has many subfields like - 
> C = ISO3166 two character country code
> ST = state or province
> L = Locality; generally means city
> O = Organization - Company Name
> OU = Organization Unit - division or unit
> CN = CommonName - end entity name e.g. www.example.com
> Provide convenience functions to obtain values of the above subfields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Qpid Proton 0.11.1

[Ted Ross]

+1

I tested proton-c against qpid dispatch on Fedora 20.

-Ted

On 12/15/2015 02:32 PM, Robbie Gemmell wrote:

Hi all,

I have put up an RC for 0.11.1, please test it and vote accordingly.

The release archive and sig/checksums can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.1-rc1/

Maven artifacts for the Java bits can be found in a temporary staging repo at:
https://repository.apache.org/content/repositories/orgapacheqpid-1057

Other than version updates, there are only two changes since 0.11.0:
https://issues.apache.org/jira/browse/PROTON-1059
https://issues.apache.org/jira/browse/PROTON-1077

It was created using commit 99ee72b897395b0abb72df001709095b498edbc5
on the 0.11.x branch, and is tagged as 0.11.1-rc1.

Regards,
Robbie

[jira] [Commented] (PROTON-989) Multi-threaded creation of outgoing connections can crash inside the Cyrus SASL library

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031842#comment-15031842
 ] 

Ted Ross commented on PROTON-989:
-

Dispatch has worked around this problem by using a mutex to serialize calls to 
"pn_sasl()".  The issue remains that if an application invokes pn_sasl() in 
multiple threads concurrently, the library can crash.

This is probably worthy of a release note or a mention in the API docs.


> Multi-threaded creation of outgoing connections can crash inside the Cyrus 
> SASL library
> ---
>
> Key: PROTON-989
> URL: https://issues.apache.org/jira/browse/PROTON-989
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Ted Ross
>Priority: Critical
>
> Qpid Dispatch router can be configured to make multiple outgoing connections. 
>  This often results in a crash in the Cyrus sasl library.
> Using the tests/config-6/A.conf configuration file in Dispatch causes this 
> problem.  You don't need to run more than one Dispatch process.
> This configuration attempts to create three outgoing connections 
> simultaneously in different threads.  Apparently there's a thread-safety 
> issue in Cyrus's sasl_client_init.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proton 0.11.0 release update - Beta is available

[Ted Ross]

I installed the 0.11.0 beta, ran the test suite, built Dispatch from 
master against it, and ran the Dispatch test suite.  I also ran the 
six-node dispatch-router scenario.


There were no build or test issues.

-Ted


On 10/28/2015 06:49 AM, Justin Ross wrote:

Hi, everyone.  The beta is now available from the following URL:

   https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.0-beta/

Maven staging repo:

   https://repository.apache.org/content/repositories/orgapacheqpid-1047

Test output from my machine, Fedora 22 x86-64:

   http://people.apache.org/~jross/qpid-releases/quirk-proton-0.11.0-beta.log

Take notice!  We are on a compressed schedule.  Alpha was one week ago, and
RC is only one week away.  We very much need testing and feedback on the
beta release.

With the beta, we've branched for release, and release-branch commits
require approval.  The release page[1] describes the procedure and criteria.

Thanks!
Justin

---
[1] Proton 0.11.0 release page:
https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.11.0

Re: proton 0.10 and swiftmq router

[Ted Ross]

It looks like SwiftMQ is configured to require SASL authentication.  If 
you supply authentication credentials (even "anonymous"), I believe this 
will work.


-Ted

On 10/02/2015 09:05 AM, Michael Ivanov wrote:

Hallo,

I am trying to run proton 0.10 client with SwiftMQ router and I'm getting the 
following errors:

   3 2015-10-02 15:24:08.42/sys$amqp/ERROR/VersionedConnection, 
connection=127.0.0.1:55984/wrong header received:
[ProtocolHeader, name=AMQP, id=0, major=1, minor=0, revision=0], required:
[ProtocolHeader, name=AMQP, id=3, major=1, minor=0, revision=0], closing 
connection

Swift MQ mailing list claims this is a proton issue :-\

Is there any hope to get a fix?

Best regards,

[jira] [Commented] (PROTON-1008) Using a blank mech_list disables authentication

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935189#comment-14935189
 ] 

Ted Ross commented on PROTON-1008:
--

Is it ever sensible to not use SASL?  Are there AMQP servers that don't support 
SASL?  As it stands, I don't know how to turn SASL _on_.  There may be existing 
mechanisms available (EXTERNAL, GSSAPI), but I don't have a username to supply 
and I don't necessarily know which mechanisms to put in the allowed_mechs list.


> Using a blank mech_list disables authentication
> ---
>
> Key: PROTON-1008
> URL: https://issues.apache.org/jira/browse/PROTON-1008
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>    Affects Versions: 0.11
>Reporter: Ted Ross
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> This bug was introduced in commit
> 
> https://github.com/apache/qpid-proton/commit/14956b07edc3de93f67179c753bbedcd9eba51a6
> If the client leaves allowed_mechs as None, the SASL protocol is not even 
> executed.  I claim that allowed_mechs is used to restrict the set of 
> acceptable mechanisms.  If it is None, then all available mechanisms may be 
> used.
> This bug causes a failure in the Qpid Dispatch test suite 
> (system_tests_qdstat).  The failure is when the server requires 
> authentication and will accept EXTERNAL and the client has a valid 
> client-certificate but doesn't use the sasl protocol because qdstat doesn't 
> (and can't) set the allowed_mechs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-1008) Using a blank mech_list disables authentication

[Ted Ross (JIRA)]

Ted Ross created PROTON-1008:


 Summary: Using a blank mech_list disables authentication
 Key: PROTON-1008
 URL: https://issues.apache.org/jira/browse/PROTON-1008
 Project: Qpid Proton
  Issue Type: Bug
  Components: python-binding
Affects Versions: 0.11
Reporter: Ted Ross
 Fix For: 0.11


This bug was introduced in commit

https://github.com/apache/qpid-proton/commit/14956b07edc3de93f67179c753bbedcd9eba51a6
If the client leaves allowed_mechs as None, the SASL protocol is not even 
executed.  I claim that allowed_mechs is used to restrict the set of acceptable 
mechanisms.  If it is None, then all available mechanisms may be used.
This bug causes a failure in the Qpid Dispatch test suite 
(system_tests_qdstat).  The failure is when the server requires authentication 
and will accept EXTERNAL and the client has a valid client-certificate but 
doesn't use the sasl protocol because qdstat doesn't (and can't) set the 
allowed_mechs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-1004) Inconsistency in container.create_sender

[Ted Ross (JIRA)]

Ted Ross created PROTON-1004:


 Summary: Inconsistency in container.create_sender
 Key: PROTON-1004
 URL: https://issues.apache.org/jira/browse/PROTON-1004
 Project: Qpid Proton
  Issue Type: Bug
  Components: python-binding
Affects Versions: 0.10
Reporter: Ted Ross


For URL = "localhost:5672/examples"
Using the API in two different ways:
{noformat}
def on_start(self, event):
event.container.create_sender(URL)
{noformat}
Yields an attach with the following target:
[address="examples", durable=0, timeout=0, dynamic=false]

But this variation yields something different:
{noformat}
def on_start(self, event):
conn = event.container.connect(URL, heartbeat=8)
event.container.create_sender(conn, URL)
{noformat}
yields:
[address="localhost:5672/examples", durable=0, timeout=0, dynamic=false]

The attach targets should be consistent across these examples.  I believe the 
first example is the correct one.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Bug in proton interop suite??

[Ted Ross]

I don't think this is a valid data sequence.  Literally, it is a binary 
sequence of seven octets where the internal encoding of a string is 
coincidental.  Binary is not a compound type and does not contain 
sub-fields.


-Ted

On 09/08/2015 05:36 PM, aconway wrote:

I'm doing some interop work on the go binding, and I see something
strange in the 'message.amqp' file in tests/interop. The message body
is encoded as:

0x77, 0xa0, 0x7, 0xa1, 0x5, 0x68, 0x65, 0x6c, 0x6c, 0x6f
^ AMQP value section
   ^Binary
 ^7 bytes
  ^String
^5 bytes
 h e  l lo

In other words there's an AMQP-encoded string *inside* an AMQP encoded
binary. Looking at the python code that generated this message I would
expect it to be an AMQP 5 byte binary value "hello". I think the intent
was for it to be a string, but in python plain "hello" is binary you
need to say u"hello" to get a string. However I can't see any reason
why there would be a string *inside* a binary. Anyone have a clue
what's going on here?

Cheers,
Alan.

[jira] [Created] (PROTON-989) Multi-threaded creation of outgoing connections can crash inside the Cyrus SASL library

[Ted Ross (JIRA)]

Ted Ross created PROTON-989:
---

 Summary: Multi-threaded creation of outgoing connections can crash 
inside the Cyrus SASL library
 Key: PROTON-989
 URL: https://issues.apache.org/jira/browse/PROTON-989
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.10
Reporter: Ted Ross
Priority: Critical


Qpid Dispatch router can be configured to make multiple outgoing connections.  
This often results in a crash in the Cyrus sasl library.
Using the tests/config-6/A.conf configuration file in Dispatch causes this 
problem.  You don't need to run more than one Dispatch process.
This configuration attempts to create three outgoing connections simultaneously 
in different threads.  Apparently there's a thread-safety issue in Cyrus's 
sasl_client_init.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Qpid Proton 0.10 (RC3)

[Ted Ross]

On 08/13/2015 03:20 PM, Robbie Gemmell wrote:

To clarify, my run was also using the x86_64 / amd64 version, using a VM.

Neither of us have been able to reproduce what Andrew saw, so unless
we can get a better idea what it is specifically then I am inclined to
say that we proceed. If there is an issue and it can be identified,
I'm sure it will be joined by others once a larger group of folks can
actually get there hands on a release, and I'll happilly cut a 0.10.1
to address them if fixes are available.


+1



Robbie

On 13 August 2015 at 20:05, Ted Ross  wrote:

I ran the tests under Ubuntu 14.04 (for amd64) running an x86_64 Linux
kernel (using Docker).  All of the tests, including the SSL tests pass.

-Ted


On 08/13/2015 09:56 AM, Robbie Gemmell wrote:


I have run up a fresh Ubuntu 14.04.3 install didn't see any issues
(once I figured out what packages to install to get the tests all
running). Can you elaborate on the problem you are seeing?

Robbie

On 12 August 2015 at 22:41, Andrew Stitcher  wrote:


I've tested proton-c on ubuntu1404, ubuntu1204 & FreeBSD 10.1p17

Ubuntu 1204 builds and ctests fine.
This is our the OS on our travis CI so it's not a surprise it works.

Ubuntu 1404 - I'm having problems with the "python" tests and SSL -
investigating whether this is my config or something more. This is a
little worrying

FreeBSD - I'm getting test failures in
proton_tests.messenger.SelectableMessengerTest.testSelectable*
This might reflect some difference in poll() behaviour.

I'm also getting failures in
...*_valgrind with output like this...
AssertionError: Unexpected input while waiting for receiver to
initialize: ==12271== Use of uninitialised value of size 8

Which seems like valgrind detected use of an uninitialised value.
I don't know it this is in proton or one of the lib it uses yet.

Not sure if FreeBSD is important enough to care too much, but it should
work.

[so no -1 yet, but investigating. IMO the FreeBSD failures aren't
enough to reject the release, but the Ubuntu failures might be]

Andrew

On Tue, 2015-08-11 at 21:08 +0100, Robbie Gemmell wrote:


Hi all,

I have put up a third cut for 0.10, please test it and vote
accordingly.

Since RC2 there have been fixes for PROTON-978, PROTON-975, and
PROTON-899.

The release archive and sig/checksums can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/proton/0.10-rc3/

Maven artifacts for the Java bits can be found in a temporary staging
repo at:
https://repository.apache.org/content/repositories/orgapacheqpid-1042

It is tagged as 0.10-rc3. You may need to fetch the tags explicitly
to
see it, e.g: "git fetch --tags"

Regards,
Robbie



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Qpid Proton 0.10 (RC3)

[Ted Ross]

I ran the tests under Ubuntu 14.04 (for amd64) running an x86_64 Linux 
kernel (using Docker).  All of the tests, including the SSL tests pass.


-Ted

On 08/13/2015 09:56 AM, Robbie Gemmell wrote:

I have run up a fresh Ubuntu 14.04.3 install didn't see any issues
(once I figured out what packages to install to get the tests all
running). Can you elaborate on the problem you are seeing?

Robbie

On 12 August 2015 at 22:41, Andrew Stitcher  wrote:

I've tested proton-c on ubuntu1404, ubuntu1204 & FreeBSD 10.1p17

Ubuntu 1204 builds and ctests fine.
This is our the OS on our travis CI so it's not a surprise it works.

Ubuntu 1404 - I'm having problems with the "python" tests and SSL -
investigating whether this is my config or something more. This is a
little worrying

FreeBSD - I'm getting test failures in
proton_tests.messenger.SelectableMessengerTest.testSelectable*
This might reflect some difference in poll() behaviour.

I'm also getting failures in
...*_valgrind with output like this...
AssertionError: Unexpected input while waiting for receiver to
initialize: ==12271== Use of uninitialised value of size 8

Which seems like valgrind detected use of an uninitialised value.
I don't know it this is in proton or one of the lib it uses yet.

Not sure if FreeBSD is important enough to care too much, but it should
work.

[so no -1 yet, but investigating. IMO the FreeBSD failures aren't
enough to reject the release, but the Ubuntu failures might be]

Andrew

On Tue, 2015-08-11 at 21:08 +0100, Robbie Gemmell wrote:

Hi all,

I have put up a third cut for 0.10, please test it and vote
accordingly.

Since RC2 there have been fixes for PROTON-978, PROTON-975, and
PROTON-899.

The release archive and sig/checksums can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/proton/0.10-rc3/

Maven artifacts for the Java bits can be found in a temporary staging
repo at:
https://repository.apache.org/content/repositories/orgapacheqpid-1042

It is tagged as 0.10-rc3. You may need to fetch the tags explicitly
to
see it, e.g: "git fetch --tags"

Regards,
Robbie


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Qpid Proton 0.10 (RC3)

[Ted Ross]

+1

I tested proton-c against Dispatch Router.  It all looks good.

-Ted

On 08/11/2015 04:08 PM, Robbie Gemmell wrote:

Hi all,

I have put up a third cut for 0.10, please test it and vote accordingly.

Since RC2 there have been fixes for PROTON-978, PROTON-975, and PROTON-899.

The release archive and sig/checksums can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/proton/0.10-rc3/

Maven artifacts for the Java bits can be found in a temporary staging repo at:
https://repository.apache.org/content/repositories/orgapacheqpid-1042

It is tagged as 0.10-rc3. You may need to fetch the tags explicitly to
see it, e.g: "git fetch --tags"

Regards,
Robbie

[jira] [Updated] (PROTON-978) Framing errors after SASL exchange when max-frame-size is configured

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-978:

Attachment: commit-34b4c6d

Proposed patch that fixes the problem.

> Framing errors after SASL exchange when max-frame-size is configured
> 
>
> Key: PROTON-978
> URL: https://issues.apache.org/jira/browse/PROTON-978
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Ted Ross
>Priority: Blocker
> Fix For: 0.10
>
> Attachments: commit-0d2ef9f, commit-34b4c6d
>
>
> Detected in Proton 0.10-RC2
> If the server side of a transport has a non-zero max-frame-size (e.g. 65536), 
> framing errors will occur between the SASL and AMQP sections of the 
> connection protocol because pn_read_frame will read the AMQP header as though 
> it were a frame.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-978) Framing errors after SASL exchange when max-frame-size is configured

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-978:

Attachment: commit-0d2ef9f

Test update to detect the issue.

> Framing errors after SASL exchange when max-frame-size is configured
> 
>
> Key: PROTON-978
> URL: https://issues.apache.org/jira/browse/PROTON-978
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Ted Ross
>Priority: Blocker
> Fix For: 0.10
>
> Attachments: commit-0d2ef9f, commit-34b4c6d
>
>
> Detected in Proton 0.10-RC2
> If the server side of a transport has a non-zero max-frame-size (e.g. 65536), 
> framing errors will occur between the SASL and AMQP sections of the 
> connection protocol because pn_read_frame will read the AMQP header as though 
> it were a frame.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-978) Framing errors after SASL exchange when max-frame-size is configured

[Ted Ross (JIRA)]

Ted Ross created PROTON-978:
---

 Summary: Framing errors after SASL exchange when max-frame-size is 
configured
 Key: PROTON-978
 URL: https://issues.apache.org/jira/browse/PROTON-978
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.10
Reporter: Ted Ross
Priority: Blocker
 Fix For: 0.10


Detected in Proton 0.10-RC2
If the server side of a transport has a non-zero max-frame-size (e.g. 65536), 
framing errors will occur between the SASL and AMQP sections of the connection 
protocol because pn_read_frame will read the AMQP header as though it were a 
frame.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Qpid Proton 0.10 (RC2)

[Ted Ross]

-1 unfortunately.

I've been testing against Dispatch and I'm seeing lots of timeouts on 
the tests.


It turns out that pn_read_frame is used to parse text that is not a 
frame header.  It's actually the AMQP header so it interprets the string 
"AMQP" as the frame length.  Now that we're testing frames against the 
max-frame-size, this causes a framing error which drops the connection.


It's interesting to note that this mis-parse is not a regression.  It's 
been happening all along but was not noticed because "AMQP" is much 
larger than the typical number of available bytes.  Before RC2, 
pn_read_frame would simply return zero for this non-frame and things 
muddled along more or less correctly.


-Ted

On 08/10/2015 02:34 PM, Robbie Gemmell wrote:

Hi all,

I have put up a second cut for 0.10, please test it and vote accordingly.

This fixes a crash (PROTON-976) reported against the previous spin,
and adds a known issue (PROTON-975) of possible failure using the
DIGEST-MD5 mechanism against non-proton servers.

The release archive and sig/checksums can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/proton/0.10-rc2/

Maven artifacts for the Java bits can be found in a temporary staging repo at:
https://repository.apache.org/content/repositories/orgapacheqpid-1041

Regards,
Robbie

[jira] [Created] (PROTON-970) SASL options for setting path and name should not be transport-specific

[Ted Ross (JIRA)]

Ted Ross created PROTON-970:
---

 Summary: SASL options for setting path and name should not be 
transport-specific
 Key: PROTON-970
 URL: https://issues.apache.org/jira/browse/PROTON-970
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Ted Ross


Both pn_sasl_config_name and pn_sasl_config_path take a pn_sasl_t object as an 
argument, suggesting that different transports may use different configurations.
Cyrus SASL treats both the path and (server) name as per-process settings.
The above methods in pn_sasl should reflect this scope and not use a pn_sasl_t 
as an argument.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-969) Cyrus SASL module calls sasl_server_init once for every incoming connection

[Ted Ross (JIRA)]

Ted Ross created PROTON-969:
---

 Summary: Cyrus SASL module calls sasl_server_init once for every 
incoming connection
 Key: PROTON-969
 URL: https://issues.apache.org/jira/browse/PROTON-969
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Ted Ross
Priority: Blocker
 Fix For: 0.10


The Cyrus SASL module invokes sasl_server_init once for every incoming 
connection on a listener.  The Manpage for sasl_server_init states that it 
should be called only once per process.

Is this a blocker for 0.10?




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-950) SASL PLAIN over cleartext should be supported

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-950:

Priority: Blocker  (was: Major)

> SASL PLAIN over cleartext should be supported
> -
>
> Key: PROTON-950
> URL: https://issues.apache.org/jira/browse/PROTON-950
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Ted Ross
>Assignee: Andrew Stitcher
>Priority: Blocker
> Fix For: 0.10
>
>
> In the current 0.10 alpha, if SASL PLAIN is selected, SSL is forced.  This is 
> a surprising change of behavior from earlier versions of Proton and it's 
> arguable that a security policy like that should be left to the application 
> using the Proton library.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630019#comment-14630019
 ] 

Ted Ross commented on PROTON-950:
-

That makes two of us.  I've updated it accordingly.

> SASL PLAIN over cleartext should be supported
> -
>
> Key: PROTON-950
> URL: https://issues.apache.org/jira/browse/PROTON-950
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Ted Ross
>Assignee: Andrew Stitcher
>Priority: Blocker
> Fix For: 0.10
>
>
> In the current 0.10 alpha, if SASL PLAIN is selected, SSL is forced.  This is 
> a surprising change of behavior from earlier versions of Proton and it's 
> arguable that a security policy like that should be left to the application 
> using the Proton library.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-950) SASL PLAIN over cleartext should be supported

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-950:

Assignee: Andrew Stitcher

> SASL PLAIN over cleartext should be supported
> -
>
> Key: PROTON-950
> URL: https://issues.apache.org/jira/browse/PROTON-950
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: Ted Ross
>Assignee: Andrew Stitcher
> Fix For: 0.10
>
>
> In the current 0.10 alpha, if SASL PLAIN is selected, SSL is forced.  This is 
> a surprising change of behavior from earlier versions of Proton and it's 
> arguable that a security policy like that should be left to the application 
> using the Proton library.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-950) SASL PLAIN over cleartext should be supported

[Ted Ross (JIRA)]

Ted Ross created PROTON-950:
---

 Summary: SASL PLAIN over cleartext should be supported
 Key: PROTON-950
 URL: https://issues.apache.org/jira/browse/PROTON-950
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.10
Reporter: Ted Ross
 Fix For: 0.10


In the current 0.10 alpha, if SASL PLAIN is selected, SSL is forced.  This is a 
surprising change of behavior from earlier versions of Proton and it's arguable 
that a security policy like that should be left to the application using the 
Proton library.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-943) Bump library (.so) major version for proton-c libraries

[Ted Ross (JIRA)]

Ted Ross created PROTON-943:
---

 Summary: Bump library (.so) major version for proton-c libraries
 Key: PROTON-943
 URL: https://issues.apache.org/jira/browse/PROTON-943
 Project: Qpid Proton
  Issue Type: Task
  Components: proton-c
Reporter: Ted Ross
Priority: Blocker
 Fix For: 0.10


0.10 contains incompatible API changes.  The library major versions need to be 
incremented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: New python tox tests failing on fedora 22, Python 2.7.10/3.4.2

[Ted Ross]

I had a similar error, not sure if it was exactly the same.  I 
discovered that I was missing the python3-devel package.  Once 
python3-devel was installed and I did a completely clean build, the 
problems went away.


-Ted

On 07/10/2015 10:01 AM, aconway wrote:

Anyone seeing errors like this? I think the ERROR: InterpreterNotFound
should be a warning, it seems to be testing both 2.7 and 3.4 so not
finding 2.6 and 3.3 doesn't seem like an ERROR.

The "missing attribute" is defined as a @staticmethod so I don't
understand that.

The 3 argument raise is definitely gone in python 3 so I don't
understand why its still there or what is the portable way to replace
it.

Cheers,
Alan.

1/1 Test #3: python-tox-test ..***Failed  Error regular
expression found in output. Regex=[ERROR:[ ]+py[0-9]*: commands failed]
28.49 sec
GLOB sdist-make: /home/aconway/proton/proton-c/bindings/python/setup.py
py26 create: /home/aconway/proton/proton-c/bindings/python/.tox/py26
ERROR: InterpreterNotFound: python2.6
py27 inst-nodeps: /home/aconway/proton/proton
-c/bindings/python/.tox/dist/python-qpid-proton-0.10.0.zip
py27 runtests: PYTHONHASHSEED='147840795'
py27 runtests: commands[0] | /home/aconway/proton/proton
-c/bindings/python/../../../tests/python/proton-test
Traceback (most recent call last):
   File "/home/aconway/proton/proton
-c/bindings/python/../../../tests/python/proton-test", line 620, in

 m = __import__(name, None, None, ["dummy"])
   File "/home/aconway/proton/tests/python/proton_tests/__init__.py",
line 20, in 
 import proton_tests.codec
   File "/home/aconway/proton/tests/python/proton_tests/codec.py", line
21, in 
 from . import common
   File "/home/aconway/proton/tests/python/proton_tests/common.py", line
133, in 
 if SASL.extended():
AttributeError: type object 'SASL' has no attribute 'extended'
ERROR: InvocationError: '/home/aconway/proton/proton
-c/bindings/python/../../../tests/python/proton-test'
py33 create: /home/aconway/proton/proton-c/bindings/python/.tox/py33
ERROR: InterpreterNotFound: python3.3
py34 inst-nodeps: /home/aconway/proton/proton
-c/bindings/python/.tox/dist/python-qpid-proton-0.10.0.zip
py34 runtests: PYTHONHASHSEED='147840795'
py34 runtests: commands[0] | /home/aconway/proton/proton
-c/bindings/python/../../../tests/python/proton-test
Traceback (most recent call last):
   File "/home/aconway/proton/proton
-c/bindings/python/../../../tests/python/proton-test", line 620, in

 m = __import__(name, None, None, ["dummy"])
   File "/home/aconway/proton/tests/python/proton_tests/__init__.py",
line 20, in 
 import proton_tests.codec
   File "/home/aconway/proton/tests/python/proton_tests/codec.py", line
21, in 
 from . import common
   File "/home/aconway/proton/tests/python/proton_tests/common.py", line
26, in 
 from proton import Connection, Transport, SASL, Endpoint, Delivery,
SSL
   File "/usr/local/lib64/proton/bindings/python/proton/__init__.py",
line 3733
 raise exc, val, tb
  ^
SyntaxError: invalid syntax
ERROR: InvocationError: '/home/aconway/proton/proton
-c/bindings/python/../../../tests/python/proton-test'
___ summary
___
ERROR:   py26: InterpreterNotFound: python2.6
ERROR:   py27: commands failed
ERROR:   py33: InterpreterNotFound: python3.3
ERROR:   py34: commands failed

[GitHub] qpid-proton pull request: Fix 2 Code Analysis warnings and a reall...

[ted-ross]

Github user ted-ross commented on the pull request:

https://github.com/apache/qpid-proton/pull/39#issuecomment-118902728
  
I'd like to see this pull request move forward.  On Dan's points above:

1) I agree with Andrew that using __LINE__ as an error code should be 
changed to simply returning an eror code (or a null result, whichever is 
appropriate).
2) I agree with Andrew here as well.  I think it's an acceptable pattern to 
check inputs and exit early if there is an error condition.
3) I agree with Dan that the library should simply report the failure to 
allocate and not take any action on behalf of the process using it.  There are 
a number of cases where Proton makes relatively large allocations the failure 
of which does not necessarily mean that the process can't recover.
Taking a piecemeal approach to cleaning up all the ignored allocations is 
probably a good idea.  If there are any API changes that will result, we should 
try to get those all into a single release.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: AMQP 1.0 and Shared Subscriptions

[Ted Ross]

On 05/06/2015 10:05 AM, Ken Giusti wrote:

Bump this up.

I'm essentially in the same boat.  The olso.messaging library in Openstack has 
introduced a feature called 'consumer pools' which is essentially the same 
pattern: a set of subscribers to a topic can belong to a pool.  Each distinct 
pool of subscribers get a copy of the message sent to the topic, and only one 
subscriber from the pool claims the message.

This pattern is available in the JMS 2.0 API via the createdSharedConsumer call 
[1]

I'm particularly interested in how such a feature could be implemented in a 
qpid-dispatch based federation of brokers.  I suspect that all subscribers to a 
given share would have to belong on the same broker - if shares existed on 
multiple brokers then each 'sub-share' would get a copy of the same message in 
violation of the pattern.


A half-baked idea:

What if we implemented a shared-target in Dispatch?  It's like a 
waypoint except it doesn't have any external component and has no 
connections or links associated with it.


You would configure a shared-target to receive from topic address T and 
send to pool address P.  The semantics for T are multicast (i.e. each 
pool receiving from T will get one copy of every message from T) and the 
semantics for P are anycast (i.e. messages to P will be sent to exactly 
one of the consumers of P).


Would that solve your problem?




[1] http://www.oracle.com/technetwork/articles/java/jms2messaging-1954190.html

- Original Message -

From: "Dominic Evans" 
To: proton@qpid.apache.org
Sent: Wednesday, May 6, 2015 7:41:59 AM
Subject: AMQP 1.0 and Shared Subscriptions

When we were implementing the MQ Light broker, we wanted to be able to
support sharing of subscriptions across a group of clients - in particular
for the worker offload scenario. At the time we were unable to find guidance
in the specification or extensions thereof, so we went ahead with encoding
this into the terminus addresses of an attach. Using a `private:` prefix to
denote an exclusive subscription, and `share:sharename` to indicate a shared
one.

i.e.,

-> @attach(18) [name="share:sharename:topicname", handle=0, role=true,
snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
[address="share:sharename:topicname", durable=0, timeout=0, dynamic=false],
target=@target(41) [address="share:sharename:topicname", durable=0,
timeout=0, dynamic=false], initial-delivery-count=0]

vs

-> @attach(18) [name="private:topicname", handle=0, role=true,
snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
[address="private:topicname", durable=0, timeout=0, dynamic=false],
target=@target(41) [address="private:topicname", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]

The other day I happened to notice that the qpid-cpp broker also supports a
similar functionality since https://issues.apache.org/jira/browse/QPID-4917
/ https://github.com/apache/qpid/commit/d4dafd3 - and it does this by
supporting a capability of 'shared' on the exchange, and expecting a client
@attach to request this capability, whereupon the link-name is used as-is
for the name of the share. I wasn't able to find this behaviour documented
any further than that, and it wasn't clear to me what the behaviour should
be for the various scenarios.

Ideally we'd like to conform to a common standard. Does anyone know if there
were any plans to register this (or another) shared subscription behaviour
with the working group as an extension?


--

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [VOTE]: Release Proton 0.9.1-rc1 as 0.9.1

[Ted Ross]

+1

On 04/29/2015 03:34 PM, Rafael Schloming wrote:

Hi Everyone,

I've put out an RC for 0.9.1 in the usual places.

Source artifacts are here:
 https://people.apache.org/~rhs/qpid-proton-0.9.1-rc1/

Java binaries are here:
 https://repository.apache.org/content/repositories/orgapacheqpid-1033

Please check them out and register your vote:

[  ]: Yes, release Proton 0.9.1-rc1 as 0.9.1
[  ]: No, ...

--Rafael

Re: 0.10 release time frame?

[Ted Ross]

+1

I'd like to see an official release with the SASL updates as soon as 
practical.


-Ted


On 04/30/2015 09:37 PM, Rafael Schloming wrote:

I'd like to see one fairly soon. I'm currently working through a few
sasl-related interop issues between proton-c and proton-j, but once that is
done and gordon's map fix lands, I think we would be in decent shape to put
out a 0.10 in short order.

--Rafael

On Thu, Apr 30, 2015 at 3:06 PM, Rajith Muditha Attapattu <
rajit...@gmail.com> wrote:


I'm interested in knowing the timelines the community has in mind for the
0.10 release.

A tentative date for alpha and beta cycles would be helpful in planning the
work tasks and vacation time.

Regards,

Rajith

Re: [RESULT] [VOTE]: Proton 0.9-rc-3

[Ted Ross]

Rafael,

Do you have an ETA for the final bits?  We're anxious to build some 
downstream packages.


-Ted

On 03/22/2015 02:44 PM, Rafael Schloming wrote:

This vote passes with 8 binding +1's and no other votes. I will push the
final bits soon.

--Rafael

On Tue, Mar 17, 2015 at 9:42 AM, Rafael Schloming  wrote:


Hi Everyone,

Here's a quick respin of 0.9-rc-3. The only changes from rc-2 are exactly
those two mentioned on the rc-2 vote thread. I've included them at the end
for reference. You can find the source artifacts in the usual location:

 https://people.apache.org/~rhs/qpid-proton-0.9-rc-3/

Java binaries are here:

 https://repository.apache.org/content/repositories/orgapacheqpid-1031

Please check it out and register your vote:

[   ] Yes, release Proton 0.9-rc-3 as 0.9 final
[   ] No, because ...

--Rafael

==

commit 810088b14dedcd12a9474687ba9cd05fc8297188
Author: Dominic Evans 
Date:   Mon Mar 16 12:18:20 2015 +

 PROTON-834: further UTF-8 encoder fixes

 After commit c65e897 it turned out there were still some issues with
 strings containing a codepoint >0xDBFF which was being incorrectly
 treated as a surrogate pair in the calculateUTF8Length method.

 Fixed this up and added some more test coverage.

 Closes #13

 (cherry picked from commit 7b9b516d445ab9e86a0313709c77218d901435b1)

commit c2042d7d26c4383047dac2709d1a2effe0b11419
Author: Alan Conway 
Date:   Mon Mar 16 09:51:28 2015 -0400

 PROTON-839: Proton 0.9 RC 2 blocker -
proton_tests.utils.SyncRequestResponse

 Fix to reactor.py, check for lack of SSL domain.

 (cherry picked from commit e31df015a79d791e62caf9bef3f29bdfd77042ef)

Re: [VOTE]: Proton 0.9-rc-3

[Ted Ross]

[ X ] Yes, release Proton 0.9-rc-3 as 0.9 final


On 03/16/2015 04:42 PM, Rafael Schloming wrote:

Hi Everyone,

Here's a quick respin of 0.9-rc-3. The only changes from rc-2 are exactly
those two mentioned on the rc-2 vote thread. I've included them at the end
for reference. You can find the source artifacts in the usual location:

 https://people.apache.org/~rhs/qpid-proton-0.9-rc-3/

Java binaries are here:

 https://repository.apache.org/content/repositories/orgapacheqpid-1031

Please check it out and register your vote:

[   ] Yes, release Proton 0.9-rc-3 as 0.9 final
[   ] No, because ...

--Rafael

==

commit 810088b14dedcd12a9474687ba9cd05fc8297188
Author: Dominic Evans 
Date:   Mon Mar 16 12:18:20 2015 +

 PROTON-834: further UTF-8 encoder fixes

 After commit c65e897 it turned out there were still some issues with
 strings containing a codepoint >0xDBFF which was being incorrectly
 treated as a surrogate pair in the calculateUTF8Length method.

 Fixed this up and added some more test coverage.

 Closes #13

 (cherry picked from commit 7b9b516d445ab9e86a0313709c77218d901435b1)

commit c2042d7d26c4383047dac2709d1a2effe0b11419
Author: Alan Conway 
Date:   Mon Mar 16 09:51:28 2015 -0400

 PROTON-839: Proton 0.9 RC 2 blocker -
proton_tests.utils.SyncRequestResponse

 Fix to reactor.py, check for lack of SSL domain.

 (cherry picked from commit e31df015a79d791e62caf9bef3f29bdfd77042ef)

Re: I think that's a blocker...

[Ted Ross]

On 02/25/2015 11:52 AM, Rafael Schloming wrote:

On Wed, Feb 25, 2015 at 10:49 AM, Ted Ross  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.



Interesting... so this is what the docs say:

/**
  * A ::pn_io_t manages IO for a group of pn_socket_t handles.  A
  * pn_io_t object may have zero or one pn_selector_t selectors
  * associated with it (see ::pn_io_selector()).  If one is associated,
  * all the pn_socket_t handles managed by a pn_io_t must use that
  * pn_selector_t instance.
  *
  * The pn_io_t interface is single-threaded. All methods are intended
  * to be used by one thread at a time, except that multiple threads
  * may use:
  *
  *   ::pn_write()
  *   ::pn_send()
  *   ::pn_recv()
  *   ::pn_close()
  *   ::pn_selector_select()
  *
  * provided at most one thread is calling ::pn_selector_select() and
  * the other threads are operating on separate pn_socket_t handles.
  */


I claim that the commit-in-question violates the text above.  Calls to 
pn_send() and pn_recv() are no longer thread-safe because they now use 
the shared error record.




I think this has been somewhat modified by the constraints from the windows
implementation, and I'm not sure I understand completely what the
constraints are there, or entirely what is being described above, but on
the posix front, the pn_io_t is little more than just a holder for an error
slot, and you should have one of these per thread. It shouldn't be a
problem to use send/recv/etc from multiple threads though so long as you
pass in the pn_io_t from the current thread.


It's not desirable to allocate sockets to threads up front (i.e. 
partition the set of sockets into per-thread slots).  I know you didn't 
say that was needed but it's what I infer from the docs for pn_io_t.


Assuming, as you suggest, that pn_io_t is nothing more than a 
thread-specific error notepad seems like a recipe for future disaster 
because pn_io_t is clearly intended to be more than that.


-Ted

Re: I think that's a blocker...

[Ted Ross]

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 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 perhaps a pre-existing bug in dispatch where it is calling
pn_send/pn_recv with a pn_io_t that has been freed, and it is only now
triggering due to the additional asserts that are encountered due to not
ignoring the error information.

I could be mistaken, but I would try reproducing this under valgrind. That
will tell you where the first free occurred and that should hopefully make
it obvious whether this is indeed a proton bug or whether dispatch is
somehow freeing the pn_io_t sooner than it should.

(FWIW, if it is indeed a proton bug, then I would agree it is a blocker.)

--Rafael

On Wed, Feb 25, 2015 at 7:54 AM, Michael Goulish 
wrote:


...but if not, somebody please feel free to correct me.

The Jira that I just created -- PROTON-826 -- is for a
bug I found with my topology testing of the Dispatch Router,
in which I repeatedly kill and restart a router and make
sure that the router network comes back to the same topology
that it had before.

As of checkin 01cb00c -- which had no Jira -- it is pretty
easy for my test to blow core.  It looks like an error
string is being double-freed (maybe) in the proton library.

( full info in the Jira.  https://issues.apache.org/jira/browse/PROTON-826
)

[jira] [Updated] (PROTON-825) BlockingReceiver.receive() uses 100% CPU.

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-825:

Assignee: Alan Conway  (was: Ted Ross)

> BlockingReceiver.receive() uses 100% CPU.
> -
>
> Key: PROTON-825
> URL: https://issues.apache.org/jira/browse/PROTON-825
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.9
> Environment: F20
> Built from master 2/19.
>Reporter: Jeff Ortel
>Assignee: Alan Conway
>
> Calling BlockingReceiver.receive(timeout=10) blocks the caller for 10 seconds 
> but uses 100% CPU.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-817) BlockingConnection doesn't pass options down in create_sender or create_receiver

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-817:

Attachment: PROTON-817.patch

> BlockingConnection doesn't pass options down in create_sender or 
> create_receiver
> 
>
> Key: PROTON-817
> URL: https://issues.apache.org/jira/browse/PROTON-817
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Ted Ross
>Assignee: Gordon Sim
> Fix For: 0.9
>
> Attachments: PROTON-817.patch
>
>
> The options argument is not passed down from 
> BlockingConnection.create_receiver to Container.create_receiver.  The same is 
> true for create_sender.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-817) BlockingConnection doesn't pass options down in create_sender or create_receiver

[Ted Ross (JIRA)]

Ted Ross created PROTON-817:
---

 Summary: BlockingConnection doesn't pass options down in 
create_sender or create_receiver
 Key: PROTON-817
 URL: https://issues.apache.org/jira/browse/PROTON-817
 Project: Qpid Proton
  Issue Type: Bug
  Components: python-binding
Reporter: Ted Ross
Assignee: Gordon Sim
 Fix For: 0.9


The options argument is not passed down from BlockingConnection.create_receiver 
to Container.create_receiver.  The same is true for create_sender.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-816) Add access to dynamic-node-properties in termini

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-816:

Attachment: PROTON-816.patch

> Add access to dynamic-node-properties in termini
> 
>
> Key: PROTON-816
> URL: https://issues.apache.org/jira/browse/PROTON-816
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: python-binding
>    Reporter: Ted Ross
> Fix For: 0.9
>
> Attachments: PROTON-816.patch
>
>
> The Python reactive API needs to provide access to the 
> dynamic-node-properties map in termini for senders and receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-816) Add access to dynamic-node-properties in termini

[Ted Ross (JIRA)]

Ted Ross created PROTON-816:
---

 Summary: Add access to dynamic-node-properties in termini
 Key: PROTON-816
 URL: https://issues.apache.org/jira/browse/PROTON-816
 Project: Qpid Proton
  Issue Type: New Feature
  Components: python-binding
Reporter: Ted Ross
 Fix For: 0.9


The Python reactive API needs to provide access to the dynamic-node-properties 
map in termini for senders and receivers.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: reactor examples

[Ted Ross]

Rafael,

I'm a bit confused by this push.  How does this set of examples relate 
to the examples Gordon has been developing in examples/engine/py?


They are both "reactor" APIs with very similar structure yet they appear 
to be completely different and unrelated.  Yours uses Reactor, 
on_delivery, and on_reactor_start.  Gordon's uses Container, on_message, 
and on_start.


Gordon has been developing this API in the open for the last several 
months.  Why have you suddenly contributed a seemingly overlapping API?


-Ted


On 01/29/2015 06:23 PM, Rafael Schloming wrote:

I pushed some basic reactor examples into the proton tree under
examples/reactor/py. These are geared mostly towards
understanding/explaining the basic processing model of the event loop.

Please have a look. They are still a bit of a work in progress, as is the
API itself, but all feedback is welcome.

--Rafael

[jira] [Updated] (PROTON-756) add a new/simpler setup.py for python bindings

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-756:

Priority: Blocker  (was: Major)

> add a new/simpler setup.py for python bindings
> --
>
> Key: PROTON-756
> URL: https://issues.apache.org/jira/browse/PROTON-756
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Reporter: Rafael H. Schloming
>Assignee: Ken Giusti
>Priority: Blocker
> Fix For: 0.9
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-764) Driver is multi-thread-unsafe when connections are closed uncleanly

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236076#comment-14236076
 ] 

Ted Ross commented on PROTON-764:
-

I've lowered the severity of this to minor.  I think Dispatch is the only user 
of this driver that will see this problem and the issue has been worked around 
in Dispatch.


> Driver is multi-thread-unsafe when connections are closed uncleanly
> ---
>
> Key: PROTON-764
> URL: https://issues.apache.org/jira/browse/PROTON-764
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.8
>Reporter: Ted Ross
>Priority: Minor
>
> In a multi-threaded environment (Qpid Dispatch), lost connections can result 
> in multiple calls to pn_connector_close for a given connector.  This results 
> in driver->close_count never returning to zero and the poll loop forever 
> running with a zero timeout.
> The reason for this is that pn_driver_wait_3 calls pn_connector_close when it 
> sees an error, even if that connector is currently being processed by another 
> thread.  I think that pn_driver_wait_3 should only flag the connector as 
> failed so the user can close it in the proper thread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-764) Driver is multi-thread-unsafe when connections are closed uncleanly

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-764:

Fix Version/s: (was: 0.9)

> Driver is multi-thread-unsafe when connections are closed uncleanly
> ---
>
> Key: PROTON-764
> URL: https://issues.apache.org/jira/browse/PROTON-764
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.8
>Reporter: Ted Ross
>Priority: Minor
>
> In a multi-threaded environment (Qpid Dispatch), lost connections can result 
> in multiple calls to pn_connector_close for a given connector.  This results 
> in driver->close_count never returning to zero and the poll loop forever 
> running with a zero timeout.
> The reason for this is that pn_driver_wait_3 calls pn_connector_close when it 
> sees an error, even if that connector is currently being processed by another 
> thread.  I think that pn_driver_wait_3 should only flag the connector as 
> failed so the user can close it in the proper thread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-764) Driver is multi-thread-unsafe when connections are closed uncleanly

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-764:

Priority: Minor  (was: Major)

> Driver is multi-thread-unsafe when connections are closed uncleanly
> ---
>
> Key: PROTON-764
> URL: https://issues.apache.org/jira/browse/PROTON-764
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.8
>Reporter: Ted Ross
>Priority: Minor
> Fix For: 0.9
>
>
> In a multi-threaded environment (Qpid Dispatch), lost connections can result 
> in multiple calls to pn_connector_close for a given connector.  This results 
> in driver->close_count never returning to zero and the poll loop forever 
> running with a zero timeout.
> The reason for this is that pn_driver_wait_3 calls pn_connector_close when it 
> sees an error, even if that connector is currently being processed by another 
> thread.  I think that pn_driver_wait_3 should only flag the connector as 
> failed so the user can close it in the proper thread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-764) Driver is multi-thread-unsafe when connections are closed uncleanly

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-764:

Priority: Major  (was: Blocker)

> Driver is multi-thread-unsafe when connections are closed uncleanly
> ---
>
> Key: PROTON-764
> URL: https://issues.apache.org/jira/browse/PROTON-764
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.8
>Reporter: Ted Ross
> Fix For: 0.9
>
>
> In a multi-threaded environment (Qpid Dispatch), lost connections can result 
> in multiple calls to pn_connector_close for a given connector.  This results 
> in driver->close_count never returning to zero and the poll loop forever 
> running with a zero timeout.
> The reason for this is that pn_driver_wait_3 calls pn_connector_close when it 
> sees an error, even if that connector is currently being processed by another 
> thread.  I think that pn_driver_wait_3 should only flag the connector as 
> failed so the user can close it in the proper thread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PROTON-764) Driver is multi-thread-unsafe when connections are closed uncleanly

[Ted Ross (JIRA)]

Ted Ross created PROTON-764:
---

 Summary: Driver is multi-thread-unsafe when connections are closed 
uncleanly
 Key: PROTON-764
 URL: https://issues.apache.org/jira/browse/PROTON-764
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.8
Reporter: Ted Ross
Priority: Blocker
 Fix For: 0.9


In a multi-threaded environment (Qpid Dispatch), lost connections can result in 
multiple calls to pn_connector_close for a given connector.  This results in 
driver->close_count never returning to zero and the poll loop forever running 
with a zero timeout.

The reason for this is that pn_driver_wait_3 calls pn_connector_close when it 
sees an error, even if that connector is currently being processed by another 
thread.  I think that pn_driver_wait_3 should only flag the connector as failed 
so the user can close it in the proper thread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE]: migrate the proton repo to use git

[Ted Ross]

[ X ] Yes, migrate the proton repo over to git.

On 10/30/2014 06:59 AM, Rafael Schloming wrote:
> Hi Everyone,
> 
> I'm planning on updating the release script for 0.9 to automate the last
> few details of the release process and to do proper branching. Given that
> the release script must make use of the canonical repo to work properly, it
> occurs to me that if we're going to switch over to git then now would be a
> good time so that I only need to update the release script once. I'd
> therefore like to call for a formal vote to approve the switch.
> 
> [   ] Yes, migrate the proton repo over to git.
> [   ] No, keep it in svn.
> 
> --Rafael
> 

Re: VOTE: Release Proton 0.8 RC5 as 0.8 final

[Ted Ross]

[ X ] Yes, release Proton 0.8 RC5 as 0.8 final

I tested 0.8 against the Dispatch trunk.

On 10/27/2014 09:51 PM, Rafael Schloming wrote:
> Hi Everyone,
> 
> Sorry for the delay, there seemed to be some kind of Nexus outage today, so
> I was unable to generate the java binaries until just now.
> 
> I've posted RC5 in the usual places. The only difference from RC4 is a one
> line delta that replaces the assertion failure when we receive
> out-of-sequence ids with a connection shutdown error. Please have a look
> and register your vote.
> 
> Source code can be found here:
> 
> http://people.apache.org/~rhs/qpid-proton-0.8rc5/
> 
> Java binaries are here:
> 
> https://repository.apache.org/content/repositories/orgapacheqpid-1021
> 
> [   ] Yes, release Proton 0.8 RC5 as 0.8 final
> [   ] No, because ...
> 
> --Rafael
> 

Re: Intro to proton

[Ted Ross]

Hi Jake,

You are trying to run Proton (AMQP 1.0) against a broker that only talks
AMQP 0-10.  You need to make sure that the broker is loading the
"amqp.so" module so it can support the 1.0 protocol.

qpidd --load-module amqp.so

If you are building the broker from source, you need to make sure
Proton-c is installed or the build won't produce an amqp.so.

If you need further clarification, please ask.

-Ted

On 09/23/2014 01:26 PM, O'Hara, Jake wrote:
> Hello,
> 
> Our company is currently evaluating some AMQP technologies and one of the 
> ones we are interested in is proton.  We are currently having some trouble 
> getting a connection from the proton client to an Apache Qpid instance.  The 
> Qpid client connects with no problems, but when we use proton we get the 
> following error:
> 
> Calling pn_messenger_send()
> [003224B0]:ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
> 
> [003224B0]:ERROR[-2] SASL header mismatch: ''
> CONNECTION ERROR connection aborted (remote)
> 
> Any help/guidance you can provide to get us past this would be greatly 
> appreciated.
> 
> Thanks,
> 
> Jake O'Hara | Software Architect | Design & Development
> Aristocrat Technologies, Inc.
> tel 702 270 1217 | fax 702 270 1136
> email jake.oh...@aristocrat-inc.com | 
> web www.aristocratgaming.com
> P Please consider the environment before printing this e-mail
> 
> 
> 
> IMPORTANT CONFIDENTIALITY NOTICE:
> 
> This E-mail (including any documents referred to in, or attached, to this 
> E-mail) may contain information that is personal, confidential or the subject 
> of copyright or other proprietary rights in favor of Aristocrat, its 
> affiliates or third parties. This E-mail is intended only for the named 
> addressee. Any privacy, confidence, copyright or other proprietary rights in 
> favor of Aristocrat, its affiliates or third parties, is not lost because 
> this E-mail was sent to you by mistake.
> 
> If you received this E-mail by mistake you should: (i) not copy, disclose, 
> distribute or otherwise use it, or its contents, without the consent of 
> Aristocrat or the owner of the relevant rights; (ii) let us know of the 
> mistake by reply E-mail or by telephone (US 1-877-274-9661, or  AU +61 2 9013 
> 6000); and (iii) delete it from your system and destroy all copies.
> 
> Any personal information contained in this E-mail must be handled in 
> accordance with applicable privacy laws.
> 
> Electronic and internet communications can be interfered with or affected by 
> viruses and other defects. As a result, such communications may not be 
> successfully received or, if received, may cause interference with the 
> integrity of receiving, processing or related systems (including hardware, 
> software and data or information on, or using, that hardware or software). 
> Aristocrat gives no assurances in relation to these matters.
> 
> If you have any doubts about the veracity or integrity of any electronic 
> communication we appear to have sent you, please call (US 1-877-274-9661, or  
> AU +61 2 9013 6000) for clarification.
> 

[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:

Fix Version/s: 0.8

> Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
> -
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.6
>Reporter: Ted Ross
>Assignee: Cliff Jansen
> Fix For: 0.8
>
> Attachments: 08_fix_ipv6_windows.patch
>
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::1" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:

Assignee: Cliff Jansen

> Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
> -
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.6
>Reporter: Ted Ross
>Assignee: Cliff Jansen
> Attachments: 08_fix_ipv6_windows.patch
>
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::1" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-643) Malloc result used without testing for null

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-643:

Fix Version/s: 0.8

> Malloc result used without testing for null
> ---
>
> Key: PROTON-643
> URL: https://issues.apache.org/jira/browse/PROTON-643
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.7
>Reporter: Chuck Rolke
> Fix For: 0.8
>
>
> {noformat}
>   pn_buffer_t *buf = (pn_buffer_t *) malloc(sizeof(pn_buffer_t));
>   buf->capacity = capacity;
> {noformat}
> Many calls to malloc are properly checked but not all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proton Performance Pictures (1 of 2)

[Ted Ross]

On 09/03/2014 11:35 AM, Michael Goulish wrote:
> 
> 
> 
> 
> - Original Message -
>> On 09/03/2014 08:51 AM, Michael Goulish wrote:
>>> That point is where I seem to find the best performance on my
>>> system: 123,500 messages per second received.  ( i.e. 247,000
>>> transfers per second ) using about 180% CPU ( i.e. 90% each of
>>> 2 processors. )
>>
>> If you are sending direct between the sender and receiver process (i.e.
>> no intermediary process), then why are you doubling the number of
>> messages sent to get 'transfers per second'? One transfer is the sending
>> of a message from one process to another, which in this case is the same
>> as messages sent or received.
>>
> 
> Yes, this is interesting.
> 
> I need a way to make a fair comparison between something like this setup 
> (simple peer-to-peer) and the Dispatch Router numbers I was getting
> earlier.
> 
> 
> For the router, the analogous topology is
> 
> writer --> router --> reader
> 
> in which case I counted each message twice.
> 
> 
> 
> But it does not seem right to count a single message in
>writer --> router --> reader 
> as "2 transfers", while counting a single message in
>writer --> reader
> as only "1 transfer".
> 
> Because -- from the application point of view, those two topologies 
> are doing the same work.

You should probably be using "throughput" and not "transfers" in this case.

> 
> 
> 
> Also I think that I *need* to countwriter-->router-->reader   
> as "2", because in *this* case:
> 
> 
>  writer -->  router --> reader_1
>   \
>\--> reader_2
> 
> 
> ...I need to count that as "3" .
> 
> 
> 
> ? Thoughts ?
> 
> 

Re: proton engine performance: two strong credit management effects

[Ted Ross]

On 08/27/2014 03:05 PM, Andrew Stitcher wrote:
> On Wed, 2014-08-27 at 14:55 -0400, Andrew Stitcher wrote:
>> ...
>> Of this only applies under the exact circumstances of these tests, until
>> we have more data points. I'd suspect it must also depend on the message
>> size too.
>>
> 
> Just to reply to myself...
> 
> Keeping the credit window at around the MTU size is going to give you
> the most efficient networking transfers.

I'm not sure I'm following you here.  Credits are in units of messages
whereas MTU is in octets.

To avoid bad interactions with the Nagle algorithm in TCP, the credit
window multiplied by message size should exceed MTU (Maybe that was the
point you were originally making).

I think the network latency is going to have a bigger effect (i.e. the
number of messages and returning 'flow' frames in flight at the same
time in the network).

> 
> if looks like we get maximum throughput with at least 20 messages in
> flight at once. That is something over 1KiB and will pack them into few
> transfer units.
> 
> For regular ethernet the MTU is 1500, and for loopback on Linux it is
> 64KiB. So I'd guess that when the message is big enough it makes less
> difference. And it looks like once you can hit around 1KiB of content
> for each packet then you get small performance gain after that.
> 
> Andrew
> 

Re: proton engine performance: two strong credit management effects

[Ted Ross]

On 08/27/2014 02:55 PM, Andrew Stitcher wrote:
> On Wed, 2014-08-27 at 13:39 -0400, Michael Goulish wrote:
>>
>> conclusion
>> =
>>
>>
>> Using the proton engine interface  (in C)  I am seeing two 
>> aspects of credit management that can strongly affect 
>> throughput.
>>
>>
>> The first is "credit stall".  If you frequently allow the credit 
>> available to the sender to drop to zero, so that he has to cool
>> his heels waiting for more, that can have a very strong effect
>> even in my simple test case, in which the receiver is granting 
>> new credit as quickly as possible, and is serving only 1 sender.
>>
>>
>> The second effect is "credit replenishment amortization".
>> It looks like the granting of new credit is kind of an expensive 
>> operation.  If you do it too frequently, that will also have a 
>> noticeable effect on throughput.
> 
> So my conclusion looking at the graphs for these tests would be that you
> will get the vast majority of benefit by using an initial credit of 40
> and replenishing with 20 at 20.

Funny, those are the exact numbers I chose for the default in Dispatch
(based on Mick's conclusion).

I think the 'amortization' effect will be fairly independent of local
conditions whereas the outstanding credit value will be primarily tied
to network latency (i.e. you will want a larger window for networks with
higher latency).

> 
> Of this only applies under the exact circumstances of these tests, until
> we have more data points. I'd suspect it must also depend on the message
> size too.
> 
> Andrew
> 
> 
> 

[jira] [Commented] (PROTON-642) SASL Servers need to be able to optionally handle clients that don't use SASL

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14087749#comment-14087749
 ] 

Ted Ross commented on PROTON-642:
-

Commit 1616245 from [~tedross] in branch 'proton/trunk'
[ https://svn.apache.org/r1616245 ]

PROTON-485 - Make SASL server tolerant of clients that skip SASL

The above commit addresses the C implementation.  It also adds a test that 
fails against the Java implementation.  A fix to that is forthcoming.

> SASL Servers need to be able to optionally handle clients that don't use SASL
> -
>
> Key: PROTON-642
> URL: https://issues.apache.org/jira/browse/PROTON-642
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c, proton-j
>    Affects Versions: 0.7
>        Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.8
>
>
> A proton-based server that uses SASL for authentication needs to be able to 
> optionally accept connections from clients that do not use SASL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-485:


Attachment: (was: PROTON-485.patch)

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Priority: Minor
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14087748#comment-14087748
 ] 

Ted Ross commented on PROTON-485:
-

PROTON-642 was opened as a place to track the fix that was applied to this 
issue.  This issue shall remain open.

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Priority: Minor
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PROTON-642) SASL Servers need to be able to optionally handle clients that don't use SASL

[Ted Ross (JIRA)]

Ted Ross created PROTON-642:
---

 Summary: SASL Servers need to be able to optionally handle clients 
that don't use SASL
 Key: PROTON-642
 URL: https://issues.apache.org/jira/browse/PROTON-642
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c, proton-j
Affects Versions: 0.7
Reporter: Ted Ross
Assignee: Ted Ross
 Fix For: 0.8


A proton-based server that uses SASL for authentication needs to be able to 
optionally accept connections from clients that do not use SASL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-485:


Assignee: (was: Ted Ross)

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Priority: Minor
> Attachments: PROTON-485.patch
>
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-485:


Fix Version/s: (was: 0.8)

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Priority: Minor
> Attachments: PROTON-485.patch
>
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross resolved PROTON-485.
-

Resolution: Fixed

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Assignee: Ted Ross
>Priority: Minor
> Fix For: 0.8
>
> Attachments: PROTON-485.patch
>
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross reassigned PROTON-485:
---

Assignee: Ted Ross

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Assignee: Ted Ross
>Priority: Minor
> Fix For: 0.8
>
> Attachments: PROTON-485.patch
>
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-485:


Attachment: PROTON-485.patch

Updated patch...

Adds a method to sasl called "allow_skip" that allows a server application to 
indicate whether it will allow remote clients to skip the SASL exchange.  The 
default behavior remains unchanged (fail if the client skips the exchange), but 
the error message is improved in this case.

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Priority: Minor
> Fix For: 0.8
>
> Attachments: PROTON-485.patch
>
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-485:


Attachment: (was: PROTON-485.patch)

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Priority: Minor
> Fix For: 0.8
>
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-485:


Attachment: PROTON-485.patch

The attached patch allows the server to gracefully handle a client that doesn't 
use SASL.  A new SASL outcome, SKIPPED, has been added to indicate to the 
server side that the client skipped the SASL exchange and went straight to AMQP.


> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Priority: Minor
> Fix For: 0.8
>
> Attachments: PROTON-485.patch
>
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084585#comment-14084585
 ] 

Ted Ross commented on PROTON-485:
-

The SASL transport layer should handle a peer that doesn't use SASL.  
Currently, if one side enables SASL and the other doesn't, both sides fail with 
obscure framing errors.  I will attach a patch shortly.

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Priority: Minor
> Fix For: 0.8
>
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-485) Make SASL authentication optional

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-485:


Fix Version/s: 0.8

> Make SASL authentication optional
> -
>
> Key: PROTON-485
> URL: https://issues.apache.org/jira/browse/PROTON-485
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.5
>Reporter: Andreas Mueller
>Priority: Minor
> Fix For: 0.8
>
>
> Disabling SASL should be an option in proton to connect to simple AMQP 
> services that do not provide SASL or just to skip this additional step if 
> SASL is not required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: landing events branch

[Ted Ross]

Another heads-up... I've updated dispatch-router to use the newly landed
events in Proton.  If you are building dispatch from source, you will
need the latest Proton trunk.

-Ted

On 07/10/2014 12:41 PM, Rafael Schloming wrote:
> Hi Everyone,
> 
> I wanted to give people a quick heads up. I would like to land the events
> branch soon. If you don't use the events API then this probably won't
> impact you, however if you do then you may experience some compilation
> failures. This is because of the following changes:
> 
> The PN_{CONNECTION,SESSION,LINK}_LOCAL_STATE events have been decomposed
> into two distinct events:
> 
>   PN_{CONNECTION,SESSION,LINK}_OPEN and PN_{CONNECTION,SESSION,LINK}_CLOSE
> 
> Similarly, PN_{CONNECTION,SESSION,LINK}_REMOTE_STATE has been decomposed
> into:
> 
>   PN_{CONNECTION,SESSION,LINK}_REMOTE_OPEN and
> PN_{CONNECTION,SESSION,LINK}_REMOTE_CLOSE
> 
> To fix your code all you need to do is adjust your switch statements to
> match on the new names, e.g. something like this:
> 
> ...
> case PN_CONNECTION_REMOTE_STATE:
> ...
> 
> Would become something like this:
> 
> ...
> case PN_CONNECTION_REMOTE_OPEN: // fall through
> case PN_CONNECTION_REMOTE_CLOSE:
> ...
> 
> Please give me a shout if this will cause a problem for you, otherwise I
> will land the branch in a day or two.
> 
> --Rafael
> 

[jira] [Reopened] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross reopened PROTON-548:
-


I'm re-opening this issue so we can track this as it is implemented also for 
Windows.

> Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
> -
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.6
>Reporter: Ted Ross
>Assignee: Ted Ross
> Attachments: 14_fix_ipv6_windows.patch
>
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::1" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:


Assignee: (was: Ted Ross)

> Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
> -
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.6
>Reporter: Ted Ross
> Attachments: 14_fix_ipv6_windows.patch
>
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::1" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PROTON-586) Driver spins when a listener accepts a socket while FDs are all in use

[Ted Ross (JIRA)]

Ted Ross created PROTON-586:
---

 Summary: Driver spins when a listener accepts a socket while FDs 
are all in use
 Key: PROTON-586
 URL: https://issues.apache.org/jira/browse/PROTON-586
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.7
Reporter: Ted Ross


when operating as a server and using listeners, if the number of open FDs is 
equal to the limit on FDs, accept will return an error and the driver will spin 
at 100% cpu until an FD is freed up for the incoming connection.

Suggested fix:

If "accept" returns a "too many open files" error (ENFILE or EMFILE), the 
listening socket should be taken out of the read-fds for a time (say one 
second) before retrying.

If this is not practical to do in Proton, the driver should provide hooks for 
the encapsulating application to use to provide this holdoff.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PROTON-567) Segmentation fault

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978257#comment-13978257
 ] 

Ted Ross commented on PROTON-567:
-

If you could provide a small reproducer for others to try that causes the 
crash, that would be helpful.



> Segmentation fault
> --
>
> Key: PROTON-567
> URL: https://issues.apache.org/jira/browse/PROTON-567
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: php-binding
>Affects Versions: 0.6
>Reporter: Denis Savrukov
> Attachments: php-mem-dump.log
>
>
> Unexpectedly segmentation fault had become occurring after this night 
> 2014-04-22 / 2014-04-23
> We use WindowsAzure account, service bus hasn't changed, php-code hasn't 
> changed this night
> Memory dump's attached
> Any more details?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PROTON-567) Segmentation fault

[Ted Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978094#comment-13978094
 ] 

Ted Ross commented on PROTON-567:
-

It looks like some form of memory mismanagement.  The Proton libraries don't 
appear in the backtrace.  Do you have any particular reason to suspect that 
Proton is causing the problem?


> Segmentation fault
> --
>
> Key: PROTON-567
> URL: https://issues.apache.org/jira/browse/PROTON-567
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: php-binding
>Affects Versions: 0.6
>Reporter: Denis Savrukov
> Attachments: php-mem-dump.log
>
>
> Unexpectedly segmentation fault had become occurring after this night 
> 2014-04-22 / 2014-04-23
> We use WindowsAzure account, service bus hasn't changed, php-code hasn't 
> changed this night
> Memory dump's attached
> Any more details?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE]: Release Proton 0.7 RC4 as 0.7 final

[Ted Ross]

+1

On 04/22/2014 07:12 AM, Rafael Schloming wrote:
> Hi Everyone,
> 
> I haven't heard of any issues in RC4, so I'm going to put this to a formal
> vote now:
> 
> Source artifacts are here:
> 
>   - http://people.apache.org/~rhs/qpid-proton-0.7rc4/
> 
> Java binaries are here:
> 
>  - https://repository.apache.org/content/repositories/orgapacheqpid-1004/
> 
> Please review and register your vote:
> 
>   [ ] Yes, release 0.7 RC4 as 0.7 final
>   [ ] No, 0.7 RC4 as the following issues...
> 
> 
> Thanks,
> 
> --Rafael
> 

Re: new team working with AMQP and Apache Qpid Proton

[Ted Ross]

Rob and team,

Thanks for the introduction and welcome to the project.

The mission of Qpid Proton is to encourage adoption of AMQP and to make
it as easy as possible to integrate AMQP into anything and everything.
As such, I think your goals are in alignment with the project's goals.

I'll address your specific questions in-line below:

On 04/17/2014 08:36 AM, Rob Nicholson wrote:
> Hello proton mailing list. 
> 
> I think that some folks here have noticed that within IBM we have an 
> incubator project called MQ Light [1] which is using the AMQP 1.0 wire 
> protocol and is making use of Apache Qpid Proton both standalone[1] and in 
> our cloud PaaS incubator [2]. 
> Up until this point we have been largely in listen mode on the mailing 
> list but now we will be engaging with the community so we thought it would 
> be polite to introduce ourselves, what we are doing and how we are 
> thinking of engaging with you.
> 
> Currently we use the proton C messenger API in our client and the Java 
> messaging API in our "server" which uses code derived from IBM's Websphere 
> MQ products. 
> 
> We have raised some Jiras, we plan to raise more for some specific 
> problems we have had, supplying patches which show how we worked around or 
> addressed each problem we had. 
> 
> We also have some of more strategic queries the first of which are:
> 
>  - We are finding that we need to extend Messenger in order to make it 
> capable of doing what we want it to. Is this valid or did you want to keep 
> messenger really simple.   Should we just supply patches for these 
> extensions also? 

Others have also identified gaps in Messenger, specifically in allowing
it to be integrated into an existing program's poll loop and to run
asynchronously.

We always welcome patches, but this is a case where a discussion of the
gaps you've identified is appropriate so we can arrive at a solution
that solves the real problems without muddying the API.

> 
> -  We want to create language bindings for MQ Light which are _really_ 
> easy to use by programmers in that language. Specifically we find these 
> bindings need to understand our messaging model. AMQP does not have a 
> preconceived idea of a messaging model. We would like to put all of the 
> client code into open source but do these language bindings belong in the 
> Proton project? If not, I suspect we'll create a separate project which 
> has a dependency to proton. 

It is in AMQP's best interest for there to be freely available bindings
that are easy to use.  It is also consistent with Qpid's purpose to have
them hosted here.

I'd like to understand more about the implications of your messaging
model and whether clients built for that model can be used with other
messaging services.  Such a conversation would help determine whether
these clients belong in Proton or as a separate sub-project.

> 
> -  As we have consumed the Java engine API we have run up against some 
> threading issues. This might be because we do not understand the threading 
> model in the Engine.  At some point we'd like to have a design discussion 
> with the community on the threading model in the Engine implementation. 

There is at least one team within Red Hat that has also identified
threading and performance issues with the Proton-J engine.  We should
work together to identify and fix the problems.

> 
> 
> [1] https://www.ibmdw.net/messaging/mq-light/
> [2] http://www.bluemix.net
> [3] https://www.npmjs.org/package/mqlight
> 
> 
> Regards,
> 
> Rob Nicholson
> CEng MEng FBCS CITP
> 
> 

-Ted

[jira] [Resolved] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross resolved PROTON-548.
-

Resolution: Fixed
  Assignee: Ted Ross

> Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
> -
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.6
>Reporter: Ted Ross
>Assignee: Ted Ross
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::1" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:


Attachment: (was: PROTON-548.patch)

> Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
> -
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.6
>Reporter: Ted Ross
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::1" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-548) Proton-C driver doesn't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:


Component/s: proton-j

> Proton-C driver doesn't support AF_INET6 (IPv6)
> ---
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.6
>Reporter: Ted Ross
> Attachments: PROTON-548.patch
>
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::1" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:


Summary: Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)  
(was: Proton-C driver doesn't support AF_INET6 (IPv6))

> Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
> -
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Affects Versions: 0.6
>Reporter: Ted Ross
> Attachments: PROTON-548.patch
>
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::1" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-548) Proton-C driver doesn't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:


Description: 
The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
address family associated with a particular address.

On systems that enable IPv6, the address "localhost" cannot be used because it 
resolves to "::1" rather than "127.0.0.1"


  was:
The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
address family associated with a particular address.

On systems that enable IPv6, the address "localhost" cannot be used because it 
resolves to "::0" rather than "127.0.0.1"



> Proton-C driver doesn't support AF_INET6 (IPv6)
> ---
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.6
>Reporter: Ted Ross
> Attachments: PROTON-548.patch
>
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::1" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-548) Proton-C driver doesn't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:


Attachment: PROTON-548.patch

Proposed patch.


> Proton-C driver doesn't support AF_INET6 (IPv6)
> ---
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.6
>Reporter: Ted Ross
> Attachments: PROTON-548.patch
>
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::0" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-548) Proton-C driver doesn't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:


Attachment: (was: PROTON-548.patch)

> Proton-C driver doesn't support AF_INET6 (IPv6)
> ---
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.6
>Reporter: Ted Ross
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::0" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (PROTON-548) Proton-C driver doesn't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:


Comment: was deleted

(was: Proposed fix.  I've tested this with Dispatch and have verified that all 
of the following addresses work correctly:
  - 0.0.0.0
  - 127.0.0.1
  - localhost
  - ::0
)

> Proton-C driver doesn't support AF_INET6 (IPv6)
> ---
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.6
>Reporter: Ted Ross
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::0" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PROTON-548) Proton-C driver doesn't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated PROTON-548:


Attachment: PROTON-548.patch

Proposed fix.  I've tested this with Dispatch and have verified that all of the 
following addresses work correctly:
  - 0.0.0.0
  - 127.0.0.1
  - localhost
  - ::0


> Proton-C driver doesn't support AF_INET6 (IPv6)
> ---
>
> Key: PROTON-548
> URL: https://issues.apache.org/jira/browse/PROTON-548
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.6
>Reporter: Ted Ross
> Attachments: PROTON-548.patch
>
>
> The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
> address family associated with a particular address.
> On systems that enable IPv6, the address "localhost" cannot be used because 
> it resolves to "::0" rather than "127.0.0.1"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PROTON-548) Proton-C driver doesn't support AF_INET6 (IPv6)

[Ted Ross (JIRA)]

Ted Ross created PROTON-548:
---

 Summary: Proton-C driver doesn't support AF_INET6 (IPv6)
 Key: PROTON-548
 URL: https://issues.apache.org/jira/browse/PROTON-548
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.6
Reporter: Ted Ross


The proton-c driver hard-codes its sockets to AF_INET, rather than using the 
address family associated with a particular address.

On systems that enable IPv6, the address "localhost" cannot be used because it 
resolves to "::0" rather than "127.0.0.1"




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PROTON-541) Problems with multi-frame deliveries

[Ted Ross (JIRA)]

Ted Ross created PROTON-541:
---

 Summary: Problems with multi-frame deliveries
 Key: PROTON-541
 URL: https://issues.apache.org/jira/browse/PROTON-541
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.6
Reporter: Ted Ross


I made a modification to messenger.c to configure the maximum frame size on 
transports (there is no API access to this configuration) and then ran a 
point-to-point test between a sender and a passive receiver using messages 
larger than the frame max.

The receiver crashes with the following assertion after several dozen messages 
are transferred successfully.

python: /home/ross/svn/proton/proton-c/src/message/message.c:653: 
pn_message_decode: Assertion `msg && bytes && size' failed.

Another observation:
When the max-frame-size is specified only by one side of the connection, there 
is no negotiation.  Frames larger than the specified max are transferred.  It 
is not clear from the specification (2.7.1) whether max-frame-size is intended 
to be symmetric and apply to transfers in both directions on the connection.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Anonymous Producers

[Ted Ross]

You have the option of leaving the target of a producer link empty and 
putting the destination in the "to" field of each message sent on the link.


-Ted

On 03/20/2014 11:36 PM, Clebert Suconic wrote:

A common JMS feature is to have a Producer being anonymous and define the 
address only when the message is sent.


We do the same on HornetQ core API.. However from my first look on the Proton 
API I always need to define the source and the target?

Is there a way to define the destination per message sent?


How do you handle this at the current qpid JMS Client? From what I understand 
on the API it will then declare a new LINK when a new destination is set.. is 
that right?


That means there are no anonymous links or a way to alter the target during the 
message send? no such thing as deliver.send(message, *destination*)?

Re: Proton 0.7 RC1

[Ted Ross]

I tested this RC standalone and against Dispatch trunk.  Everything 
worked as I expected.


One note on the README:  I tested on a stripped down Fedora 20 image and 
I had to install two additional packages to those listed in the README:


- rubygem-minitest
- maven

-Ted

On 03/14/2014 04:25 PM, Rafael Schloming wrote:

Hi Everyone,

There's been a bunch of key improvements/fixes since Proton 0.6, so it's
probably about time for a new release. I've just posted the first RC in the
usual places. Please check it out and give a shout if you run into any
issues.

Source artifacts:

   http://people.apache.org/~rhs/qpid-proton-0.7rc1/

Java binaries:

   https://repository.apache.org/content/repositories/orgapacheqpid-1001/

--Rafael

Re: Source/Target Question

[Ted Ross]

Based on a discussion with Gordon, I'm not going to use source vs. 
target to infer any intent on the part of the peer node.


I am, however, still interested in the answer to the question.

-Ted

On 02/21/2014 03:02 PM, Ted Ross wrote:
I'm working on a feature for Dispatch Router that will allow it to 
intermediate between clients and brokers.  This raises a question 
about how Proton Messenger handles targets and sources in links.


Consider a subscriber using Messenger:

from proton import Messenger
M = Messenger()
M.start()
sub = M.subscribe("amqp://0.0.0.0/name")

The resulting incoming link (from Messenger's perspective) has a 
source of "name" and a target of "name".


The above code can have two meanings:  "I am a service called 'name' 
and I wish to begin receiving messages" or "I wish to receive messages 
from a node called 'name'".


As I understand it, the first meaning should be indicated by setting 
the target and the second meaning by setting the source. Since both 
source and target are set, the intent of the node is ambiguous.


From an API perspective, how should a Messenger program indicate which 
flavor of subscription it is establishing?


-Ted

Source/Target Question

[Ted Ross]

I'm working on a feature for Dispatch Router that will allow it to 
intermediate between clients and brokers.  This raises a question about 
how Proton Messenger handles targets and sources in links.


Consider a subscriber using Messenger:

from proton import Messenger
M = Messenger()
M.start()
sub = M.subscribe("amqp://0.0.0.0/name")

The resulting incoming link (from Messenger's perspective) has a source 
of "name" and a target of "name".


The above code can have two meanings:  "I am a service called 'name' and 
I wish to begin receiving messages" or "I wish to receive messages from 
a node called 'name'".


As I understand it, the first meaning should be indicated by setting the 
target and the second meaning by setting the source. Since both source 
and target are set, the intent of the node is ambiguous.


From an API perspective, how should a Messenger program indicate which 
flavor of subscription it is establishing?


-Ted

Re: error when building proton

[Ted Ross]

There's one other thing to be careful of...  Once CMake determines that 
it's not there, it will not reconsider after you've installed the 
dependency.  Make sure you delete your whole build directory and 
re-configure.


-Ted

On 02/05/2014 12:02 PM, Roberto Pagliari wrote:

Hi Alan,
I have uuid-dev installed but it still cannot find it. Is there a flag on
the CMakeLists file? I can't see it when running ccmake.


Thank you,
Roberto



On Wed, Feb 5, 2014 at 11:07 AM, Alan Conway  wrote:


On Tue, 2014-02-04 at 17:50 -0500, Roberto Pagliari wrote:

I'm getting this error when using ccmake to build proton (on Ubuntu 12)


  CMake Error at proton-c/CMakeLists.txt:126 (message):
No Uuid API found


does anyone know how to fix it? I can't find this flag in ccmake gui and
uuid is available on my system.



You may need uuid-devel or whatever is the equivalent package on your
distribution. E.g. on fedora 20 the libuuid package contains the uuid
library, but libuuid-devel contains the .h files that are also needed to
build proton.

[jira] [Created] (PROTON-510) hostname field in the Open command is not set

[Ted Ross (JIRA)]

Ted Ross created PROTON-510:
---

 Summary: hostname field in the Open command is not set
 Key: PROTON-510
 URL: https://issues.apache.org/jira/browse/PROTON-510
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.6
Reporter: Ted Ross


If an address of the form "amqp://dns.domain.com/path" is used in 
Proton/Messenger, when the connection is opened, the hostname field in the Open 
should contain "dns.domain.com".




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Qpid Proton messenger on 32 bit linux

[Ted Ross]

I haven't had a change to try it yet.

I think we typically use "-m32 -march=i686"

-Ted

On 01/29/2014 09:56 AM, serega wrote:

The attached example is a  send.c
   slightly modified
send.c example. It works in 64 bit environment, but crashes when proton is
build with export CFLAGS=-m32  . Can you execute it on 32 bit linux?

Thanks,
Sergey.



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Qpid-Proton-messenger-on-32-bit-linux-tp7603445p7603555.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.

Re: Qpid Proton messenger on 32 bit linux

[Ted Ross]

I routinely run tests using Messenger in a 32-bit Linux environment and 
I've never had a problem with it.  Are you building on a 64-bit machine 
or in a complete 32-bit environment?


-Ted

On 01/27/2014 03:43 PM, serega wrote:

Does the messenger work on 32 bit linux? I build the 32 bit messenger by
setting the variable
export CFLAGS=-m32

The same code that works on 64 bit linux crates on 32.  It always crashes in
pn_encoder_writef8
Here is the crash stack trace from a core dump

Core was generated by `./testconsumer 10.250.0.126 10.250.0.127 1000'.
Program terminated with signal 11, Segmentation fault.
#0  0x00d89877 in pn_encoder_writef8 () from
/usr/local/lib/libqpid-proton.so.2
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.80.el6_3.7.i686 libuuid-2.17.2-12.7.el6_3.i686
(gdb) bt
#0  0x00d89877 in pn_encoder_writef8 () from
/usr/local/lib/libqpid-proton.so.2
#1  0x00d89d4c in pni_encoder_enter () from
/usr/local/lib/libqpid-proton.so.2
#2  0x00d85d66 in pni_data_traverse () from
/usr/local/lib/libqpid-proton.so.2
#3  0x00d8a6e5 in pn_encoder_encode () from
/usr/local/lib/libqpid-proton.so.2
#4  0x00d863ec in pn_data_encode () from /usr/local/lib/libqpid-proton.so.2
#5  0x00d8af95 in pn_post_frame () from /usr/local/lib/libqpid-proton.so.2
#6  0x00d930f7 in pn_flush_disp () from /usr/local/lib/libqpid-proton.so.2
#7  0x00d93971 in pn_process_flush_disp () from
/usr/local/lib/libqpid-proton.so.2
#8  0x00d93f94 in pn_phase () from /usr/local/lib/libqpid-proton.so.2
#9  0x00d940c0 in pn_process () from /usr/local/lib/libqpid-proton.so.2
#10 0x00d942e2 in pn_output_write_amqp () from
/usr/local/lib/libqpid-proton.so.2
#11 0x00d94a28 in pn_io_layer_output_passthru () from
/usr/local/lib/libqpid-proton.so.2
#12 0x00d94a28 in pn_io_layer_output_passthru () from
/usr/local/lib/libqpid-proton.so.2
#13 0x00d944cd in transport_produce () from
/usr/local/lib/libqpid-proton.so.2
#14 0x00d94de7 in pn_transport_pending () from
/usr/local/lib/libqpid-proton.so.2
#15 0x00da0726 in pn_connector_process () from
/usr/local/lib/libqpid-proton.so.2
#16 0x00d9b1bf in pn_messenger_tsync () from
/usr/local/lib/libqpid-proton.so.2
#17 0x00d9b503 in pn_messenger_sync () from
/usr/local/lib/libqpid-proton.so.2
#18 0x00d9d279 in pn_messenger_recv () from
/usr/local/lib/libqpid-proton.so.2
#19 0x0065f10c in run_consumer (args=0x8dc7198) at messageconsumer.c:104
#20 0x0050fa49 in start_thread () from /lib/libpthread.so.0
#21 0x0035863e in clone () from /lib/libc.so.6
(gdb)




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Qpid-Proton-messenger-on-32-bit-linux-tp7603445.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.