Re: improving cross language maintainability
On Thu, Dec 19, 2013 at 2:44 PM, Ken Giusti wrote: > Sorry for top-posting. I'm trying to understand the consequences of what > you are proposing. > > First, as I understand it, there are two separate test suites in the > proton tree: one written in Java - containing 19 tests as you point out - > and a much larger one written in python. Each test suite exercises both > the Java and C implementations. By testing both implementations using the > same tests, we ensure consistency across the two implementations (some, as > a lot of the python tests are skipped) > > What you're proposing would remove the ability for the Java test suite to > exercise the C implementation, right? > Yes, it would remove the ability for Java tests to exercise C code by calling it through JNI. We do have the interop test suite which checks that there is common behaviour without using JNI, i.e. by comparing binary output of codec and such across languages and I can imagine a number of other ways we could test for common behaviour that would not involve Java code calling into C code, e.g. comparing protocol traces, or running interop scenarios over the wire. > > This means that only the python test suite would be used to ensure cross > implementation consistency (Java v. C), right? > Yes > > What doesn't change is the two python wrapper implementations - one that > wraps the Java API, the other wraps the C API - that are used by the python > test suite to test both implementations. We'd still have to keep both of > those sync'ed. > Correct, although I believe there are some ways that we can significantly improve the commonality between the two python wrapper implementations (shims), and I suspect this will also improve the consistency of the APIs as well. > > If all my assumptions above are correct, then I can live with this. It > still ensures (some) consistency checking between the two implementations. > Drift between the two python wrappers could be caught by the tests > themselves, so I'm not too concerned about that. > > I'd like to see that time saved maintaining two test beds invested in > bringing both implementations to parity - IMHO we're skipping far too many > tests due to feature disparity. > Agreed. --Rafael
Re: improving cross language maintainability
On Thu, Dec 19, 2013 at 9:01 AM, Darryl L. Pierce wrote: > On Thu, Dec 19, 2013 at 08:49:59AM -0500, Rafael Schloming wrote: > > > I would love to hear thoughts and/or alternative ideas on how to improve > > things. I would like to start addressing this early in the 0.7 > development > > cycle. > > In a similar way, I'm trying to keep our Ruby and Perl bindings in > parity as best I can with what's going on in the C and Python code. Can > we use JIRA to create umbrella tasks for when new features are added, > with subtasks that are binding specific? Or if there's a change to the C > code that would require a change in the bindings, have the C code be the > top JIRA and the language bindings be subtasks to that? That way I > wouldn't need to look through commits to see what's changed in C to know > what should be added to the other languages. > > Also, could we add a component for each of the language bindings? It > doesn't feel right to add a JIRA for something in Ruby that's at the > Ruby level but have its component be "proton-c". > It certainly makes sense to make it as easy as possible to track what is going on, and I can see how that would help keep bindings up to date where there is interest and resources to do so. However we do this though, I don't want to just brainlessly duplicate each C jira across every binding (not that you're necessarily suggesting this). The problem I have with that approach is that there isn't equivalent interest/resources associated with each binding, so e.g. if we were to make every JIRA a full umbrella that depends on sub tasks for each binding we would continually accumulate php jiras that never end up getting closed off because we don't keep php as up to date as the other bindings, and this in turn would cause the umbrella JIRAs to never get closed off. Jira is really a task oriented tool, and I think JIRAs should really only be created when there is intention/interest to actually complete the task they represent, otherwise they usually end up being noise/clutter that will eventually be irrelevant and out of date. I'd suggest that perhaps a more document oriented description of those features for which we are trying to keep parity would possibly be helpful. All that said, I'm certainly sure we can improve our usage of JIRA, and I've gone ahead and added ruby-binding, python-binding, perl-binding, and php-binding components as you suggest. --Rafael
Re: improving cross language maintainability
Sorry for top-posting. I'm trying to understand the consequences of what you are proposing. First, as I understand it, there are two separate test suites in the proton tree: one written in Java - containing 19 tests as you point out - and a much larger one written in python. Each test suite exercises both the Java and C implementations. By testing both implementations using the same tests, we ensure consistency across the two implementations (some, as a lot of the python tests are skipped) What you're proposing would remove the ability for the Java test suite to exercise the C implementation, right? This means that only the python test suite would be used to ensure cross implementation consistency (Java v. C), right? What doesn't change is the two python wrapper implementations - one that wraps the Java API, the other wraps the C API - that are used by the python test suite to test both implementations. We'd still have to keep both of those sync'ed. If all my assumptions above are correct, then I can live with this. It still ensures (some) consistency checking between the two implementations. Drift between the two python wrappers could be caught by the tests themselves, so I'm not too concerned about that. I'd like to see that time saved maintaining two test beds invested in bringing both implementations to parity - IMHO we're skipping far too many tests due to feature disparity. - Original Message - > From: "Rafael Schloming" > To: proton@qpid.apache.org > Sent: Thursday, December 19, 2013 8:49:59 AM > Subject: improving cross language maintainability > > Hi Everyone, > > I've been struggling with some of the cross language maintenance aspects of > proton for a while, and I believe we need to take some steps to improve the > situation. I'm one of a tiny number of people (two possibly) who regularly > commit changes to both the Java and C codebase and attempt to keep the two > in sync and at feature parity. Because of this, not everyone is necessarily > aware of the process, but to summarize the issue, currently there are far > too many moving parts and layers of indirection involved. This is not only > a significant drag on my personal productivity, but perhaps more > importantly it is a significant barrier to growing the number of proton > contributors in general as all those moving parts and layers of indirection > need to be understood before being able to make complete contributions. > > To get an idea of what's going on here I think it helps to look at what's > involved in a simple change. Recently I noticed an edge case around status > updates in the messenger interface. The fix involved adding another value > to messenger's status enum and making a trivial logic change to make use of > that value under the appropriate circumstances. You can look at the full > commit here[1] if you like, but it breaks down in the following way: > > Changes to C implementation (.h and .c file): 8 LOC > Changes to the python test shim for C: 3 LOC > Changes to the Java API: 2 LOC > Changes to the pure Java implementation: 6 LOC > Changes to the JNI binding: 4 LOC > Changes to the python test shim for Java: 3 LOC > Changes to the python test suite: 2 LOC > > Now obviously from a personal productivity perspective it is at a minimum > annoying to have to touch so many different parts in order to make even a > trivial change, but setting that aside for the moment, what is really > sobering about this is that each one of the above parts involve a non > trivial learning curve on their own, and while it's true that only a few > lines of code are needed in each area, it is necessary to understand each > piece before being able to write the correct few lines of code. This > presents a pretty daunting hurdle for bringing new contributors to the > codebase up to the level needed to make even a trivial change like the one > above. > > The JNI binding and the python test shim for Java both exist to serve > similar purposes, namely to facilitate running a common test suite against > both implementations in order to ensure common behaviour. The python test > shims allow the python test suite to run against both proton-c and proton-j > (via jython), and the JNI binding allows pure Java tests to be run against > proton-c as well as proton-j. > > Currently by my count there are about 19 such tests in Java. By comparison > there are about 266 tests in the python test suite. Also, judging by > commits, the python test suite is growing/actively maintained, and the java > system tests (the subset of java tests that are run against both > implementations) are neither. On top of this the JNI binding itself has > suffered significantly from bit rot. As far as I know it is not made use of > outside of our own test infrastructure, and currently about 50% of the > tests run against it are skipped because it is only minimally maintained > when necessary to get the tests to pass. > > Because of a
Proton 0.6 RC3
Hi Everyone, I've put out an RC3 with fixes to the issues people have noted so far with RC2. You can find the source tarballs here: http://people.apache.org/~rhs/qpid-proton-0.6rc3/ The java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-003/ I've attached the list of changes since RC2. --Rafael r1552390 | rhs | 2013-12-19 13:22:51 -0500 (Thu, 19 Dec 2013) | 1 line PROTON-420: modified pn_messenger_route comment to use alternative detailed block syntax to avoid comment warnings due to embedded examples containing /\* r1552341 | mcpierce | 2013-12-19 11:29:19 -0500 (Thu, 19 Dec 2013) | 3 lines PROTON-482: Fix the Ruby install directory. Use vendorarchdir rather than vendorlibdir. r1552223 | rhs | 2013-12-18 22:48:51 -0500 (Wed, 18 Dec 2013) | 1 line added released status r1552221 | rhs | 2013-12-18 22:41:15 -0500 (Wed, 18 Dec 2013) | 1 line PROTON-420: added error.h portion of patch r1552218 | rhs | 2013-12-18 22:16:12 -0500 (Wed, 18 Dec 2013) | 1 line fixed braino in PROTON-439
[jira] [Commented] (PROTON-420) Warnings Presented When Using Strict Compiler Flags
[
https://issues.apache.org/jira/browse/PROTON-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853095#comment-13853095
]
ASF subversion and git services commented on PROTON-420:
Commit 1552390 from r...@apache.org in branch 'proton/trunk'
[ https://svn.apache.org/r1552390 ]
PROTON-420: modified pn_messenger_route comment to use alternative detailed
block syntax to avoid comment warnings due to embedded examples containing /\*
> Warnings Presented When Using Strict Compiler Flags
> ---
>
> Key: PROTON-420
> URL: https://issues.apache.org/jira/browse/PROTON-420
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.5
> Environment: GCC 4.4.7
>Reporter: Frank Quinn
> Attachments:
> FIX-Warnings-Presented-When-Using-Strict-Compiler-Flags-PROTON-420.patch
>
>
> Hi Folks,
> In our project, we currently use the following compiler flags for gcc (tested
> in version 4.4.7):
> -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes
> -Werror
> Unfortunately this causes problems in recent versions of proton as its
> headers produce some warnings of their own. The ones we have spotted can be
> recreated using the following code:
> #include
> #include
> int main(){}
> Compiled with:
> $ gcc -Wall -Wdeclaration-after-statement -Wmissing-prototypes
> -Wstrict-prototypes -Werror -I./qpid-proton-0.5/proton-c/include/ test.c -o
> test
> cc1: warnings being treated as errors
> In file included from test.c:1:
> ./qpid-proton-0.5/proton-c/include/proton/error.h:46: error: function
> declaration isn’t a prototype
> In file included from test.c:2:
> ./qpid-proton-0.5/proton-c/include/proton/messenger.h:458:29: error: "/*"
> within comment
> ./qpid-proton-0.5/proton-c/include/proton/messenger.h:466:40: error: "/*"
> within comment
> ./qpid-proton-0.5/proton-c/include/proton/messenger.h:470:32: error: "/*"
> within comment
> ./qpid-proton-0.5/proton-c/include/proton/messenger.h:475:34: error: "/*"
> within comment
> test.c:4: error: function declaration isn’t a prototype
> The first one can be resolved by changing pn_error() to pn_error(void) and
> the others can be fixed simply by adding some spacing. We typically just hack
> our local copies for testing, but we figured it may be better to get this
> into the main code stream if you guys can find the time to put it in.
> Cheers,
> Frank
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (PROTON-482) Ruby bindings install to vendorarchdir rather than vendorlibdir
[ https://issues.apache.org/jira/browse/PROTON-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved PROTON-482. - Resolution: Fixed Fix Version/s: 0.6 > Ruby bindings install to vendorarchdir rather than vendorlibdir > --- > > Key: PROTON-482 > URL: https://issues.apache.org/jira/browse/PROTON-482 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > Fix For: 0.6 > > > The vendorarchdir is the proper location on Ruby (1.8.7+) for platform > specific code, like the Ruby bindings. If this isn't found (Ruby 1.8.6) then > sitearchdir should be used. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (PROTON-482) Ruby bindings install to vendorarchdir rather than vendorlibdir
[ https://issues.apache.org/jira/browse/PROTON-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853013#comment-13853013 ] ASF subversion and git services commented on PROTON-482: Commit 1552341 from [~mcpierce] in branch 'proton/trunk' [ https://svn.apache.org/r1552341 ] PROTON-482: Fix the Ruby install directory. Use vendorarchdir rather than vendorlibdir. > Ruby bindings install to vendorarchdir rather than vendorlibdir > --- > > Key: PROTON-482 > URL: https://issues.apache.org/jira/browse/PROTON-482 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > Fix For: 0.6 > > > The vendorarchdir is the proper location on Ruby (1.8.7+) for platform > specific code, like the Ruby bindings. If this isn't found (Ruby 1.8.6) then > sitearchdir should be used. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (PROTON-482) Ruby bindings install to vendorarchdir rather than vendorlibdir
[ https://issues.apache.org/jira/browse/PROTON-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated PROTON-482: Description: The vendorarchdir is the proper location on Ruby (1.8.7+) for platform specific code, like the Ruby bindings. If this isn't found (Ruby 1.8.6) then sitearchdir should be used. (was: The sitearchdir is the proper location on earlier versions of Ruby for platform-specific code like the Ruby bindings.) > Ruby bindings install to vendorarchdir rather than vendorlibdir > --- > > Key: PROTON-482 > URL: https://issues.apache.org/jira/browse/PROTON-482 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > > The vendorarchdir is the proper location on Ruby (1.8.7+) for platform > specific code, like the Ruby bindings. If this isn't found (Ruby 1.8.6) then > sitearchdir should be used. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (PROTON-482) Ruby bindings install to vendorarchdir rather than vendorlibdir
[ https://issues.apache.org/jira/browse/PROTON-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated PROTON-482: Summary: Ruby bindings install to vendorarchdir rather than vendorlibdir (was: Ruby bindings install to sitearchdir rather than sitelibdir) > Ruby bindings install to vendorarchdir rather than vendorlibdir > --- > > Key: PROTON-482 > URL: https://issues.apache.org/jira/browse/PROTON-482 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > > The sitearchdir is the proper location on earlier versions of Ruby for > platform-specific code like the Ruby bindings. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (PROTON-482) Ruby bindings install to sitearchdir rather than sitelibdir
Darryl L. Pierce created PROTON-482: --- Summary: Ruby bindings install to sitearchdir rather than sitelibdir Key: PROTON-482 URL: https://issues.apache.org/jira/browse/PROTON-482 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce The sitearchdir is the proper location on earlier versions of Ruby for platform-specific code like the Ruby bindings. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
Re: improving cross language maintainability
On Thu, Dec 19, 2013 at 08:49:59AM -0500, Rafael Schloming wrote: > I would love to hear thoughts and/or alternative ideas on how to improve > things. I would like to start addressing this early in the 0.7 development > cycle. In a similar way, I'm trying to keep our Ruby and Perl bindings in parity as best I can with what's going on in the C and Python code. Can we use JIRA to create umbrella tasks for when new features are added, with subtasks that are binding specific? Or if there's a change to the C code that would require a change in the bindings, have the C code be the top JIRA and the language bindings be subtasks to that? That way I wouldn't need to look through commits to see what's changed in C to know what should be added to the other languages. Also, could we add a component for each of the language bindings? It doesn't feel right to add a JIRA for something in Ruby that's at the Ruby level but have its component be "proton-c". -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp5KU9SF4aFs.pgp Description: PGP signature
improving cross language maintainability
Hi Everyone, I've been struggling with some of the cross language maintenance aspects of proton for a while, and I believe we need to take some steps to improve the situation. I'm one of a tiny number of people (two possibly) who regularly commit changes to both the Java and C codebase and attempt to keep the two in sync and at feature parity. Because of this, not everyone is necessarily aware of the process, but to summarize the issue, currently there are far too many moving parts and layers of indirection involved. This is not only a significant drag on my personal productivity, but perhaps more importantly it is a significant barrier to growing the number of proton contributors in general as all those moving parts and layers of indirection need to be understood before being able to make complete contributions. To get an idea of what's going on here I think it helps to look at what's involved in a simple change. Recently I noticed an edge case around status updates in the messenger interface. The fix involved adding another value to messenger's status enum and making a trivial logic change to make use of that value under the appropriate circumstances. You can look at the full commit here[1] if you like, but it breaks down in the following way: Changes to C implementation (.h and .c file): 8 LOC Changes to the python test shim for C: 3 LOC Changes to the Java API: 2 LOC Changes to the pure Java implementation: 6 LOC Changes to the JNI binding: 4 LOC Changes to the python test shim for Java: 3 LOC Changes to the python test suite: 2 LOC Now obviously from a personal productivity perspective it is at a minimum annoying to have to touch so many different parts in order to make even a trivial change, but setting that aside for the moment, what is really sobering about this is that each one of the above parts involve a non trivial learning curve on their own, and while it's true that only a few lines of code are needed in each area, it is necessary to understand each piece before being able to write the correct few lines of code. This presents a pretty daunting hurdle for bringing new contributors to the codebase up to the level needed to make even a trivial change like the one above. The JNI binding and the python test shim for Java both exist to serve similar purposes, namely to facilitate running a common test suite against both implementations in order to ensure common behaviour. The python test shims allow the python test suite to run against both proton-c and proton-j (via jython), and the JNI binding allows pure Java tests to be run against proton-c as well as proton-j. Currently by my count there are about 19 such tests in Java. By comparison there are about 266 tests in the python test suite. Also, judging by commits, the python test suite is growing/actively maintained, and the java system tests (the subset of java tests that are run against both implementations) are neither. On top of this the JNI binding itself has suffered significantly from bit rot. As far as I know it is not made use of outside of our own test infrastructure, and currently about 50% of the tests run against it are skipped because it is only minimally maintained when necessary to get the tests to pass. Because of all this I'm proposing that we remove the JNI binding and roll back the Java API/impl split that was (hastily) done to facilitate the test infrastructure. This should significantly simplify the development process relative to what it is now, and while there is still more learning curve than desired with the python shims, I believe this will put us in a position to improve the shims, remove duplication, and minimize the overhead associated with them, ultimately allowing us to make the codebase more transparently communicate its design and hopefully lessen the learning curve for new contributions. I would love to hear thoughts and/or alternative ideas on how to improve things. I would like to start addressing this early in the 0.7 development cycle. [1] http://svn.apache.org/r1551950
Re: Proton 0.6 RC2
Yes, it's fixed on trunk. Thanks!
-Ted
On 12/19/2013 05:52 AM, Rafael Schloming wrote:
I believe I've fixed this on trunk. Let me know if you still see the
problem there.
--Rafael
On Wed, Dec 18, 2013 at 5:44 PM, Ted Ross wrote:
Digging further into this, I see that Messenger is providing the
subscription and the address before the dynamic-attach handshake is
completed. It was my understanding that one or both of those calls would
block until the name was resolved.
-Ted
On 12/18/2013 05:25 PM, Ted Ross wrote:
QPID-439 seems to have reverted in this RC.
Here's my client code:
self.M.route("amqp:/*", "amqp://%s/$1" % host)
self.subscription = self.M.subscribe("amqp:/#")
self.reply = self.subscription.address
print "REPLY:", self.reply
The output is:
REPLY: None
yet the trace looks like this:
[0x26135e0]:0 -> @attach(18) [name="receiver-xxx", handle=0,
role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=true],
target=@target(41) [durable=0, timeout=0, dynamic=false],
initial-delivery-count=0]
[0x26135e0]:0 <- @attach(18) [name="receiver-xxx", handle=0,
role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [address="amqp:/_topo/0/
Router.A/temp.4TQT_a",
durable=0, timeout=0, dynamic=true], initial-delivery-count=0]
On 12/18/2013 04:53 PM, Rafael Schloming wrote:
Hi Everyone,
I've just posted proton 0.6 RC2. The changes since RC1 are listed in the
attached file. Please check it out and let me know if you run into any
issues.
Sources are available here:
http://people.apache.org/~rhs/qpid-proton-0.6rc2/ <
http://people.apache.org/%7Erhs/qpid-proton-0.6rc2/>
Java binaries are available here:
https://repository.apache.org/content/repositories/orgapacheqpid-070/
--Rafael
-
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: Proton 0.6 RC2
Sounds great, thanks Rafael - that one had been annoying us :). Cheers, Frank - Original Message - From: Rafael Schloming [mailto:r...@alum.mit.edu] Sent: Thursday, December 19, 2013 10:58 AM To: proton@qpid.apache.org Cc: us...@qpid.apache.org Subject: Re: Proton 0.6 RC2 On Wed, Dec 18, 2013 at 6:43 PM, Frank Quinn wrote: > Hi Rafael, > > Could we get PROTON-420 in there too? I attached a patch to the ticket > which fixes, it's just for compiler warning prevention when compiling > against proton with strict flags. > I have applied a modified version of the PROTON-420 patch. I really don't like adding a space to examples. I feel like it is pretty inevitable that people will cut and paste example snippets and if there is an extra space in there then it will lead to lots of problems. I do recall that there is an alternative syntax for detailed comment descriptions in doxygen that makes use of // style comments rather than /* style comments. I've switched over to this form and removed the -Wno-comment from the build. This appears to work for me, so hopefully it will fix your warnings also. SVN appears to be down now, but I will check it in as soon as it is back up. --Rafael This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange Group, Inc. (ICE), NYSE Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
Re: Proton 0.6 RC2
On Wed, Dec 18, 2013 at 6:43 PM, Frank Quinn wrote: > Hi Rafael, > > Could we get PROTON-420 in there too? I attached a patch to the ticket > which fixes, it's just for compiler warning prevention when compiling > against proton with strict flags. > I have applied a modified version of the PROTON-420 patch. I really don't like adding a space to examples. I feel like it is pretty inevitable that people will cut and paste example snippets and if there is an extra space in there then it will lead to lots of problems. I do recall that there is an alternative syntax for detailed comment descriptions in doxygen that makes use of // style comments rather than /* style comments. I've switched over to this form and removed the -Wno-comment from the build. This appears to work for me, so hopefully it will fix your warnings also. SVN appears to be down now, but I will check it in as soon as it is back up. --Rafael
Re: Proton 0.6 RC2
I believe I've fixed this on trunk. Let me know if you still see the
problem there.
--Rafael
On Wed, Dec 18, 2013 at 5:44 PM, Ted Ross wrote:
> Digging further into this, I see that Messenger is providing the
> subscription and the address before the dynamic-attach handshake is
> completed. It was my understanding that one or both of those calls would
> block until the name was resolved.
>
> -Ted
>
>
> On 12/18/2013 05:25 PM, Ted Ross wrote:
>
>> QPID-439 seems to have reverted in this RC.
>>
>> Here's my client code:
>>
>> self.M.route("amqp:/*", "amqp://%s/$1" % host)
>> self.subscription = self.M.subscribe("amqp:/#")
>> self.reply = self.subscription.address
>> print "REPLY:", self.reply
>>
>> The output is:
>>
>> REPLY: None
>>
>> yet the trace looks like this:
>>
>> [0x26135e0]:0 -> @attach(18) [name="receiver-xxx", handle=0,
>> role=true, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [durable=0, timeout=0, dynamic=true],
>> target=@target(41) [durable=0, timeout=0, dynamic=false],
>> initial-delivery-count=0]
>> [0x26135e0]:0 <- @attach(18) [name="receiver-xxx", handle=0,
>> role=false, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [address="amqp:/_topo/0/
>> Router.A/temp.4TQT_a",
>> durable=0, timeout=0, dynamic=true], initial-delivery-count=0]
>>
>>
>>
>> On 12/18/2013 04:53 PM, Rafael Schloming wrote:
>>
>>> Hi Everyone,
>>>
>>> I've just posted proton 0.6 RC2. The changes since RC1 are listed in the
>>> attached file. Please check it out and let me know if you run into any
>>> issues.
>>>
>>> Sources are available here:
>>>
>>> http://people.apache.org/~rhs/qpid-proton-0.6rc2/ <
>>> http://people.apache.org/%7Erhs/qpid-proton-0.6rc2/>
>>>
>>> Java binaries are available here:
>>>
>>> https://repository.apache.org/content/repositories/orgapacheqpid-070/
>>>
>>> --Rafael
>>>
>>>
>>>
>>>
>>> -
>>> 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
>
>
