[jira] [Commented] (PROTON-136) Add support for SSL session resumption
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531121#comment-13531121 ] Ken Giusti commented on PROTON-136: --- Rafi has mentioned a minor change to the proposed API: 1) don't deprecate pn_ssl_t *pn_ssl( pn_transport_t *), and 2) modify the constructor: pn_ssl_t *pn_ssl_new( pn_ssl_domain_t *domain, pn_transport_t *transport, const char *session_id); to: int pn_ssl_init( pn_ssl_t *ssl, pn_ssl_domain_t *domain, const char *session_id); So, to create an SSL connection, two steps are done: ssl = pn_ssl( transport );// access transport's ssl, or construct if none. rc = pn_ssl_init( ssl, domain, id ) // initialize, The modified API would prevent the ambiguity possible with the first approach - say calling the pn_ssl_new method for a transport that already has an SSL with a different domain than was used when the ssl object was originally constructed. Rafi - is this correct? Add support for SSL session resumption -- Key: PROTON-136 URL: https://issues.apache.org/jira/browse/PROTON-136 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.3 Reporter: Affan Dar Assignee: Ken Giusti Labels: ssl, sslContext, sslresume Attachments: PROTON-136-initial-Java-and-Python.tgz, ssl-patches-20121212.tar.gz Open SSL supports resumption of SSL sessions which by-pass the heavy SSL handshake process. This is critical for scenarios involving low powered devices especially on cellular data networks where bandwidth is precious. It would be great if Proton exposes this ssl resume feature to users. . From: rhs [mailto:rschlom...@gmail.com] Sent: Tuesday, November 13, 2012 11:34 AM To: Affan Dar Cc: David Ingham Subject: Re: SSL session resumption On Tue, Nov 13, 2012 at 8:05 PM, Affan Dar affan...@microsoft.com wrote: Serializing/restoring the whole session state for the messenger will work for the scenario I think. Ok, let's start with this step then. I'm open to providing something finer grained if there is a need, but my preference is to keep it simple for the moment. One more thing, RFC 5077 has another flavor of session resumption which openssl supports (original implemented as RFC 4057 back in 2007 I think). This allows us to resume sessions without carrying state on the server side which as you can imagine is a big deal for service vendors. Probably there is no API level impact if messenger handles the session state itself but just wanted to put this on your radar. Ok, good to know. Could one of you file a JIRA for this upstream? I'm trying to get things a little more organized on the process front and keep everything centralized in JIRA. ;-) --Rafael -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-136) Add support for SSL session resumption
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531124#comment-13531124 ] Rafael H. Schloming commented on PROTON-136: Yes I think those changes would be a significant improvement for the reasons you mention. Add support for SSL session resumption -- Key: PROTON-136 URL: https://issues.apache.org/jira/browse/PROTON-136 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.3 Reporter: Affan Dar Assignee: Ken Giusti Labels: ssl, sslContext, sslresume Attachments: PROTON-136-initial-Java-and-Python.tgz, ssl-patches-20121212.tar.gz Open SSL supports resumption of SSL sessions which by-pass the heavy SSL handshake process. This is critical for scenarios involving low powered devices especially on cellular data networks where bandwidth is precious. It would be great if Proton exposes this ssl resume feature to users. . From: rhs [mailto:rschlom...@gmail.com] Sent: Tuesday, November 13, 2012 11:34 AM To: Affan Dar Cc: David Ingham Subject: Re: SSL session resumption On Tue, Nov 13, 2012 at 8:05 PM, Affan Dar affan...@microsoft.com wrote: Serializing/restoring the whole session state for the messenger will work for the scenario I think. Ok, let's start with this step then. I'm open to providing something finer grained if there is a need, but my preference is to keep it simple for the moment. One more thing, RFC 5077 has another flavor of session resumption which openssl supports (original implemented as RFC 4057 back in 2007 I think). This allows us to resume sessions without carrying state on the server side which as you can imagine is a big deal for service vendors. Probably there is no API level impact if messenger handles the session state itself but just wanted to put this on your radar. Ok, good to know. Could one of you file a JIRA for this upstream? I'm trying to get things a little more organized on the process front and keep everything centralized in JIRA. ;-) --Rafael -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-186) Message encode should always return the number of bytes needed to fully encode the message
[ https://issues.apache.org/jira/browse/PROTON-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-186: - Issue Type: Improvement (was: Bug) Message encode should always return the number of bytes needed to fully encode the message -- Key: PROTON-186 URL: https://issues.apache.org/jira/browse/PROTON-186 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Hiram Chirino -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-186) Message encode should always return the number of bytes needed to fully encode the message
[ https://issues.apache.org/jira/browse/PROTON-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-186: - Attachment: PROTON-186.patch Attaching patch which implements this for proton-j Message encode should always return the number of bytes needed to fully encode the message -- Key: PROTON-186 URL: https://issues.apache.org/jira/browse/PROTON-186 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Hiram Chirino Attachments: PROTON-186.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-186) Message encode should always return the number of bytes needed to fully encode the message
[ https://issues.apache.org/jira/browse/PROTON-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-186: - Attachment: (was: PROTON-186v2.patch) Message encode should always return the number of bytes needed to fully encode the message -- Key: PROTON-186 URL: https://issues.apache.org/jira/browse/PROTON-186 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Hiram Chirino Attachments: PROTON-186.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-186) Message encode should always return the number of bytes needed to fully encode the message
[ https://issues.apache.org/jira/browse/PROTON-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-186: - Attachment: PROTON-186v2.patch Attaching updated patch that does not change the current encode behavour but adds a encode2 method that behaves has described in this issue. Message encode should always return the number of bytes needed to fully encode the message -- Key: PROTON-186 URL: https://issues.apache.org/jira/browse/PROTON-186 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Hiram Chirino Attachments: PROTON-186.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-186) Message encode should always return the number of bytes needed to fully encode the message
[ https://issues.apache.org/jira/browse/PROTON-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-186: - Attachment: PROTON-186v2.patch Message encode should always return the number of bytes needed to fully encode the message -- Key: PROTON-186 URL: https://issues.apache.org/jira/browse/PROTON-186 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Hiram Chirino Attachments: PROTON-186v2.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-186) Message encode should always return the number of bytes needed to fully encode the message
[ https://issues.apache.org/jira/browse/PROTON-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531400#comment-13531400 ] Rob Godfrey commented on PROTON-186: Patch applied (with modifications) to add the encode2 method to the java implementation. Message encode should always return the number of bytes needed to fully encode the message -- Key: PROTON-186 URL: https://issues.apache.org/jira/browse/PROTON-186 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Hiram Chirino Attachments: PROTON-186v2.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PROTON-127) Rename the org.apache.qpid.proton.type package for nicer Scala support
[ https://issues.apache.org/jira/browse/PROTON-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned PROTON-127: -- Assignee: Rob Godfrey Rename the org.apache.qpid.proton.type package for nicer Scala support -- Key: PROTON-127 URL: https://issues.apache.org/jira/browse/PROTON-127 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Rob Godfrey Priority: Minor 'type' is a reserved word in Scala. So when using proton from scala, you end up doing imports like: import org.apache.qpid.proton.`type`.messaging.Accepted Which is kinda ugly. Would be nice if that package was renamed so something else. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-127) Rename the org.apache.qpid.proton.type package for nicer Scala support
[ https://issues.apache.org/jira/browse/PROTON-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved PROTON-127. Resolution: Fixed Fix Version/s: 0.3 The type package has been removed. The public API classes/interfaces are now in an amqp package Rename the org.apache.qpid.proton.type package for nicer Scala support -- Key: PROTON-127 URL: https://issues.apache.org/jira/browse/PROTON-127 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Rob Godfrey Priority: Minor Fix For: 0.3 'type' is a reserved word in Scala. So when using proton from scala, you end up doing imports like: import org.apache.qpid.proton.`type`.messaging.Accepted Which is kinda ugly. Would be nice if that package was renamed so something else. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-185) Can't build proton-c - undefined symbols ERR_get_error etc
[ https://issues.apache.org/jira/browse/PROTON-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-185: -- Attachment: GITDIFF.txt Turns out, old (pre 2.8.0) versions of Cmake don't add crypto to the set of required SSL libraries. Once past that, there are additional issues with linking python wrappers, apparently cmake gets that wrong, too (or perhaps swig?). In any case, this patch gets the links resolving cleanly. Can't build proton-c - undefined symbols ERR_get_error etc -- Key: PROTON-185 URL: https://issues.apache.org/jira/browse/PROTON-185 Project: Qpid Proton Issue Type: Bug Components: proton-c Environment: Red Hat Enterprise Linux Server release 5.3 (Tikanga) Reporter: Keith Wall Assignee: Ken Giusti Attachments: GITDIFF.txt As initially discussed on mail thread.. We are having problems building proton-c on our dev boxes (Red Hat Enterprise Linux Server release 5.3 (Tikanga)). I've done a git bisect and discovered that it was Andrew's commit last Wednesday (rev 1417553) that has introduced/exposed the issue. Before that point, we could build without this issue. It appears to be a link issue with openssl. The following version of openssl is installed: $rpm -q openssl openssl-0.9.8e-7.el5.x86_64 openssl-0.9.8e-7.el5.i686 Make is failing with the following (complete cmake/make output attached below) Linking C shared library libqpid-proton.so CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `_log_ssl_error': openssl.c:(.text+0x2de): undefined reference to `ERR_get_error' openssl.c:(.text+0x2ff): undefined reference to `ERR_error_string_n' openssl.c:(.text+0x31c): undefined reference to `ERR_get_error' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `ssl_failed': openssl.c:(.text+0x43f): undefined reference to `ERR_get_error' openssl.c:(.text+0x45f): undefined reference to `ERR_error_string_n' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `get_dh2048': openssl.c:(.text+0x4ac): undefined reference to `DH_new' openssl.c:(.text+0x4d7): undefined reference to `BN_bin2bn' openssl.c:(.text+0x4f8): undefined reference to `BN_bin2bn' openssl.c:(.text+0x526): undefined reference to `DH_free' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `pn_ssl_domain': openssl.c:(.text+0x71e): undefined reference to `OPENSSL_add_all_algorithms_noconf' openssl.c:(.text+0x8fd): undefined reference to `DH_free' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `pn_ssl': openssl.c:(.text+0x1979): undefined reference to `OPENSSL_add_all_algorithms_noconf' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `process_input_ssl': openssl.c:(.text+0x1cd2): undefined reference to `BIO_write' openssl.c:(.text+0x1d62): undefined reference to `BIO_ctrl' openssl.c:(.text+0x1dcf): undefined reference to `BIO_read' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `process_output_ssl': openssl.c:(.text+0x2268): undefined reference to `BIO_write' openssl.c:(.text+0x240e): undefined reference to `BIO_read' openssl.c:(.text+0x24b7): undefined reference to `BIO_ctrl' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `init_ssl_socket': openssl.c:(.text+0x26a3): undefined reference to `BIO_new' openssl.c:(.text+0x26fa): undefined reference to `BIO_ctrl' openssl.c:(.text+0x2719): undefined reference to `BIO_new_bio_pair' openssl.c:(.text+0x278f): undefined reference to `BIO_ctrl' openssl.c:(.text+0x27cf): undefined reference to `BIO_ctrl' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `release_ssl_socket': openssl.c:(.text+0x2816): undefined reference to `BIO_free' openssl.c:(.text+0x284c): undefined reference to `BIO_free' openssl.c:(.text+0x2866): undefined reference to `BIO_free' I am not able to determine the underlying cause (my C skills are ten years rusty), would someone be able to take a look and advise? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-185) Can't build proton-c - undefined symbols ERR_get_error etc
[ https://issues.apache.org/jira/browse/PROTON-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531527#comment-13531527 ] Ken Giusti commented on PROTON-185: --- That patch isn't production quality - hardcoding the libraries is a hack, and won't work cross platform. In the end, the problem really is that the older versions of Cmake get the library configurations wrong. Technically, our CMakeLists.txt is _correct_, it's the underlying cmake logic that is bad. I wonder if we'd be better off disabling this unresolved feature check for older versions of cmake (say pre 2.8.0)? Otherwise, we're really finding bugs in cmake more than we're fixing problems in proton, IMHO. Assigning back to Andrew. Can't build proton-c - undefined symbols ERR_get_error etc -- Key: PROTON-185 URL: https://issues.apache.org/jira/browse/PROTON-185 Project: Qpid Proton Issue Type: Bug Components: proton-c Environment: Red Hat Enterprise Linux Server release 5.3 (Tikanga) Reporter: Keith Wall Assignee: Ken Giusti Attachments: GITDIFF.txt As initially discussed on mail thread.. We are having problems building proton-c on our dev boxes (Red Hat Enterprise Linux Server release 5.3 (Tikanga)). I've done a git bisect and discovered that it was Andrew's commit last Wednesday (rev 1417553) that has introduced/exposed the issue. Before that point, we could build without this issue. It appears to be a link issue with openssl. The following version of openssl is installed: $rpm -q openssl openssl-0.9.8e-7.el5.x86_64 openssl-0.9.8e-7.el5.i686 Make is failing with the following (complete cmake/make output attached below) Linking C shared library libqpid-proton.so CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `_log_ssl_error': openssl.c:(.text+0x2de): undefined reference to `ERR_get_error' openssl.c:(.text+0x2ff): undefined reference to `ERR_error_string_n' openssl.c:(.text+0x31c): undefined reference to `ERR_get_error' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `ssl_failed': openssl.c:(.text+0x43f): undefined reference to `ERR_get_error' openssl.c:(.text+0x45f): undefined reference to `ERR_error_string_n' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `get_dh2048': openssl.c:(.text+0x4ac): undefined reference to `DH_new' openssl.c:(.text+0x4d7): undefined reference to `BN_bin2bn' openssl.c:(.text+0x4f8): undefined reference to `BN_bin2bn' openssl.c:(.text+0x526): undefined reference to `DH_free' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `pn_ssl_domain': openssl.c:(.text+0x71e): undefined reference to `OPENSSL_add_all_algorithms_noconf' openssl.c:(.text+0x8fd): undefined reference to `DH_free' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `pn_ssl': openssl.c:(.text+0x1979): undefined reference to `OPENSSL_add_all_algorithms_noconf' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `process_input_ssl': openssl.c:(.text+0x1cd2): undefined reference to `BIO_write' openssl.c:(.text+0x1d62): undefined reference to `BIO_ctrl' openssl.c:(.text+0x1dcf): undefined reference to `BIO_read' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `process_output_ssl': openssl.c:(.text+0x2268): undefined reference to `BIO_write' openssl.c:(.text+0x240e): undefined reference to `BIO_read' openssl.c:(.text+0x24b7): undefined reference to `BIO_ctrl' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `init_ssl_socket': openssl.c:(.text+0x26a3): undefined reference to `BIO_new' openssl.c:(.text+0x26fa): undefined reference to `BIO_ctrl' openssl.c:(.text+0x2719): undefined reference to `BIO_new_bio_pair' openssl.c:(.text+0x278f): undefined reference to `BIO_ctrl' openssl.c:(.text+0x27cf): undefined reference to `BIO_ctrl' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `release_ssl_socket': openssl.c:(.text+0x2816): undefined reference to `BIO_free' openssl.c:(.text+0x284c): undefined reference to `BIO_free' openssl.c:(.text+0x2866): undefined reference to `BIO_free' I am not able to determine the underlying cause (my C skills are ten years rusty), would someone be able to take a look and advise? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-10) Need a means of specifying error details when detaching a link
[ https://issues.apache.org/jira/browse/PROTON-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-10. --- Resolution: Fixed Fix Version/s: 0.3 Need a means of specifying error details when detaching a link -- Key: PROTON-10 URL: https://issues.apache.org/jira/browse/PROTON-10 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Environment: All Reporter: Gordon Sim Assignee: Rafael H. Schloming Labels: api Fix For: 0.3 e.g. to indicate a node not being found, or some other error in processing an attach -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-43) Provides messenger send/receive examples in C
[ https://issues.apache.org/jira/browse/PROTON-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-43. --- Resolution: Fixed Fix Version/s: 0.2 Provides messenger send/receive examples in C - Key: PROTON-43 URL: https://issues.apache.org/jira/browse/PROTON-43 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Darryl L. Pierce Assignee: Rafael H. Schloming Priority: Blocker Fix For: 0.2 Attachments: 0001-New-C-language-examples-for-send-and-receive.patch Provides a send.c, recv.c and CMake file to build them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (PROTON-26) Engine api naming proposal
[ https://issues.apache.org/jira/browse/PROTON-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming closed PROTON-26. - Resolution: Fixed Fix Version/s: 0.2 Assignee: Rafael H. Schloming I believe all the work for this has been done. I'm marking it closed, please reopen if there is more work. Engine api naming proposal -- Key: PROTON-26 URL: https://issues.apache.org/jira/browse/PROTON-26 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Justin Ross Assignee: Rafael H. Schloming Labels: api Fix For: 0.2 Attachments: engine-naming-01.patch, proton-engine-naming-proposal-2.pdf, proton-engine-naming-proposal-3.pdf See https://docs.google.com/spreadsheet/ccc?key=0ArGmVtK1EBOMdEw0bkp4OE5UOWpRRkx3RzVoTjliX0E#gid=0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-163) On connection open username@ is appended to the hostname
[ https://issues.apache.org/jira/browse/PROTON-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-163. Resolution: Fixed Fix Version/s: 0.3 Assignee: Rafael H. Schloming On connection open username@ is appended to the hostname -- Key: PROTON-163 URL: https://issues.apache.org/jira/browse/PROTON-163 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.1, 0.2 Reporter: Arun Dsouza Assignee: Rafael H. Schloming Priority: Minor Fix For: 0.3 When Proton-C creates an AMQP open frame it appends 'username@' to the hostname. This is because the pn_messenger_resolve function in messenger.c sets the HostName to the domain and not the hostname as parsed from the incoming address. pn_connection_set_hostname(connection, host); should be used instead of pn_connection_set_hostname(connection, domain); Is this intended? This might cause issues with some broker implementations that might not expect the usename to the appended to the host name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-185) Can't build proton-c - undefined symbols ERR_get_error etc
[
https://issues.apache.org/jira/browse/PROTON-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531570#comment-13531570
]
Andrew Stitcher commented on PROTON-185:
Ah - it's not VERSION_LESS thats not defined its CMAKE_VERSION - I guess we
need instead
${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}
Can't build proton-c - undefined symbols ERR_get_error etc
--
Key: PROTON-185
URL: https://issues.apache.org/jira/browse/PROTON-185
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Environment: Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Reporter: Keith Wall
Assignee: Andrew Stitcher
Attachments: GITDIFF.txt
As initially discussed on mail thread..
We are having problems building proton-c on our dev boxes (Red Hat
Enterprise Linux Server release 5.3 (Tikanga)). I've done a git
bisect and discovered that it was Andrew's commit last Wednesday (rev
1417553) that has introduced/exposed the issue. Before that point, we
could build without this issue.
It appears to be a link issue with openssl. The following version of
openssl is installed:
$rpm -q openssl
openssl-0.9.8e-7.el5.x86_64
openssl-0.9.8e-7.el5.i686
Make is failing with the following (complete cmake/make output attached below)
Linking C shared library libqpid-proton.so
CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `_log_ssl_error':
openssl.c:(.text+0x2de): undefined reference to `ERR_get_error'
openssl.c:(.text+0x2ff): undefined reference to `ERR_error_string_n'
openssl.c:(.text+0x31c): undefined reference to `ERR_get_error'
CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `ssl_failed':
openssl.c:(.text+0x43f): undefined reference to `ERR_get_error'
openssl.c:(.text+0x45f): undefined reference to `ERR_error_string_n'
CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `get_dh2048':
openssl.c:(.text+0x4ac): undefined reference to `DH_new'
openssl.c:(.text+0x4d7): undefined reference to `BN_bin2bn'
openssl.c:(.text+0x4f8): undefined reference to `BN_bin2bn'
openssl.c:(.text+0x526): undefined reference to `DH_free'
CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `pn_ssl_domain':
openssl.c:(.text+0x71e): undefined reference to
`OPENSSL_add_all_algorithms_noconf'
openssl.c:(.text+0x8fd): undefined reference to `DH_free'
CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `pn_ssl':
openssl.c:(.text+0x1979): undefined reference to
`OPENSSL_add_all_algorithms_noconf'
CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function
`process_input_ssl':
openssl.c:(.text+0x1cd2): undefined reference to `BIO_write'
openssl.c:(.text+0x1d62): undefined reference to `BIO_ctrl'
openssl.c:(.text+0x1dcf): undefined reference to `BIO_read'
CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function
`process_output_ssl':
openssl.c:(.text+0x2268): undefined reference to `BIO_write'
openssl.c:(.text+0x240e): undefined reference to `BIO_read'
openssl.c:(.text+0x24b7): undefined reference to `BIO_ctrl'
CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `init_ssl_socket':
openssl.c:(.text+0x26a3): undefined reference to `BIO_new'
openssl.c:(.text+0x26fa): undefined reference to `BIO_ctrl'
openssl.c:(.text+0x2719): undefined reference to `BIO_new_bio_pair'
openssl.c:(.text+0x278f): undefined reference to `BIO_ctrl'
openssl.c:(.text+0x27cf): undefined reference to `BIO_ctrl'
CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function
`release_ssl_socket':
openssl.c:(.text+0x2816): undefined reference to `BIO_free'
openssl.c:(.text+0x284c): undefined reference to `BIO_free'
openssl.c:(.text+0x2866): undefined reference to `BIO_free'
I am not able to determine the underlying cause (my C skills are ten
years rusty), would someone be able to take a look and advise?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-26) Engine api naming proposal
[ https://issues.apache.org/jira/browse/PROTON-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531571#comment-13531571 ] Justin Ross commented on PROTON-26: --- That's really not the case. Rejecting it is fine, but it's mostly gone undiscussed. That's partly my fault. A post to the mailing list with highlights suitable for inline comments is incoming. Engine api naming proposal -- Key: PROTON-26 URL: https://issues.apache.org/jira/browse/PROTON-26 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Justin Ross Assignee: Rafael H. Schloming Labels: api Fix For: 0.2 Attachments: engine-naming-01.patch, proton-engine-naming-proposal-2.pdf, proton-engine-naming-proposal-3.pdf See https://docs.google.com/spreadsheet/ccc?key=0ArGmVtK1EBOMdEw0bkp4OE5UOWpRRkx3RzVoTjliX0E#gid=0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Engine API naming
API usability is important and deserves attention. Take, for instance, DeliveryState versus Disposition. That only serves to confuse people. It's a difference that has no content. I also think link.drained and link.offered are very unclear. I've found the whole process of proposing API review dispiriting. You can, of course, take it or leave it. I in no way wish to claim I have better choices. I only wish to point out things that might deserve more deliberation. Justin --- Endpoint state PN_LOCAL_UNINIT Existing C name:PN_LOCAL_UNINIT Proposed C name:PN_LOCAL_UNINITIALIZED Existing Java name: EndpointState.UNINITIALIZED Proposed Java name: One api has the remote-local distinction in one bitset, and one does not. Is this difference desirable? PN_REMOTE_UNINIT Existing C name:PN_REMOTE_UNINIT Proposed C name:PN_REMOTE_UNINITIALIZED Existing Java name: EndpointState.UNINITIALIZED Proposed Java name: Personally, I'm at ease with UNINIT as an abbreviation here Types pn_disposition_t Existing C name:pn_disposition_t Proposed C name: Existing Java name: DeliveryState Proposed Java name: Disposition DeliveryState vs. Disposition. A good example of a confusing difference. I have a slight preference for DeliveryState (it's self- explanatory), but matching is the main thing. pn_delivery_tag_t Existing C name:pn_delivery_tag_t Proposed C name: Existing Java name: [anonymous byte array] Proposed Java name: DeliveryTag? Session pn_session_connection Existing C name:pn_session_connection Proposed C name:pn_session_get_connection According to Rafi's system, this should have _get_. Link pn_link_session Existing C name:pn_link_session Proposed C name:pn_link_get_session Sender pn_link_drained Existing C name:pn_link_drained Proposed C name:pn_link_drain_credit [?] Existing Java name: Sender.drained Proposed Java name: Sender.drainCredit [?] I can't tell what's going on here. I particularly dislike pn_link_drained and _offered. They look like predicates but have no return value. Receiver pn_link_flow Existing C name:pn_link_flow Proposed C name:pn_link_issue_credit Existing Java name: Receiver.flow Proposed Java name: Receiver.issueCredit Consider pn_link_increase_credit, pn_link_issue_credit; working in the word credit somehow would help a lot pn_link_drain Existing C name:pn_link_drain Proposed C name:pn_link_rescind_credit Existing Java name: Receiver.drain Proposed Java name: Receiver.rescindCredit Consider pn_link_decrease_credit, pn_link_rescind_credit Delivery pn_delivery_link Existing C name:pn_delivery_link Proposed C name:pn_delivery_get_link pn_delivery_local_state Existing C name:pn_delivery_local_state Proposed C name:pn_delivery_state Existing Java name: Delivery.getLocalState Proposed Java name: Delivery.state Local is not used elsewhere for local/remote distinctions pn_delivery_update Existing C name:pn_delivery_update Proposed C name:pn_delivery_acknowledge Existing Java name: Delivery.disposition Proposed Java name: Delivery.acknowledge Do calls to delivery.update correspond one-to-one to delivery.updated? The naming implies a symmetry that I'm not sure is there. On Thu, 13 Dec 2012, Justin Ross (JIRA) wrote: [ https://issues.apache.org/jira/browse/PROTON-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531571#comment-13531571 ] Justin Ross commented on PROTON-26: --- That's really not the case. Rejecting it is fine, but it's mostly gone undiscussed. That's partly my fault. A post to the mailing list with highlights suitable for inline comments is incoming. Engine api naming proposal -- Key: PROTON-26 URL: https://issues.apache.org/jira/browse/PROTON-26 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Justin Ross Assignee: Rafael H. Schloming Labels: api Fix For: 0.2 Attachments: engine-naming-01.patch, proton-engine-naming-proposal-2.pdf, proton-engine-naming-proposal-3.pdf See https://docs.google.com/spreadsheet/ccc?key=0ArGmVtK1EBOMdEw0bkp4OE5UOWpRRkx3RzVoTjliX0E#gid=0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-185) Can't build proton-c - undefined symbols ERR_get_error etc
[ https://issues.apache.org/jira/browse/PROTON-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531592#comment-13531592 ] Andrew Stitcher commented on PROTON-185: I've fixed this in accordance with Ken's last suggestion - turning off the undefined symbol checking for versions of cmake prior to 2.8. Fixed in r1421586 Can't build proton-c - undefined symbols ERR_get_error etc -- Key: PROTON-185 URL: https://issues.apache.org/jira/browse/PROTON-185 Project: Qpid Proton Issue Type: Bug Components: proton-c Environment: Red Hat Enterprise Linux Server release 5.3 (Tikanga) Reporter: Keith Wall Assignee: Andrew Stitcher Attachments: GITDIFF.txt As initially discussed on mail thread.. We are having problems building proton-c on our dev boxes (Red Hat Enterprise Linux Server release 5.3 (Tikanga)). I've done a git bisect and discovered that it was Andrew's commit last Wednesday (rev 1417553) that has introduced/exposed the issue. Before that point, we could build without this issue. It appears to be a link issue with openssl. The following version of openssl is installed: $rpm -q openssl openssl-0.9.8e-7.el5.x86_64 openssl-0.9.8e-7.el5.i686 Make is failing with the following (complete cmake/make output attached below) Linking C shared library libqpid-proton.so CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `_log_ssl_error': openssl.c:(.text+0x2de): undefined reference to `ERR_get_error' openssl.c:(.text+0x2ff): undefined reference to `ERR_error_string_n' openssl.c:(.text+0x31c): undefined reference to `ERR_get_error' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `ssl_failed': openssl.c:(.text+0x43f): undefined reference to `ERR_get_error' openssl.c:(.text+0x45f): undefined reference to `ERR_error_string_n' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `get_dh2048': openssl.c:(.text+0x4ac): undefined reference to `DH_new' openssl.c:(.text+0x4d7): undefined reference to `BN_bin2bn' openssl.c:(.text+0x4f8): undefined reference to `BN_bin2bn' openssl.c:(.text+0x526): undefined reference to `DH_free' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `pn_ssl_domain': openssl.c:(.text+0x71e): undefined reference to `OPENSSL_add_all_algorithms_noconf' openssl.c:(.text+0x8fd): undefined reference to `DH_free' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `pn_ssl': openssl.c:(.text+0x1979): undefined reference to `OPENSSL_add_all_algorithms_noconf' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `process_input_ssl': openssl.c:(.text+0x1cd2): undefined reference to `BIO_write' openssl.c:(.text+0x1d62): undefined reference to `BIO_ctrl' openssl.c:(.text+0x1dcf): undefined reference to `BIO_read' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `process_output_ssl': openssl.c:(.text+0x2268): undefined reference to `BIO_write' openssl.c:(.text+0x240e): undefined reference to `BIO_read' openssl.c:(.text+0x24b7): undefined reference to `BIO_ctrl' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `init_ssl_socket': openssl.c:(.text+0x26a3): undefined reference to `BIO_new' openssl.c:(.text+0x26fa): undefined reference to `BIO_ctrl' openssl.c:(.text+0x2719): undefined reference to `BIO_new_bio_pair' openssl.c:(.text+0x278f): undefined reference to `BIO_ctrl' openssl.c:(.text+0x27cf): undefined reference to `BIO_ctrl' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `release_ssl_socket': openssl.c:(.text+0x2816): undefined reference to `BIO_free' openssl.c:(.text+0x284c): undefined reference to `BIO_free' openssl.c:(.text+0x2866): undefined reference to `BIO_free' I am not able to determine the underlying cause (my C skills are ten years rusty), would someone be able to take a look and advise? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-185) Can't build proton-c - undefined symbols ERR_get_error etc
[ https://issues.apache.org/jira/browse/PROTON-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-185. Resolution: Fixed Fix Version/s: 0.3 Can't build proton-c - undefined symbols ERR_get_error etc -- Key: PROTON-185 URL: https://issues.apache.org/jira/browse/PROTON-185 Project: Qpid Proton Issue Type: Bug Components: proton-c Environment: Red Hat Enterprise Linux Server release 5.3 (Tikanga) Reporter: Keith Wall Assignee: Andrew Stitcher Fix For: 0.3 Attachments: GITDIFF.txt As initially discussed on mail thread.. We are having problems building proton-c on our dev boxes (Red Hat Enterprise Linux Server release 5.3 (Tikanga)). I've done a git bisect and discovered that it was Andrew's commit last Wednesday (rev 1417553) that has introduced/exposed the issue. Before that point, we could build without this issue. It appears to be a link issue with openssl. The following version of openssl is installed: $rpm -q openssl openssl-0.9.8e-7.el5.x86_64 openssl-0.9.8e-7.el5.i686 Make is failing with the following (complete cmake/make output attached below) Linking C shared library libqpid-proton.so CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `_log_ssl_error': openssl.c:(.text+0x2de): undefined reference to `ERR_get_error' openssl.c:(.text+0x2ff): undefined reference to `ERR_error_string_n' openssl.c:(.text+0x31c): undefined reference to `ERR_get_error' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `ssl_failed': openssl.c:(.text+0x43f): undefined reference to `ERR_get_error' openssl.c:(.text+0x45f): undefined reference to `ERR_error_string_n' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `get_dh2048': openssl.c:(.text+0x4ac): undefined reference to `DH_new' openssl.c:(.text+0x4d7): undefined reference to `BN_bin2bn' openssl.c:(.text+0x4f8): undefined reference to `BN_bin2bn' openssl.c:(.text+0x526): undefined reference to `DH_free' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `pn_ssl_domain': openssl.c:(.text+0x71e): undefined reference to `OPENSSL_add_all_algorithms_noconf' openssl.c:(.text+0x8fd): undefined reference to `DH_free' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `pn_ssl': openssl.c:(.text+0x1979): undefined reference to `OPENSSL_add_all_algorithms_noconf' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `process_input_ssl': openssl.c:(.text+0x1cd2): undefined reference to `BIO_write' openssl.c:(.text+0x1d62): undefined reference to `BIO_ctrl' openssl.c:(.text+0x1dcf): undefined reference to `BIO_read' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `process_output_ssl': openssl.c:(.text+0x2268): undefined reference to `BIO_write' openssl.c:(.text+0x240e): undefined reference to `BIO_read' openssl.c:(.text+0x24b7): undefined reference to `BIO_ctrl' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `init_ssl_socket': openssl.c:(.text+0x26a3): undefined reference to `BIO_new' openssl.c:(.text+0x26fa): undefined reference to `BIO_ctrl' openssl.c:(.text+0x2719): undefined reference to `BIO_new_bio_pair' openssl.c:(.text+0x278f): undefined reference to `BIO_ctrl' openssl.c:(.text+0x27cf): undefined reference to `BIO_ctrl' CMakeFiles/qpid-proton.dir/src/ssl/openssl.c.o: In function `release_ssl_socket': openssl.c:(.text+0x2816): undefined reference to `BIO_free' openssl.c:(.text+0x284c): undefined reference to `BIO_free' openssl.c:(.text+0x2866): undefined reference to `BIO_free' I am not able to determine the underlying cause (my C skills are ten years rusty), would someone be able to take a look and advise? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Engine API naming
Nice suggestions actually. I think some of the discrepancy has to do with the difference between languages and the idioms that have long been fossilized int the different naming conventions. Again, all suggestions on proposed look good to me. Regards, -W On Dec 13, 2012, at 5:37 PM, Justin jr...@redhat.com wrote: API usability is important and deserves attention. Take, for instance, DeliveryState versus Disposition. That only serves to confuse people. It's a difference that has no content. I also think link.drained and link.offered are very unclear. I've found the whole process of proposing API review dispiriting. You can, of course, take it or leave it. I in no way wish to claim I have better choices. I only wish to point out things that might deserve more deliberation. Justin --- Endpoint state PN_LOCAL_UNINIT Existing C name:PN_LOCAL_UNINIT Proposed C name:PN_LOCAL_UNINITIALIZED Existing Java name: EndpointState.UNINITIALIZED Proposed Java name: One api has the remote-local distinction in one bitset, and one does not. Is this difference desirable? PN_REMOTE_UNINIT Existing C name:PN_REMOTE_UNINIT Proposed C name:PN_REMOTE_UNINITIALIZED Existing Java name: EndpointState.UNINITIALIZED Proposed Java name: Personally, I'm at ease with UNINIT as an abbreviation here Types pn_disposition_t Existing C name:pn_disposition_t Proposed C name: Existing Java name: DeliveryState Proposed Java name: Disposition DeliveryState vs. Disposition. A good example of a confusing difference. I have a slight preference for DeliveryState (it's self- explanatory), but matching is the main thing. pn_delivery_tag_t Existing C name:pn_delivery_tag_t Proposed C name: Existing Java name: [anonymous byte array] Proposed Java name: DeliveryTag? Session pn_session_connection Existing C name:pn_session_connection Proposed C name:pn_session_get_connection According to Rafi's system, this should have _get_. Link pn_link_session Existing C name:pn_link_session Proposed C name:pn_link_get_session Sender pn_link_drained Existing C name:pn_link_drained Proposed C name:pn_link_drain_credit [?] Existing Java name: Sender.drained Proposed Java name: Sender.drainCredit [?] I can't tell what's going on here. I particularly dislike pn_link_drained and _offered. They look like predicates but have no return value. Receiver pn_link_flow Existing C name:pn_link_flow Proposed C name:pn_link_issue_credit Existing Java name: Receiver.flow Proposed Java name: Receiver.issueCredit Consider pn_link_increase_credit, pn_link_issue_credit; working in the word credit somehow would help a lot pn_link_drain Existing C name:pn_link_drain Proposed C name:pn_link_rescind_credit Existing Java name: Receiver.drain Proposed Java name: Receiver.rescindCredit Consider pn_link_decrease_credit, pn_link_rescind_credit Delivery pn_delivery_link Existing C name:pn_delivery_link Proposed C name:pn_delivery_get_link pn_delivery_local_state Existing C name:pn_delivery_local_state Proposed C name:pn_delivery_state Existing Java name: Delivery.getLocalState Proposed Java name: Delivery.state Local is not used elsewhere for local/remote distinctions pn_delivery_update Existing C name:pn_delivery_update Proposed C name:pn_delivery_acknowledge Existing Java name: Delivery.disposition Proposed Java name: Delivery.acknowledge Do calls to delivery.update correspond one-to-one to delivery.updated? The naming implies a symmetry that I'm not sure is there. On Thu, 13 Dec 2012, Justin Ross (JIRA) wrote: [ https://issues.apache.org/jira/browse/PROTON-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531571#comment-13531571 ] Justin Ross commented on PROTON-26: --- That's really not the case. Rejecting it is fine, but it's mostly gone undiscussed. That's partly my fault. A post to the mailing list with highlights suitable for inline comments is incoming. Engine api naming proposal -- Key: PROTON-26 URL: https://issues.apache.org/jira/browse/PROTON-26 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Justin Ross Assignee: Rafael H. Schloming Labels: api Fix For: 0.2 Attachments: engine-naming-01.patch, proton-engine-naming-proposal-2.pdf, proton-engine-naming-proposal-3.pdf See
Re: Engine API naming
On Dec 13, 2012, at 7:23 PM, Rob Godfrey rob.j.godf...@gmail.com wrote: On 14 December 2012 01:02, Weston M. Price wpr...@redhat.com wrote: On Dec 13, 2012, at 6:22 PM, Rob Godfrey rob.j.godf...@gmail.com wrote: A couple of comments... On 13 December 2012 23:37, Justin jr...@redhat.com wrote: API usability is important and deserves attention. snip pn_link_drain Existing C name:pn_link_drain Proposed C name:pn_link_rescind_credit Existing Java name: Receiver.drain Proposed Java name: Receiver.rescindCredit Consider pn_link_decrease_credit, pn_link_rescind_credit Drain *doesn't* rescind credit, or decrease credit, so I'd be -1 on these names. Drain is an indication that the sender should use all available credit, but if insufficient deliveries are available at the sender to use up all the credit, only then should it act as if all credit had been consumed. At no point is the receiver rescinding credit. snip pn_delivery_update Existing C name:pn_delivery_update Proposed C name:pn_delivery_acknowledge Existing Java name: Delivery.disposition Proposed Java name: Delivery.acknowledge Do calls to delivery.update correspond one-to-one to delivery.updated? The naming implies a symmetry that I'm not sure is there. I'm -1 on acknowledged. Acknowledgement is one type of update, but not the only one. I'm fine with changing the Java to update() to match the C. On things such as bitmaps vs. enums, I think that's just a language convention thing... I don't see a huge need to make such things identical. Naming is something that should be aligned between APIs however. That was the point of the thread, not nit picking certain things. I'm not nit-picking - just trying to be being clear that I think some of the naming suggestions would actually make the API worse. I think drain() and update( .. ) give a truer sense of the intention of the API call (though if someone can suggest alternative names that given an even better sense of the action associated with the call, then I have no issue). Easy dude...decaf perhaps? I was simply agreeing with Justin about the discrepancy between the API names in the varying implementations. I don't know anything about intention or anything else. I assume you guys already have that figured out don't you? I just work here.
