[jira] [Commented] (PROTON-191) Proton-API reconciliation reporting tool
[ https://issues.apache.org/jira/browse/PROTON-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552625#comment-13552625 ] Philip Harvey commented on PROTON-191: -- After doing an initial sweep, and discussing with Rob Godfrey, the following discrepancies have been identified, many of which will be addressed in separate Jiras. # The pn_condition_* functions all correspond to the functionality within ErronCondition et al. We need to manually check whether they are logically equivalent. # The codec-related pn_data_* functions (plus pn_message_data) will soon have Proton-J equivalents. Rob Godfrey is working on this. # Numerous Driver-related proton-c functions have no proton-j equivalent yet. Gordon Sim is working on the proton-j Driver so we should revisit after that work is committed. In many cases, there is probably little point wrapping a proton-c driver in a Java wrapper. # The pn_error_* functions have no proton-j equivalents. We need to revisit error handling, error codes etc before addressing this. # We don't yet know what pn_message_inferred does, so not sure if it needs a proton-j equivalent # We need to consider how to do the equivalent of pn_free_* in proton-j across the board. This isn't just a mechanical function mapping because of the different memory management approaches of Java and C. # Java and C programs have quite different norms for setting up SSL (roughly speaking, setTrustStore/KeyStore and setPemFile respectively), so we need to think whether there should be an equivalent method for functions such as pn_messenger_set_trusted_certificates etc. # We don't think pn_parser_* or pn_scanner_* need a proton-j equivalent. # pn_ssl_get_peer_hostname and pn_ssl_set_peer_hostname relate to PROTON-161 which has not yet been implemented in proton-j. # pn_terminus_capabilities is called by Link.setSource/Target. However, we need to modify how subsequent mutation of sources and targets is done, possibly by doing a deep copy before serialising them. Similar issues apply to Message.setAnnotations. # We need have a general logging discussion before we can add a proton-j equivalent for pn_transport_trace. Proton-API reconciliation reporting tool Key: PROTON-191 URL: https://issues.apache.org/jira/browse/PROTON-191 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Keith Wall Assignee: Keith Wall Add standalone tool that reconciles the public functions of the Proton-C API against the public API of the Proton-J API.Used so we can easily spot gaps in one implementation or the other. -- 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-197) Add small buffer test to SSL tests
[ https://issues.apache.org/jira/browse/PROTON-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552682#comment-13552682 ] Ken Giusti commented on PROTON-197: --- Looks good - ship it! Add small buffer test to SSL tests Key: PROTON-197 URL: https://issues.apache.org/jira/browse/PROTON-197 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.3 Reporter: Philip Harvey Assignee: Ken Giusti During our work on PROTON-172 we wrote a test that checked that the SSL layer still worked when a very small buffer was used for input and output. This test was not committed because it exposed a problem in proton-c, which was subsequently fixed in PROTON-171. The test should not be committed. -- 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
Is Proton a lightweight alternative to Qpid?
Hi guys, I've been using Qpid for the past several months and I really like it. However, I've mainly just been using it to pass messages between several Python processes running on the same machine, so using Qpid is probably overkill. Then I noticed Proton and got excited. Ideally I'm looking for a fast, lightweight, and portable queueing library preferrably in Python. Are there any roadmap plans to create a Proton Python broker/engine? I looked at RabbitMQ, but read the performance wasn't as good as Qpid. I was looking into the examples and noticed you could implement your own queueing server in Python, but it's not exactly portable since I'd have to build it for Linux and Windows. Thanks, TJ
Re: [VOTE] 0.3 RC3
+1 from me as well. I think we have enough votes/time to call this one. I'll post the RC3 as 0.3 shortly. --Rafael On Fri, Jan 11, 2013 at 3:29 PM, Ted Ross tr...@redhat.com wrote: +1 Tested against a couple of applications I'm developing. It looks good. -Ted On 01/08/2013 09:53 PM, Rafael Schloming wrote: Source is here: http://people.apache.org/~rhs/**qpid-proton-0.3rc3/http://people.apache.org/~rhs/qpid-proton-0.3rc3/ Java binaries are here: https://repository.apache.org/**content/repositories/**orgapacheqpid-118/https://repository.apache.org/content/repositories/orgapacheqpid-118/ Fixes since RC2 include: - messenger now reports aborted connections - tarball for ruby gem generation - ssl fix (PROTON-171) --Rafael
Re: [VOTE] 0.3 RC3
On Mon, Jan 14, 2013 at 02:35:08PM -0500, Rajith Attapattu wrote: Rafi, We should create tags for the releases. Unless I have missed (in which case I apologize), I don't see any for 0.1 and 0.2 releases (I do see branches for them though). There are branches for the releases, if not tags. -- 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/ pgpeLXL8rjhq0.pgp Description: PGP signature
Re: [VOTE] 0.3 RC3
On Mon, Jan 14, 2013 at 02:14:26PM -0500, Rafael Schloming wrote: +1 from me as well. I think we have enough votes/time to call this one. I'll post the RC3 as 0.3 shortly. Sorry, thought I'd posted before my +1. -- 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/ pgp3SlDxYPAwq.pgp Description: PGP signature
