[jira] [Created] (PROTON-165) SSL: provide access to the certificate provided by the peer (Java implementation)
Philip Harvey created PROTON-165: Summary: SSL: provide access to the certificate provided by the peer (Java implementation) Key: PROTON-165 URL: https://issues.apache.org/jira/browse/PROTON-165 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Philip Harvey This is the Java-equivalent of the change being made in PROTON-90 -- 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-90) SSL: provide access to the certificate provided by the peer.
[ https://issues.apache.org/jira/browse/PROTON-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504526#comment-13504526 ] Philip Harvey commented on PROTON-90: - Hi, do you have a view on how the api should be modified to achieve this? The reason I ask is so PROTON-165 can expose it in a similar way. SSL: provide access to the certificate provided by the peer. Key: PROTON-90 URL: https://issues.apache.org/jira/browse/PROTON-90 Project: Qpid Proton Issue Type: New Feature Components: proton-c Reporter: Ken Giusti Currently, the SSL implementation merely verifies that the certificate supplied by the remote is signed by the configured CA. There is no way to extract information from that certificate - such as the CN, subject, etc. It would be useful to provide an accessor api to get at the contents of the certificate. This could be used by the application to, for example, verify the CN and decide whether or not to close the connection. -- 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] [Created] (PROTON-171) after connection close, proton-c SSL decryption fails when left-over bytes passed to input()
Philip Harvey created PROTON-171:
Summary: after connection close, proton-c SSL decryption fails
when left-over bytes passed to input()
Key: PROTON-171
URL: https://issues.apache.org/jira/browse/PROTON-171
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Philip Harvey
We've been working on the Java SSL implementation and are seeing a test fail
against proton-c but that works against proton-j. We believe this is due to a
bug in proton-c.
One of the scenarios we wanted to cover in our testing was the case where the
Transport input method leaves left-overs, e.g. when you call server.input()
with 100 bytes of input, but it only accepts 20, as indicated by its return
value.
For example, we expect this to happen if the preceding client.output() call is
told to write to a buffer sized such that its output contains a trailing
*fragment* of an SSL packet, which input() won't be able to decipher.
We therefore modified the pump method in proton/tests/proton_tests/ssl.py to
handle this case. In its loop, it now captures the bytes left over after
calling input(), and prepends them to the input() invocation in the next
iteration. The buffer size is now a parameter so individual tests can exercise
the packet fragmenting behaviour described above.
We made the following change:
{noformat}
diff --git a/tests/proton_tests/ssl.py b/tests/proton_tests/ssl.py
index 8567b1b..237c3da 100644
--- a/tests/proton_tests/ssl.py
+++ b/tests/proton_tests/ssl.py
@@ -43,13 +43,32 @@ class SslTest(common.Test):
self.t_client = None
self.t_server = None
-def _pump(self):
+def _pump(self, buffer_size=1024):
+
+Make the transport send up to buffer_size bytes (this will be the AMQP
+header and open frame) returning a buffer containing the bytes
+sent. Transport is stateful so this will return 0 when it has
+no more frames to send.
+TODO this function is duplicated in sasl.py. Should be moved to a
common place.
+
+out_client_leftover_by_server =
+out_server_leftover_by_client =
+i=0
while True:
-out_client = self.t_client.output(1024)
-out_server = self.t_server.output(1024)
-if out_client: self.t_server.input(out_client)
-if out_server: self.t_client.input(out_server)
+
+out_client = out_client_leftover_by_server +
self.t_client.output(buffer_size)
+out_server = out_server_leftover_by_client +
self.t_server.output(buffer_size)
+
+if out_client:
+number_server_consumed = self.t_server.input(out_client)
+out_client_leftover_by_server =
out_client[number_server_consumed:] # if it consumed everything then this is
empty
+
+if out_server:
+number_client_consumed = self.t_client.input(out_server)
+out_server_leftover_by_client =
out_server[number_client_consumed:] # if it consumed everything then this is
empty
+
if not out_client and not out_server: break
+i=i+1
def _testpath(self, file):
Set the full path to the certificate,keyfile, etc. for the test.
{noformat}
Several ssl tests now fail when run against proton-c, all with the same error.
This surprised us because we hadn't started playing with the buffer size yet -
we were still using the default of 1024.
For example, test_server_authentication gives this output:
{noformat}
proton_tests.ssl.SslTest.test_server_authentication
.[0xa2ca208:0]
ERROR[-2] SSL Failure: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
failed or bad record mac
fail
Error during test: Traceback (most recent call last):
File ./tests/proton-test, line 331, in run
phase()
File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 166, in
test_server_authentication
self._pump()
File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 63, in _pump
number_server_consumed = self.t_server.input(out_client)
File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2141,
in input
return self._check(n)
File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2115,
in _check
raise exc([%s]: %s % (err,
pn_error_text(pn_transport_error(self._trans
TransportException: [-2]: SSL Failure: error:1408F119:SSL
routines:SSL3_GET_RECORD:decryption failed or bad record mac
Totals: 1 tests, 0 passed, 0 skipped, 0 ignored, 1 failed
{noformat}
The first pump() call in this test works fine; the failure we see is when it's
invoked again after closing the connection.
The problem is that the previous t_server.input call didn't accept *any* of the
bytes given to it. On the next
[jira] [Assigned] (PROTON-171) after connection close, proton-c SSL decryption fails when left-over bytes passed to input()
[ https://issues.apache.org/jira/browse/PROTON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-171: Assignee: Ken Giusti after connection close, proton-c SSL decryption fails when left-over bytes passed to input() Key: PROTON-171 URL: https://issues.apache.org/jira/browse/PROTON-171 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Philip Harvey Assignee: Ken Giusti We've been working on the Java SSL implementation and are seeing a test fail against proton-c but that works against proton-j. We believe this is due to a bug in proton-c. One of the scenarios we wanted to cover in our testing was the case where the Transport input method leaves left-overs, e.g. when you call server.input() with 100 bytes of input, but it only accepts 20, as indicated by its return value. For example, we expect this to happen if the preceding client.output() call is told to write to a buffer sized such that its output contains a trailing *fragment* of an SSL packet, which input() won't be able to decipher. We therefore modified the pump method in proton/tests/proton_tests/ssl.py to handle this case. In its loop, it now captures the bytes left over after calling input(), and prepends them to the input() invocation in the next iteration. The buffer size is now a parameter so individual tests can exercise the packet fragmenting behaviour described above. We made the following change: --- diff --git a/tests/proton_tests/ssl.py b/tests/proton_tests/ssl.py index 8567b1b..237c3da 100644 --- a/tests/proton_tests/ssl.py +++ b/tests/proton_tests/ssl.py @@ -43,13 +43,32 @@ class SslTest(common.Test): self.t_client = None self.t_server = None -def _pump(self): +def _pump(self, buffer_size=1024): + +Make the transport send up to buffer_size bytes (this will be the AMQP +header and open frame) returning a buffer containing the bytes +sent. Transport is stateful so this will return 0 when it has +no more frames to send. +TODO this function is duplicated in sasl.py. Should be moved to a common place. + +out_client_leftover_by_server = +out_server_leftover_by_client = +i=0 while True: -out_client = self.t_client.output(1024) -out_server = self.t_server.output(1024) -if out_client: self.t_server.input(out_client) -if out_server: self.t_client.input(out_server) + +out_client = out_client_leftover_by_server + self.t_client.output(buffer_size) +out_server = out_server_leftover_by_client + self.t_server.output(buffer_size) + +if out_client: +number_server_consumed = self.t_server.input(out_client) +out_client_leftover_by_server = out_client[number_server_consumed:] # if it consumed everything then this is empty + +if out_server: +number_client_consumed = self.t_client.input(out_server) +out_server_leftover_by_client = out_server[number_client_consumed:] # if it consumed everything then this is empty + if not out_client and not out_server: break +i=i+1 def _testpath(self, file): Set the full path to the certificate,keyfile, etc. for the test. --- Several ssl tests now fail when run against proton-c, all with the same error. This surprised us because we hadn't started playing with the buffer size yet - we were still using the default of 1024. For example, test_server_authentication gives this output: --- proton_tests.ssl.SslTest.test_server_authentication .[0xa2ca208:0] ERROR[-2] SSL Failure: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac fail Error during test: Traceback (most recent call last): File ./tests/proton-test, line 331, in run phase() File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 166, in test_server_authentication self._pump() File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 63, in _pump number_server_consumed = self.t_server.input(out_client) File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2141, in input return self._check(n) File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2115, in _check raise exc([%s]: %s % (err, pn_error_text(pn_transport_error(self._trans TransportException: [-2]: SSL Failure: error:1408F119:SSL
[jira] [Created] (PROTON-172) Implement SSL within proton-j
Philip Harvey created PROTON-172: Summary: Implement SSL within proton-j Key: PROTON-172 URL: https://issues.apache.org/jira/browse/PROTON-172 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Philip Harvey Assignee: Philip Harvey Implement SSL within proton-j -- 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-172) Implement SSL within proton-j
[ https://issues.apache.org/jira/browse/PROTON-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-172: - Attachment: 0001-PROTON-172-refactored-Java-SSL-implementation-to-mak.patch refactored Java SSL implementation to make it more readable Implement SSL within proton-j - Key: PROTON-172 URL: https://issues.apache.org/jira/browse/PROTON-172 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Philip Harvey Assignee: Keith Wall Attachments: 0001-PROTON-172-Java-SSL-implementation-enable-system-tes.patch, 0001-PROTON-172-refactored-Java-SSL-implementation-to-mak.patch, 0002-PROTON-172-Extra-tests-and-enhanced-pump-method.patch Implement SSL within proton-j -- 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=13509870#comment-13509870 ] Philip Harvey commented on PROTON-136: -- Hi Ken, I'm keen to explore what corresponding Java changes will need to be made. To allow me to do this, is it possible you could commit your work so far to a branch? That would give us a chance to get the tests passing against both proton-c and proton-j before merging to trunk. How does that sound to you? 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 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-172) Implement SSL within proton-j
[ https://issues.apache.org/jira/browse/PROTON-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-172: - Attachment: (was: 0001-PROTON-172-refactored-Java-SSL-implementation-to-mak.patch) Implement SSL within proton-j - Key: PROTON-172 URL: https://issues.apache.org/jira/browse/PROTON-172 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Philip Harvey Assignee: Keith Wall Attachments: 0001-PROTON-172-Java-SSL-implementation-enable-system-tes.patch, 0002-PROTON-172-Extra-tests-and-enhanced-pump-method.patch Implement SSL within proton-j -- 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-172) Implement SSL within proton-j
[ https://issues.apache.org/jira/browse/PROTON-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-172: - Attachment: 0002-PROTON-172-Moved-SSL-classes-into-package-org.engine.patch 0001-PROTON-172-refactored-Java-SSL-implementation-to-mak.patch refactored SSL implementation - extracted most byte buffer manipulation to improve readability. The second patch is only a package-move of the SSL classes into their own package, and a couple of visibility changes to PlainTransportWrapper and SslImpl.wrap to allow this. Implement SSL within proton-j - Key: PROTON-172 URL: https://issues.apache.org/jira/browse/PROTON-172 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Philip Harvey Assignee: Keith Wall Attachments: 0001-PROTON-172-Java-SSL-implementation-enable-system-tes.patch, 0001-PROTON-172-refactored-Java-SSL-implementation-to-mak.patch, 0002-PROTON-172-Extra-tests-and-enhanced-pump-method.patch, 0002-PROTON-172-Moved-SSL-classes-into-package-org.engine.patch Implement SSL within proton-j -- 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] [Created] (PROTON-179) proton-j - replace system.out and system.err calls with java.util.logging
Philip Harvey created PROTON-179: Summary: proton-j - replace system.out and system.err calls with java.util.logging Key: PROTON-179 URL: https://issues.apache.org/jira/browse/PROTON-179 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.2 Reporter: Philip Harvey Assignee: Philip Harvey We do not yet know what the final solution is for how proton-j should perform logging. We think we might want to allow Proton's host application to provide logging callbacks, allowing Proton's output to be combined with the host application's output. Pending the final logging design, we should use java.util.logging in the mean time. This is at least preferable to the existing system.out.println calls. -- 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-179) proton-j - replace system.out and system.err calls with java.util.logging
[ https://issues.apache.org/jira/browse/PROTON-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-179: - Attachment: 0001-PROTON-179-use-java.util.logging-instead-of-system.o.patch attached patch. Should be applied AFTER the patches in PROTON-172. proton-j - replace system.out and system.err calls with java.util.logging - Key: PROTON-179 URL: https://issues.apache.org/jira/browse/PROTON-179 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.2 Reporter: Philip Harvey Assignee: Philip Harvey Attachments: 0001-PROTON-179-use-java.util.logging-instead-of-system.o.patch We do not yet know what the final solution is for how proton-j should perform logging. We think we might want to allow Proton's host application to provide logging callbacks, allowing Proton's output to be combined with the host application's output. Pending the final logging design, we should use java.util.logging in the mean time. This is at least preferable to the existing system.out.println calls. -- 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-179) proton-j - replace system.out and system.err calls with java.util.logging
[ https://issues.apache.org/jira/browse/PROTON-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-179: Assignee: Rob Godfrey (was: Philip Harvey) hi Rob, pls could you review and commit if you're happy proton-j - replace system.out and system.err calls with java.util.logging - Key: PROTON-179 URL: https://issues.apache.org/jira/browse/PROTON-179 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.2 Reporter: Philip Harvey Assignee: Rob Godfrey Attachments: 0001-PROTON-179-use-java.util.logging-instead-of-system.o.patch We do not yet know what the final solution is for how proton-j should perform logging. We think we might want to allow Proton's host application to provide logging callbacks, allowing Proton's output to be combined with the host application's output. Pending the final logging design, we should use java.util.logging in the mean time. This is at least preferable to the existing system.out.println calls. -- 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=13510620#comment-13510620 ] Philip Harvey commented on PROTON-136: -- Thanks Ken, I was planning to look at this today but got delayed by some proton-c / Swig / Python problems. Will take a look tomorrow. 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 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=13526354#comment-13526354 ] Philip Harvey commented on PROTON-136: -- Hi Ken, I like your suggestion to change pn_ssl_new to accept an optional state object, i.e. pn_ssl_t *pn_ssl_new( pn_ssl_domain_t *, pn_transport_t *, pn_ssl_state_t *); I've nearly finished implementing the Java changes for this and will send you a proposed patch in the next hour or two. This will contain the necessary Java and ssl.py changes, plus a couple of minor tweaks to the proton-c proton.py file. I haven't touched the C code. I propose one minor change to the API. Since the Java SSL state object is just storing a hostname and port, calling it SSLState in the Python wrapper doesn't feel right to me. How about SSLSessionDetails instead? For me, this name is a reasonable description, whether you're using C or Java under the covers. 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 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-136) Add support for SSL session resumption
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-136: - Attachment: PROTON-136-initial-Java-and-Python.tgz My initial patch to add SSL resumption support to Java. Also contains corresponding Python changes. See README inside the tarfile for details. 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 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] [Assigned] (PROTON-172) Implement SSL within proton-j
[ https://issues.apache.org/jira/browse/PROTON-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-172: Assignee: Keith Wall (was: Rob Godfrey) Implement SSL within proton-j - Key: PROTON-172 URL: https://issues.apache.org/jira/browse/PROTON-172 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Philip Harvey Assignee: Keith Wall Attachments: 0001-PROTON-172-improved-unit-test-to-check-return-value-.patch, 0001-PROTON-172-Java-SSL-implementation-enable-system-tes.patch, 0001-PROTON-172-refactored-Java-SSL-implementation-to-mak.patch, 0002-PROTON-172-Extra-tests-and-enhanced-pump-method.patch, 0002-PROTON-172-Moved-SSL-classes-into-package-org.engine.patch Implement SSL within proton-j -- 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-172) Implement SSL within proton-j
[ https://issues.apache.org/jira/browse/PROTON-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-172: - Attachment: 0001-PROTON-172-improved-unit-test-to-check-return-value-.patch attached patch that improves unit test as suggested by Keith's review comments. Implement SSL within proton-j - Key: PROTON-172 URL: https://issues.apache.org/jira/browse/PROTON-172 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Philip Harvey Assignee: Rob Godfrey Attachments: 0001-PROTON-172-improved-unit-test-to-check-return-value-.patch, 0001-PROTON-172-Java-SSL-implementation-enable-system-tes.patch, 0001-PROTON-172-refactored-Java-SSL-implementation-to-mak.patch, 0002-PROTON-172-Extra-tests-and-enhanced-pump-method.patch, 0002-PROTON-172-Moved-SSL-classes-into-package-org.engine.patch Implement SSL within proton-j -- 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=13529126#comment-13529126 ] Philip Harvey commented on PROTON-136: -- There's no easy way of achieving session resumption across process restarts in Java, so this won't be supported in proton-j for now. However, that doesn't rule out proton-c supporting it if it's consdered important enough. Depending on how it's implemented, I don't expect that it would cause the APIs of proton-c and proton-j to diverge. 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 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=13534937#comment-13534937 ] Philip Harvey commented on PROTON-136: -- It's not clear to me whether I need to make corresponding changes to the Java Transport and Ssl interfaces. I had been assuming that Transport.ssl(..) would be called only once on a given Transport instance, therefore the ambiguity Ken mentioned wouldn't arise. I had therefore intended to JavaDoc this expectation in Transport.java and leave the implementation code unchanged. It's surprisingly hard to swap in alternative Java Ssl instances on a Transport instance because, for example, they cache both encrypted/cleartext data that the input/output methods have not yet fully accepted, respectively. I can't see an easy way for a new Ssl object to reliably inherit this in-flight data, particularly if the encryption key of the new Ssl session is different to the old one. If this is a vital use case that needs to be supported now, then there *may* be a way for us to implement it. But, if not, then I'd prefer to leave the Java code functionally unchanged, in which case my only doubt is how Transport.ssl(..) should behave when called twice with different SslDomains. I'd actually like to throw an IllegalStateException in this case. 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: Philip Harvey 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-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] [Updated] (PROTON-194) Change proton's build systems to support allow for the creation of a Java binding for proton-c.
[ https://issues.apache.org/jira/browse/PROTON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-194: - Description: The catalyst for this work was the need to conveniently build and test the JNI bindings created in PROTON-192. However, there are a number of other requirements for our build system that are worth reiterating. Each of the following things should be easy to do in a small number of steps (ideally in one step). - Starting from a fresh checkout out the base proton directory: - Build proton-c, including the language bindings - Build proton-j - Run the system tests against: - proton-c via its Python binding - proton-c via the JNI binding - proton-j It should also be convenient to run all of the above system test configurations after making a local change to any of: - proton-api - proton-c implementation - proton-c JNI bindings - proton-j - Starting from a *fresh checkout* of proton-c, release the proton-c tarball - Starting from a *fresh checkout* of proton-j, publish the proton-j maven artefacts I'm not sure how fixed the aforementioned requirements for independent checkouts are. Maybe we could relax the above requirement by stating that you would also need to check out an accompanying top-level api module. was:Change Change proton's build systems to support allow for the creation of a Java binding for proton-c. --- Key: PROTON-194 URL: https://issues.apache.org/jira/browse/PROTON-194 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Keith Wall The catalyst for this work was the need to conveniently build and test the JNI bindings created in PROTON-192. However, there are a number of other requirements for our build system that are worth reiterating. Each of the following things should be easy to do in a small number of steps (ideally in one step). - Starting from a fresh checkout out the base proton directory: - Build proton-c, including the language bindings - Build proton-j - Run the system tests against: - proton-c via its Python binding - proton-c via the JNI binding - proton-j It should also be convenient to run all of the above system test configurations after making a local change to any of: - proton-api - proton-c implementation - proton-c JNI bindings - proton-j - Starting from a *fresh checkout* of proton-c, release the proton-c tarball - Starting from a *fresh checkout* of proton-j, publish the proton-j maven artefacts I'm not sure how fixed the aforementioned requirements for independent checkouts are. Maybe we could relax the above requirement by stating that you would also need to check out an accompanying top-level api module. -- 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-194) Change proton's build systems to support allow for the creation of a Java binding for proton-c.
[ https://issues.apache.org/jira/browse/PROTON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-194: - Description: The catalyst for this work was the need to conveniently build and test the JNI bindings created in PROTON-192. However, there are a number of other requirements for our build system that are worth reiterating. Each of the following things should be easy to do in a small number of steps (ideally in one step). - Starting from a fresh checkout out the base proton directory: - Build proton-c, including the language bindings - Build proton-j - Run the system tests against: - proton-c via its Python binding - proton-c via the JNI binding - proton-j After making a local code change to any part of Proton it should also be easy to re-run each of the system test configurations listed above. - Create an SVN tag and use it to: - Release the proton-c tarball - Publish the proton-j maven artefacts I'm not sure how fixed the aforementioned requirements for independent checkouts are. Maybe we could relax the requirement by stating that you would also need to check out an accompanying top-level api module. was: The catalyst for this work was the need to conveniently build and test the JNI bindings created in PROTON-192. However, there are a number of other requirements for our build system that are worth reiterating. Each of the following things should be easy to do in a small number of steps (ideally in one step). - Starting from a fresh checkout out the base proton directory: - Build proton-c, including the language bindings - Build proton-j - Run the system tests against: - proton-c via its Python binding - proton-c via the JNI binding - proton-j It should also be convenient to run all of the above system test configurations after making a local change to any of: - proton-api - proton-c implementation - proton-c JNI bindings - proton-j - Starting from a *fresh checkout* of proton-c, release the proton-c tarball - Starting from a *fresh checkout* of proton-j, publish the proton-j maven artefacts I'm not sure how fixed the aforementioned requirements for independent checkouts are. Maybe we could relax the requirement by stating that you would also need to check out an accompanying top-level api module. Change proton's build systems to support allow for the creation of a Java binding for proton-c. --- Key: PROTON-194 URL: https://issues.apache.org/jira/browse/PROTON-194 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Keith Wall The catalyst for this work was the need to conveniently build and test the JNI bindings created in PROTON-192. However, there are a number of other requirements for our build system that are worth reiterating. Each of the following things should be easy to do in a small number of steps (ideally in one step). - Starting from a fresh checkout out the base proton directory: - Build proton-c, including the language bindings - Build proton-j - Run the system tests against: - proton-c via its Python binding - proton-c via the JNI binding - proton-j After making a local code change to any part of Proton it should also be easy to re-run each of the system test configurations listed above. - Create an SVN tag and use it to: - Release the proton-c tarball - Publish the proton-j maven artefacts I'm not sure how fixed the aforementioned requirements for independent checkouts are. Maybe we could relax the requirement by stating that you would also need to check out an accompanying top-level api module. -- 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-194) Change proton's build systems to support allow for the creation of a Java binding for proton-c.
[ https://issues.apache.org/jira/browse/PROTON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-194: - Description: The catalyst for this work was the need to conveniently build and test the JNI bindings created in PROTON-192. However, there are a number of other requirements for our build system that are worth reiterating. Each of the following things should be easy to do in a small number of steps (ideally in one step). - Starting from a fresh checkout out the base proton directory: - Build proton-c, including the language bindings - Build proton-j - Run the system tests against: - proton-c via its Python binding - proton-c via the JNI binding - proton-j After making a local code change to any part of Proton it should also be easy to re-run each of the system test configurations listed above. - Create an SVN tag and use it to: - Release the proton-c tarball - Publish the proton-j maven artefacts I'm not sure how fixed the aforementioned requirements for independent checkouts are. Maybe we could relax the requirement by stating that you would also need to check out an accompanying top-level api module. All the usual software engineering rules apply, e.g. - Don't Repeat Yourself - Adhere to the Principle of Least Surprise was: The catalyst for this work was the need to conveniently build and test the JNI bindings created in PROTON-192. However, there are a number of other requirements for our build system that are worth reiterating. Each of the following things should be easy to do in a small number of steps (ideally in one step). - Starting from a fresh checkout out the base proton directory: - Build proton-c, including the language bindings - Build proton-j - Run the system tests against: - proton-c via its Python binding - proton-c via the JNI binding - proton-j After making a local code change to any part of Proton it should also be easy to re-run each of the system test configurations listed above. - Create an SVN tag and use it to: - Release the proton-c tarball - Publish the proton-j maven artefacts I'm not sure how fixed the aforementioned requirements for independent checkouts are. Maybe we could relax the requirement by stating that you would also need to check out an accompanying top-level api module. Change proton's build systems to support allow for the creation of a Java binding for proton-c. --- Key: PROTON-194 URL: https://issues.apache.org/jira/browse/PROTON-194 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Keith Wall The catalyst for this work was the need to conveniently build and test the JNI bindings created in PROTON-192. However, there are a number of other requirements for our build system that are worth reiterating. Each of the following things should be easy to do in a small number of steps (ideally in one step). - Starting from a fresh checkout out the base proton directory: - Build proton-c, including the language bindings - Build proton-j - Run the system tests against: - proton-c via its Python binding - proton-c via the JNI binding - proton-j After making a local code change to any part of Proton it should also be easy to re-run each of the system test configurations listed above. - Create an SVN tag and use it to: - Release the proton-c tarball - Publish the proton-j maven artefacts I'm not sure how fixed the aforementioned requirements for independent checkouts are. Maybe we could relax the requirement by stating that you would also need to check out an accompanying top-level api module. All the usual software engineering rules apply, e.g. - Don't Repeat Yourself - Adhere to the Principle of Least Surprise -- 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-194) Change proton's build systems to support allow for the creation of a Java binding for proton-c.
[ https://issues.apache.org/jira/browse/PROTON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562722#comment-13562722 ] Philip Harvey commented on PROTON-194: -- Discussions on how to implement this JIRA are primarily on the Proton mailing list in the thread titled Changing the Proton build system to accommodate jni bindings: http://mail-archives.apache.org/mod_mbox/qpid-proton/201301.mbox/browser Change proton's build systems to support allow for the creation of a Java binding for proton-c. --- Key: PROTON-194 URL: https://issues.apache.org/jira/browse/PROTON-194 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Keith Wall The catalyst for this work was the need to conveniently build and test the JNI bindings created in PROTON-192. However, there are a number of other requirements for our build system that are worth reiterating. To avoid making excessive edits to this JIRA I've created a wiki page listing the provisional requirements of or build system: https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+proposals -- 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] [Created] (PROTON-209) Update README file(s) to more specific about required versions of tools
Philip Harvey created PROTON-209: Summary: Update README file(s) to more specific about required versions of tools Key: PROTON-209 URL: https://issues.apache.org/jira/browse/PROTON-209 Project: Qpid Proton Issue Type: Task Affects Versions: 0.3 Reporter: Philip Harvey Priority: Minor We should be more explicit about which version of the following tools are required by Proton, either in the top level README or in READMEs in the relevant sub-folders: - Python (see PROTON-199). - Swig - cmake? (the required version is specified in the CMakeLists.txt files but maybe it would be polite to mention in the README too). - Maven? (or maybe we can omit this for same reasons as cmake version) - possibly others, e.g. openssl, gcc, epydoc, Perl, Ruby etc. -- 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-194) Change proton's build systems to allow for the creation of a Java binding for proton-c.
[ https://issues.apache.org/jira/browse/PROTON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-194: - Summary: Change proton's build systems to allow for the creation of a Java binding for proton-c. (was: Change proton's build systems to support allow for the creation of a Java binding for proton-c.) Change proton's build systems to allow for the creation of a Java binding for proton-c. --- Key: PROTON-194 URL: https://issues.apache.org/jira/browse/PROTON-194 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Keith Wall The catalyst for this work was the need to conveniently build and test the JNI bindings created in PROTON-192. However, there are a number of other requirements for our build system that are worth reiterating. To avoid making excessive edits to this JIRA I've created a wiki page listing the provisional requirements of or build system: https://cwiki.apache.org/confluence/display/qpid/Proton+build+system+proposals -- 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-192) Implement Proton-JNI binding for proton-c
[ https://issues.apache.org/jira/browse/PROTON-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved PROTON-192. -- Resolution: Fixed Fix Version/s: 0.4 merged to trunk Implement Proton-JNI binding for proton-c - Key: PROTON-192 URL: https://issues.apache.org/jira/browse/PROTON-192 Project: Qpid Proton Issue Type: New Feature Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.4 Expose proton-c via the Java proton API using swig/JNI. -- 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-207) Modify release.sh to create single release artefact from top-level proton directory
[ https://issues.apache.org/jira/browse/PROTON-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey closed PROTON-207. Resolution: Duplicate Modify release.sh to create single release artefact from top-level proton directory --- Key: PROTON-207 URL: https://issues.apache.org/jira/browse/PROTON-207 Project: Qpid Proton Issue Type: Task Affects Versions: 0.3 Reporter: Philip Harvey Assignee: Philip Harvey In the light of the build system refactoring done in PROTON-194, release.sh needs to be modified. It should now create a single tarball, which should allow the script to be simplified. -- 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] [Created] (PROTON-225) Redesign Transport interface such that Transport owns the in/out buffers rather than its client
Philip Harvey created PROTON-225: Summary: Redesign Transport interface such that Transport owns the in/out buffers rather than its client Key: PROTON-225 URL: https://issues.apache.org/jira/browse/PROTON-225 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.3 Reporter: Philip Harvey Fix For: 0.5 This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix. -- 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-217) cmake build system should include install target for Java binaries
[ https://issues.apache.org/jira/browse/PROTON-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13579331#comment-13579331 ] Philip Harvey commented on PROTON-217: -- The link below gives some background to how jar installation on Linux works, at least on Fedora: https://fedoraproject.org/wiki/Packaging:Java#JAR_file_installation cmake build system should include install target for Java binaries Key: PROTON-217 URL: https://issues.apache.org/jira/browse/PROTON-217 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.3 Reporter: Philip Harvey Priority: Minor The cmake build system was recently modified in PROTON-194 to include compilation of the Java artefacts. However, we don't yet have a target to install them. Further discussion is required to decide where they should be installed. -- 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-217) cmake build system should include install target for Java binaries
[ https://issues.apache.org/jira/browse/PROTON-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-217: Assignee: Philip Harvey cmake build system should include install target for Java binaries Key: PROTON-217 URL: https://issues.apache.org/jira/browse/PROTON-217 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.3 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor The cmake build system was recently modified in PROTON-194 to include compilation of the Java artefacts. However, we don't yet have a target to install them. Further discussion is required to decide where they should be installed. -- 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] [Created] (PROTON-242) Shared library used JNI code has poor name libproton-swig.so
Philip Harvey created PROTON-242: Summary: Shared library used JNI code has poor name libproton-swig.so Key: PROTON-242 URL: https://issues.apache.org/jira/browse/PROTON-242 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Philip Harvey Assignee: Keith Wall Fix For: 0.4 The shared library used JNI code has name libproton-swig.so, which is poor because the (a) it doesn't hint that it's used by the proton-jni.jar, and (b) Swig should be an implementation detail that is hidden from the user of the library. A better name would be libproton-jni.so. Note that I've used the lib prefix as required by JNI on Linux. On Windows, this prefix should be blank. -- 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-60) Support configuring the max frame size.
[ https://issues.apache.org/jira/browse/PROTON-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-60: Fix Version/s: (was: 0.4) 0.5 Support configuring the max frame size. --- Key: PROTON-60 URL: https://issues.apache.org/jira/browse/PROTON-60 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Reporter: Hiram Chirino Assignee: Philip Harvey Labels: api Fix For: 0.5 -- 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-225) Redesign Transport interface such that Transport owns the in/out buffers rather than its client
[ https://issues.apache.org/jira/browse/PROTON-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-225: - Description: This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix. When refactoring the Java implementation, we should consider if the point when the sent/received protocol logging is done should be changed. was:This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix. Redesign Transport interface such that Transport owns the in/out buffers rather than its client --- Key: PROTON-225 URL: https://issues.apache.org/jira/browse/PROTON-225 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.3 Reporter: Philip Harvey Assignee: Ken Giusti Fix For: 0.5 This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix. When refactoring the Java implementation, we should consider if the point when the sent/received protocol logging is done should be changed. -- 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-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-214: - Fix Version/s: 0.4 Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Gordon Sim Priority: Minor Fix For: 0.4 The system test proton_tests.messenger.MessengerTest.testSendBogus is failing on my computer when run against proton-j. I think I've seen this test pass occasionally so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run_test$41(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:412) at
[jira] [Commented] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13584122#comment-13584122 ] Philip Harvey commented on PROTON-214: -- This test was also failing when run under the proton-jni profile, because JNIMessenger does not yet handle non-zero (ie non-success) returns codes from proton-c functions. I have modified it to throw ProtonUnsupportedOperationException's in revision 1448962 so that this test skips rather than fails when using proton-jni. Leaving this Jira open until the proton-j problem is also resolved. Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Gordon Sim Priority: Minor Fix For: 0.5 The system test proton_tests.messenger.MessengerTest.testSendBogus is failing on my computer when run against proton-j. I think I've seen this test pass occasionally so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at
[jira] [Assigned] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-214: Assignee: Philip Harvey (was: Gordon Sim) Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Fix For: 0.5 The system test proton_tests.messenger.MessengerTest.testSendBogus is failing on my computer when run against proton-j. I think I've seen this test pass occasionally so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at
[jira] [Updated] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-214: - Fix Version/s: (was: 0.5) Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor The system test proton_tests.messenger.MessengerTest.testSendBogus is failing on my computer when run against proton-j. I think I've seen this test pass occasionally so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run_test$41(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:412) at
[jira] [Updated] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-214: - Affects Version/s: 0.4 Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3, 0.4 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor The system test proton_tests.messenger.MessengerTest.testSendBogus is failing on my computer when run against proton-j. I think I've seen this test pass occasionally so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run_test$41(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:412) at
[jira] [Updated] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-214: - Description: The system test proton_tests.messenger.MessengerTest.testSendBogus is failing against both the proton-jni profile and, on certain computers, when run against proton-j too. The proton-jni problem seems to be caused by the fact the the JNI Messenger implementation ignores proton-c's error return codes. I think I've seen this test pass occasionally against proton-j so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run_test$41(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:412) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at
[jira] [Created] (PROTON-252) Reduce visibiliy of constructors for classes that should be created by factories eg MessageImpl
Philip Harvey created PROTON-252: Summary: Reduce visibiliy of constructors for classes that should be created by factories eg MessageImpl Key: PROTON-252 URL: https://issues.apache.org/jira/browse/PROTON-252 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.4 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor These constructors are currently public but deprecated, and should be made package-private where possible to enforce the use of the factories instead. -- 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] [Created] (PROTON-253) Remove compile-time dependency on bouncycastle cryptography library
Philip Harvey created PROTON-253: Summary: Remove compile-time dependency on bouncycastle cryptography library Key: PROTON-253 URL: https://issues.apache.org/jira/browse/PROTON-253 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.4 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor It is inconvenient that the proton-j requires bouncycastle to be on the compile-time classpath, as the Proton user may wish to use an alternative provider, or to use Java's vanilla SSL certificate support. -- 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] [Created] (PROTON-256) Improve Engine API JavaDoc
Philip Harvey created PROTON-256: Summary: Improve Engine API JavaDoc Key: PROTON-256 URL: https://issues.apache.org/jira/browse/PROTON-256 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor The JavaDoc in the Proton API engine package is very sparse and should be improved. -- 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] [Created] (PROTON-257) Add example to illustrate use of proton-j API
Philip Harvey created PROTON-257: Summary: Add example to illustrate use of proton-j API Key: PROTON-257 URL: https://issues.apache.org/jira/browse/PROTON-257 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Add example to illustrate use of proton-j API. This is intended to be instructive to new developers to show a simple, conventional use of the lower level Proton APIs, i.e. Engine and Message but not Messenger. -- 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] [Created] (PROTON-259) proton-j engine operations do not check if the endpoint is already closed
Philip Harvey created PROTON-259: Summary: proton-j engine operations do not check if the endpoint is already closed Key: PROTON-259 URL: https://issues.apache.org/jira/browse/PROTON-259 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Philip Harvey Operations such as SessionImpl#receiver(receiverName) and LinkImpl#delivery do not check the state of the endpoint. I believe they should throw an exception. Moreover, I notice that the following sequence of calls cause the transport to produce no output: --- sender.close; // deliberately use a closed sender. // The presence of this line causes the subsequent transport.output to produce zero bytes. sender.delivery(deliveryTag); transport.output(); --- -- 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-259) proton-j engine operations do not check if the endpoint is already closed
[ https://issues.apache.org/jira/browse/PROTON-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-259: Assignee: Philip Harvey proton-j engine operations do not check if the endpoint is already closed - Key: PROTON-259 URL: https://issues.apache.org/jira/browse/PROTON-259 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Philip Harvey Assignee: Philip Harvey Operations such as SessionImpl#receiver(receiverName) and LinkImpl#delivery do not check the state of the endpoint. I believe they should throw an exception. Moreover, I notice that the following sequence of calls cause the transport to produce no output: --- sender.close; // deliberately use a closed sender. // The presence of this line causes the subsequent transport.output to produce zero bytes. sender.delivery(deliveryTag); transport.output(); --- -- 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-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-214: Assignee: Gordon Sim (was: Philip Harvey) Hi Gordon, Would you mind looking at my commit to fix this race condition please? It's r1459089. Thanks. Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3, 0.4 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Gordon Sim Priority: Minor Attachments: JNIMessenger.patch The system test proton_tests.messenger.MessengerTest.testSendBogus is failing against both the proton-jni profile and, on certain computers, when run against proton-j too. The proton-jni problem seems to be caused by the fact the the JNI Messenger implementation ignores proton-c's error return codes. I think I've seen this test pass occasionally against proton-j so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at
[jira] [Resolved] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved PROTON-214. -- Resolution: Fixed Fix Version/s: 0.5 Assignee: Philip Harvey (was: Gordon Sim) Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3, 0.4 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Fix For: 0.5 Attachments: JNIMessenger.patch The system test proton_tests.messenger.MessengerTest.testSendBogus is failing against both the proton-jni profile and, on certain computers, when run against proton-j too. The proton-jni problem seems to be caused by the fact the the JNI Messenger implementation ignores proton-c's error return codes. I think I've seen this test pass occasionally against proton-j so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at
[jira] [Commented] (PROTON-215) Add tests to verify AMQP 1.0 type support for all language bindings
[ https://issues.apache.org/jira/browse/PROTON-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13610069#comment-13610069 ] Philip Harvey commented on PROTON-215: -- reformatted InteropTest.java to adhere to Qpid coding conventions (no tabs, braces on newlines etc). Committed in r1459686. Add tests to verify AMQP 1.0 type support for all language bindings --- Key: PROTON-215 URL: https://issues.apache.org/jira/browse/PROTON-215 Project: Qpid Proton Issue Type: Test Components: proton-c Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Alan Conway Labels: test For each language binding, we need to verify that the language can encode to and decode from the AMQP 1.0 types. -- 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] [Created] (PROTON-280) Maven should generate project documentation including markdown docs
Philip Harvey created PROTON-280: Summary: Maven should generate project documentation including markdown docs Key: PROTON-280 URL: https://issues.apache.org/jira/browse/PROTON-280 Project: Qpid Proton Issue Type: Improvement Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Maven can generate a web site from a project. We should configure this to include the markdown documents added recently in docs. -- 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] [Created] (PROTON-281) Engine should handle errors by generating implicit CLOSE frame
Philip Harvey created PROTON-281: Summary: Engine should handle errors by generating implicit CLOSE frame Key: PROTON-281 URL: https://issues.apache.org/jira/browse/PROTON-281 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Philip Harvey Assignee: Philip Harvey As discussed on the mailing list recently (see http://qpid.2158936.n2.nabble.com/Defining-the-behaviour-of-Proton-Engine-API-under-error-conditions-tp7590533.html), the Engine should implicitly generate a CLOSE frame in case of errors such as malformed frames etc. -- 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] [Created] (PROTON-282) Add support for transport unbind to proton-j
Philip Harvey created PROTON-282: Summary: Add support for transport unbind to proton-j Key: PROTON-282 URL: https://issues.apache.org/jira/browse/PROTON-282 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Philip Harvey As discussed on the mailing list recently (see http://qpid.2158936.n2.nabble.com/Defining-the-behaviour-of-Proton-Engine-API-under-error-conditions-tp7590533.html), Proton applications sometimes want to unbind a transport, e.g. following an error, with the intention of binding to a new transport later on. proton-j does not currently support unbinding. -- 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] [Created] (PROTON-283) Add support for idle timeout to proton-j
Philip Harvey created PROTON-283: Summary: Add support for idle timeout to proton-j Key: PROTON-283 URL: https://issues.apache.org/jira/browse/PROTON-283 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Philip Harvey proton-j does not currently support specifying a connection's idle timeout as required by Section 2.4.5 of the AMQP spec (http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-doc-idle-time-out) -- 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-283) Add support for idle timeout to proton-j
[ https://issues.apache.org/jira/browse/PROTON-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey closed PROTON-283. Resolution: Duplicate Add support for idle timeout to proton-j Key: PROTON-283 URL: https://issues.apache.org/jira/browse/PROTON-283 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Philip Harvey proton-j does not currently support specifying a connection's idle timeout as required by Section 2.4.5 of the AMQP spec (http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-doc-idle-time-out) -- 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] [Created] (PROTON-284) Add JUnit tests for Engine Connection
Philip Harvey created PROTON-284: Summary: Add JUnit tests for Engine Connection Key: PROTON-284 URL: https://issues.apache.org/jira/browse/PROTON-284 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Philip Harvey Add tests that exercise the Engine's adherence to the Connection-related sections of the AMQP spec. These tests are similar in to the existing Python ones (in tests/python), but have a more direct correspondence to the requirements in the spec. -- 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-284) Add JUnit tests for Engine Connection
[ https://issues.apache.org/jira/browse/PROTON-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-284: Assignee: Philip Harvey Add JUnit tests for Engine Connection - Key: PROTON-284 URL: https://issues.apache.org/jira/browse/PROTON-284 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Philip Harvey Assignee: Philip Harvey Add tests that exercise the Engine's adherence to the Connection-related sections of the AMQP spec. These tests are similar in to the existing Python ones (in tests/python), but have a more direct correspondence to the requirements in the spec. -- 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-276) Ssl tests fail against proton-j on Windows (tests can't find certificates)
[ https://issues.apache.org/jira/browse/PROTON-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved PROTON-276. -- Resolution: Fixed Fix Version/s: 0.5 looks good Ssl tests fail against proton-j on Windows (tests can't find certificates) -- Key: PROTON-276 URL: https://issues.apache.org/jira/browse/PROTON-276 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.4 Reporter: Keith Wall Assignee: Philip Harvey Priority: Minor Fix For: 0.5 Running mvn test on Windows I see all the (Python) ssl tests fail. The error message is: java.lang.RuntimeException: Unable to read PEM object from file __pyclasspath__/proton_tests\ssl_db/ca-certificate.pem -- 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-280) Maven should generate project documentation including markdown docs
[ https://issues.apache.org/jira/browse/PROTON-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved PROTON-280. -- Resolution: Fixed committed in revision 1463950 Maven should generate project documentation including markdown docs --- Key: PROTON-280 URL: https://issues.apache.org/jira/browse/PROTON-280 Project: Qpid Proton Issue Type: Improvement Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Maven can generate a web site from a project. We should configure this to include the markdown documents added recently in docs. -- 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-280) Maven should generate project documentation including markdown docs
[ https://issues.apache.org/jira/browse/PROTON-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-280: - Fix Version/s: 0.5 Maven should generate project documentation including markdown docs --- Key: PROTON-280 URL: https://issues.apache.org/jira/browse/PROTON-280 Project: Qpid Proton Issue Type: Improvement Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Fix For: 0.5 Maven can generate a web site from a project. We should configure this to include the markdown documents added recently in docs. -- 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-284) Add JUnit tests for Engine Connection
[ https://issues.apache.org/jira/browse/PROTON-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13622031#comment-13622031 ] Philip Harvey commented on PROTON-284: -- Committed first cut of these changes in r1464428 Add JUnit tests for Engine Connection - Key: PROTON-284 URL: https://issues.apache.org/jira/browse/PROTON-284 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Philip Harvey Assignee: Philip Harvey Add tests that exercise the Engine's adherence to the Connection-related sections of the AMQP spec. These tests are similar in to the existing Python ones (in tests/python), but have a more direct correspondence to the requirements in the spec. -- 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-293) [proton-hawtdispatch] Use more conservative initial message size estimates.
[ https://issues.apache.org/jira/browse/PROTON-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-293: Assignee: Philip Harvey [proton-hawtdispatch] Use more conservative initial message size estimates. --- Key: PROTON-293 URL: https://issues.apache.org/jira/browse/PROTON-293 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Philip Harvey Attachments: PROTON-293.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] [Resolved] (PROTON-293) [proton-hawtdispatch] Use more conservative initial message size estimates.
[ https://issues.apache.org/jira/browse/PROTON-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved PROTON-293. -- Resolution: Fixed Fix Version/s: 0.4 [proton-hawtdispatch] Use more conservative initial message size estimates. --- Key: PROTON-293 URL: https://issues.apache.org/jira/browse/PROTON-293 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Philip Harvey Fix For: 0.4 Attachments: PROTON-293.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-292) [proton-hawtdispatch] avoid printing debug info to the console.
[ https://issues.apache.org/jira/browse/PROTON-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13631688#comment-13631688 ] Philip Harvey commented on PROTON-292: -- Hiram - would you like me to commit the patch you attached on Friday at 17:36? [proton-hawtdispatch] avoid printing debug info to the console. --- Key: PROTON-292 URL: https://issues.apache.org/jira/browse/PROTON-292 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Philip Harvey Attachments: PROTON-292.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] [Resolved] (PROTON-292) [proton-hawtdispatch] avoid printing debug info to the console.
[ https://issues.apache.org/jira/browse/PROTON-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey resolved PROTON-292. -- Resolution: Fixed Fix Version/s: 0.4 [proton-hawtdispatch] avoid printing debug info to the console. --- Key: PROTON-292 URL: https://issues.apache.org/jira/browse/PROTON-292 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Philip Harvey Fix For: 0.4 Attachments: PROTON-292.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] [Created] (PROTON-307) Remove redundant input and output methods from Sasl interface
Philip Harvey created PROTON-307: Summary: Remove redundant input and output methods from Sasl interface Key: PROTON-307 URL: https://issues.apache.org/jira/browse/PROTON-307 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Philip Harvey Assignee: Philip Harvey The Sasl interface exposes input and output methods which duplicate those offered by Transport. Furthermore, use of these methods may be harmful because, for example, if a Transport has been set up to use both SSL and SASL, directly calling Sasl.input undermines the layering of SSL/SASL/AMQP transports that Transport is meant to oversee. -- 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] [Reopened] (PROTON-295) recv(-1) + incoming_window == bad
[ https://issues.apache.org/jira/browse/PROTON-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reopened PROTON-295: -- proton-j test is now failing: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/334/ recv(-1) + incoming_window == bad - Key: PROTON-295 URL: https://issues.apache.org/jira/browse/PROTON-295 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: michael goulish Assignee: Rafael H. Schloming Fix For: 0.5 Use of recv(-1) could receive enough messages that some would exceed the incoming window size and be automatically accepted -- with app logic never getting a say in the matter. -- 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-315) proton-j Messenger testIncomingQueueBiggerThanWindow failing
[ https://issues.apache.org/jira/browse/PROTON-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659358#comment-13659358 ] Philip Harvey commented on PROTON-315: -- commented out the failing test in r1483244 proton-j Messenger testIncomingQueueBiggerThanWindow failing Key: PROTON-315 URL: https://issues.apache.org/jira/browse/PROTON-315 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Philip Harvey Assignee: Rafael H. Schloming This test has been failing since the changes for PROTON-295 were committed. https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/338/#showFailuresLink -- 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-315) proton-j Messenger testIncomingQueueBiggerThanWindow failing
[ https://issues.apache.org/jira/browse/PROTON-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665017#comment-13665017 ] Philip Harvey commented on PROTON-315: -- The failing test is now Skipped iff using proton-j. See r1485619. proton-j Messenger testIncomingQueueBiggerThanWindow failing Key: PROTON-315 URL: https://issues.apache.org/jira/browse/PROTON-315 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Philip Harvey Assignee: Rafael H. Schloming This test has been failing since the changes for PROTON-295 were committed. https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/338/#showFailuresLink -- 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-326) proton-c ServerTest.testIdleTimeout sometimes fails, causing test suite to hang forever
[
https://issues.apache.org/jira/browse/PROTON-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13676849#comment-13676849
]
Philip Harvey commented on PROTON-326:
--
Note that I would normally have captured a core dump to analyse where the tests
were stuck, but this was on a bare-bones machine without gdb installed :-(
proton-c ServerTest.testIdleTimeout sometimes fails, causing test suite to
hang forever
---
Key: PROTON-326
URL: https://issues.apache.org/jira/browse/PROTON-326
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.4
Environment: Linux
Reporter: Philip Harvey
I ran the python test suite against proton-c today and noticed that
ServerTest.testIdleTimeout failed with the following output:
{noformat}
proton_tests.engine.ServerTest.testIdleTimeout
..ERROR amqp:resource-limit-exceeded
local-idle-timeout expired
fail
Error during test: Traceback (most recent call last):
File ./tests/python/proton-test, line 340, in run
phase()
File /.../workspace/proton/tests/python/proton_tests/engine.py, line
1412, in testIdleTimeout
assert self.conn.state == (Endpoint.LOCAL_ACTIVE |
Endpoint.REMOTE_ACTIVE), Connection terminated
AssertionError: Connection terminated
{noformat}
This test usually succeeds so I guess it contains a race condition.
Something that is arguably more problematic is that this failure causes the
test suite to hang. The suite proceeds to run the other tests, but does not
terminate when it reaches the end. On Linux, I actually had to kill the
process rather than ctrl-c-ing it.
I cannot reproduce the test failure, but I do find that if I make it fail
(for example, by modifying the assert on line 1412 to always fail) then the
suite hangs every time.
It's obviously undesirable for a failing test to cause the entire suite to
hang.
--
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] [Created] (PROTON-327) proton-c: soak.MessengerTests.test_relay_C_SSL sometimes fails
Philip Harvey created PROTON-327: Summary: proton-c: soak.MessengerTests.test_relay_C_SSL sometimes fails Key: PROTON-327 URL: https://issues.apache.org/jira/browse/PROTON-327 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Linux Reporter: Philip Harvey Today I observed the following test failure on my CI server. This is the first time I've seen the test fail. It passed when I re-ran it. Here is the test output: proton_tests.soak.MessengerTests.test_relay_C_SSL (from pythontests) Failing for the past 1 build (Since Failed#122 ) Took 1 min 0 sec. add description Error Message Command '['msgr-send', '-a', 'amqps://0.0.0.0:58694/X0Y,amqps://0.0.0.0:58694/X1Y,amqps://0.0.0.0:58694/X2Y,amqps://0.0.0.0:58694/X3Y,amqps://0.0.0.0:58694/X4Y', '-c', '85', '-R', '-t', '60']' failed Stacktrace Error during test: Traceback (most recent call last): File ./tests/python/proton-test, line 340, in run phase() File /.../proton/tests/python/proton_tests/soak.py, line 310, in test_relay_C_SSL self._do_relay_test(MessengerReceiverC(), MessengerReceiverC(), MessengerSenderC(), amqps) File /.../proton/tests/python/proton_tests/soak.py, line 220, in _do_relay_test self._do_test(iterations) File /.../proton/tests/python/proton_tests/soak.py, line 96, in _do_test assert S.status() == 0, Command '%s' failed % str(S.cmdline()) AssertionError: Command '['msgr-send', '-a', 'amqps://0.0.0.0:58694/X0Y,amqps://0.0.0.0:58694/X1Y,amqps://0.0.0.0:58694/X2Y,amqps://0.0.0.0:58694/X3Y,amqps://0.0.0.0:58694/X4Y', '-c', '85', '-R', '-t', '60']' failed -- 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-343) Add a pluggable Proton logging layer
[ https://issues.apache.org/jira/browse/PROTON-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-343: - Attachment: 0001-PROTON-343-sketched-out-the-Java-parts-of-the-propos.patch Skeleton implementation of a proton-j (operational) logging design, intended to act as a straw man when discussing the design. Add a pluggable Proton logging layer Key: PROTON-343 URL: https://issues.apache.org/jira/browse/PROTON-343 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Philip Harvey Assignee: Philip Harvey Attachments: 0001-PROTON-343-sketched-out-the-Java-parts-of-the-propos.patch Applications that use Proton sometimes want Proton to produce logging. This logging needs to be pluggable - applications should be able to provide their own Proton logging implementation that, for example, uses their preferred logging framework. Proton's log output is considered to be part of its public interface. Therefore, this output should be consistent between proton-c and proton-j. -- 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-343) Add a pluggable Proton logging layer
[ https://issues.apache.org/jira/browse/PROTON-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-343: - Description: Applications that use Proton sometimes want Proton to produce logging. Goals * Proton should provide a default logging implementation. * It should be easy for Proton client code to provide custom logging implementation, e.g. one that uses the same third party logging framework as their application code. * Proton should not have a compile-time dependency on a third party logging framework * Proton's log output is considered to be part of its public interface. Therefore, in the spirit of Proton's cross-language consistency goals, this output should be consistent between proton-c and proton-j. * The goals that general-purpose logging frameworks try to meet - performance, ease of use etc - also apply. was: Applications that use Proton sometimes want Proton to produce logging. This logging needs to be pluggable - applications should be able to provide their own Proton logging implementation that, for example, uses their preferred logging framework. Proton's log output is considered to be part of its public interface. Therefore, this output should be consistent between proton-c and proton-j. Add a pluggable Proton logging layer Key: PROTON-343 URL: https://issues.apache.org/jira/browse/PROTON-343 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Philip Harvey Assignee: Philip Harvey Attachments: 0001-PROTON-343-sketched-out-the-Java-parts-of-the-propos.patch Applications that use Proton sometimes want Proton to produce logging. Goals * Proton should provide a default logging implementation. * It should be easy for Proton client code to provide custom logging implementation, e.g. one that uses the same third party logging framework as their application code. * Proton should not have a compile-time dependency on a third party logging framework * Proton's log output is considered to be part of its public interface. Therefore, in the spirit of Proton's cross-language consistency goals, this output should be consistent between proton-c and proton-j. * The goals that general-purpose logging frameworks try to meet - performance, ease of use etc - also apply. -- 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-343) Add a pluggable Proton logging layer
[
https://issues.apache.org/jira/browse/PROTON-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695403#comment-13695403
]
Philip Harvey commented on PROTON-343:
--
Here are some rough notes about how the code should look that I agreed with
Robbie and Rob. The previously-attached patch will be modified in line with
the notes below.
{code}
//Applications can plug in custom behaviour in several ways:
engineFactory.setEngineLogger(myCustomEngineLogger)
engineFactory.setEngineLogger(new CategoryLoggerWrapper(myCustomEngineLogger))
CategoryLoggerWrapper.setDefaultCategoryLogger(myCustomCategoryLogger)
connection.setEngineLogger(myCustomEngineLogger)
((CategoryLoggerWrapper)connection.getEngineLogger()).setCategoryLogger(myCustomCategoryLogger)
// How the new JMS client will probably do it:
class JMSConnectionImpl
{
CategoryLoggerWrapper.setDefaultCategoryLogger(new Slf4JCategoryLogger());
// defined in Proton
}
// public class defined in proton-api
public class CategoryLoggerWrapper implements EngineLogger, MessengerLogger...
{
private static final JUL_CATEGEORY_LOGGER = new JulCategoryLogger()
private CategoryLogger _categoryLogger = JUL_CATEGEORY_LOGGER // or use
the logged defined in a system property if set
static setDefaultCategoryLogger(logger);
setCategoryLogger(logger)
logFrameReceived(Connection, )
{
_categoryLogger.log(FRAME_CATEGORY, blah blah)
}
logMessengerStuff(...)
}
// used by Python tests
public class RememberingLogger implements EngineLogger
{
... just remembers its invocations so we can assertion correct behaviour of
ConnectionImpl
}
class EngineFactoryImpl
{
public Connection createConnection()
{
conn = return new ConnectionImpl(_engineLogger);
}
}
class SenderImpl
{
...
getEngineLogger().logStuff(getConnection(), )
}
{code}
Add a pluggable Proton logging layer
Key: PROTON-343
URL: https://issues.apache.org/jira/browse/PROTON-343
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c, proton-j
Reporter: Philip Harvey
Assignee: Philip Harvey
Attachments:
0001-PROTON-343-sketched-out-the-Java-parts-of-the-propos.patch
Applications that use Proton sometimes want Proton to produce logging.
Goals
* Proton should provide a default logging implementation.
* It should be easy for Proton client code to provide custom logging
implementation, e.g. one that uses the same third party logging framework as
their application code.
* Proton should not have a compile-time dependency on a third party logging
framework
* Proton's log output is considered to be part of its public interface.
Therefore, in the spirit of Proton's cross-language consistency goals, this
output should be consistent between proton-c and proton-j.
* The goals that general-purpose logging frameworks try to meet -
performance, ease of use etc - also apply.
--
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] [Comment Edited] (PROTON-343) Add a pluggable Proton logging layer
[
https://issues.apache.org/jira/browse/PROTON-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695403#comment-13695403
]
Philip Harvey edited comment on PROTON-343 at 7/1/13 10:50 AM:
---
Here are some rough notes about how the code should look that I agreed with
Robbie and Rob. The previously-attached patch will be modified in line with
the notes below.
{code}
//Applications can plug in custom behaviour in several ways:
engineFactory.setEngineLogger(myCustomEngineLogger)
engineFactory.setEngineLogger(new CategoryLoggerWrapper(myCustomCategoryLogger))
CategoryLoggerWrapper.setDefaultCategoryLogger(myCustomCategoryLogger)
connection.setEngineLogger(myCustomEngineLogger)
((CategoryLoggerWrapper)connection.getEngineLogger()).setCategoryLogger(myCustomCategoryLogger)
// How the new JMS client will probably do it:
class JMSConnectionImpl
{
CategoryLoggerWrapper.setDefaultCategoryLogger(new Slf4JCategoryLogger());
// defined in Proton
}
// public class defined in proton-api
public class CategoryLoggerWrapper implements EngineLogger, MessengerLogger...
{
private static final JUL_CATEGEORY_LOGGER = new JulCategoryLogger()
private CategoryLogger _categoryLogger = JUL_CATEGEORY_LOGGER // or use
the logger defined in a system property if set
static setDefaultCategoryLogger(logger);
setCategoryLogger(logger)
logFrameReceived(Connection, )
{
_categoryLogger.log(FRAME_CATEGORY, blah blah)
}
logMessengerStuff(...)
}
// used by Python tests
public class RememberingLogger implements EngineLogger
{
... just remembers its invocations so we can assertion correct behaviour of
ConnectionImpl
}
class EngineFactoryImpl
{
public Connection createConnection()
{
conn = return new ConnectionImpl(_engineLogger);
}
}
class SenderImpl
{
...
getEngineLogger().logStuff(getConnection(), )
}
{code}
was (Author: philharveyonline):
Here are some rough notes about how the code should look that I agreed with
Robbie and Rob. The previously-attached patch will be modified in line with
the notes below.
{code}
//Applications can plug in custom behaviour in several ways:
engineFactory.setEngineLogger(myCustomEngineLogger)
engineFactory.setEngineLogger(new CategoryLoggerWrapper(myCustomEngineLogger))
CategoryLoggerWrapper.setDefaultCategoryLogger(myCustomCategoryLogger)
connection.setEngineLogger(myCustomEngineLogger)
((CategoryLoggerWrapper)connection.getEngineLogger()).setCategoryLogger(myCustomCategoryLogger)
// How the new JMS client will probably do it:
class JMSConnectionImpl
{
CategoryLoggerWrapper.setDefaultCategoryLogger(new Slf4JCategoryLogger());
// defined in Proton
}
// public class defined in proton-api
public class CategoryLoggerWrapper implements EngineLogger, MessengerLogger...
{
private static final JUL_CATEGEORY_LOGGER = new JulCategoryLogger()
private CategoryLogger _categoryLogger = JUL_CATEGEORY_LOGGER // or use
the logged defined in a system property if set
static setDefaultCategoryLogger(logger);
setCategoryLogger(logger)
logFrameReceived(Connection, )
{
_categoryLogger.log(FRAME_CATEGORY, blah blah)
}
logMessengerStuff(...)
}
// used by Python tests
public class RememberingLogger implements EngineLogger
{
... just remembers its invocations so we can assertion correct behaviour of
ConnectionImpl
}
class EngineFactoryImpl
{
public Connection createConnection()
{
conn = return new ConnectionImpl(_engineLogger);
}
}
class SenderImpl
{
...
getEngineLogger().logStuff(getConnection(), )
}
{code}
Add a pluggable Proton logging layer
Key: PROTON-343
URL: https://issues.apache.org/jira/browse/PROTON-343
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c, proton-j
Reporter: Philip Harvey
Assignee: Philip Harvey
Attachments:
0001-PROTON-343-sketched-out-the-Java-parts-of-the-propos.patch
Applications that use Proton sometimes want Proton to produce logging.
Goals
* Proton should provide a default logging implementation.
* It should be easy for Proton client code to provide custom logging
implementation, e.g. one that uses the same third party logging framework as
their application code.
* Proton should not have a compile-time dependency on a third party logging
framework
* Proton's log output is considered to be part of its public interface.
Therefore, in the spirit of Proton's cross-language consistency goals, this
output should be consistent between proton-c and proton-j.
* The goals that
[jira] [Commented] (PROTON-366) Add a protocol dump utility for java
[ https://issues.apache.org/jira/browse/PROTON-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13720696#comment-13720696 ] Philip Harvey commented on PROTON-366: -- I don't think this patch should be committed without wider review. From a quick check, I notice: - Curly braces should be on new lines as per [https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards] - I doubt we really want to add a compile-time dependency on hawtbuf and hawtdispatch-transport to proton-j (or have I misread the patch?) - We've been very careful about additions to proton's public interface so far, so the addition of a command-line utility in proton-j-impl is something that merits discussion on the proton mailing list. - Instead of cluttering the pom with locations of sample data files used to test the utility, should this should all be inside a JUnit test? Add a protocol dump utility for java Key: PROTON-366 URL: https://issues.apache.org/jira/browse/PROTON-366 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.4 Reporter: Justin Ross Priority: Minor Attachments: QPID-4106.patch This bug was originally under the QPID jira instance. -- 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-370) test proton-hawtdispatch
[ https://issues.apache.org/jira/browse/PROTON-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-370: - Attachment: PROTON-370-logging-and-whitespace.tar Attached revised path which resolves problems with: - trailing whitespace - excessive logging to System.err (replaced with Logger.fine) The test still prints a stack trace to stderr, which needs to resolved before I can commit this code because it clutters the test output. test proton-hawtdispatch Key: PROTON-370 URL: https://issues.apache.org/jira/browse/PROTON-370 Project: Qpid Proton Issue Type: Test Components: proton-j Reporter: Bozo Dragojevic Assignee: Philip Harvey Attachments: 0001-Add-java-implementation-of-Messenger-server-similar-.patch, 0002-simple-test-of-sending-and-receiving-a-message-with-.patch, PROTON-370-logging-and-whitespace.tar First test for proton-hawtdispatch. For now I've made a java equivalent of python test messenger server and a rough test to use proton-hawtdispatch as a client -- 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-343) Add a pluggable Proton logging layer
[ https://issues.apache.org/jira/browse/PROTON-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730711#comment-13730711 ] Philip Harvey commented on PROTON-343: -- As of now, most of the logging framework code has been implemented but is not yet being used. Here is my list of what needs to be done to achieve this: * Implement the main methods we need on EngineLogger. These are currently: ** sentFrame ** receivedFrame ** sentBytes ** receivedBytes (replacing java.util.Logger in FrameParser) ** possibly from SASL-related state information, e.g. saslOutcome(outcome) ** possibly from SSL-related state information, e.g. sslDetected(true) * Add a new Frame interface to proton-api for use by EngineLogger.sendFrame * Replace uses of ProtocolTracer with EngineLogger. These are currently : ** _protocolTracer.sentFrame(TransportFrame) in FrameWriter ** _protocolTracer.receivedFrame(TransportFrame) in TransportImpl * Implement one or more DriverLogger onError() (or similar) methods to replace the existing use of java.util.logging Add a pluggable Proton logging layer Key: PROTON-343 URL: https://issues.apache.org/jira/browse/PROTON-343 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Philip Harvey Assignee: Philip Harvey Attachments: 0001-PROTON-343-sketched-out-the-Java-parts-of-the-propos.patch Applications that use Proton sometimes want Proton to produce logging. Goals * Proton should provide a default logging implementation. * It should be easy for Proton client code to provide custom logging implementation, e.g. one that uses the same third party logging framework as their application code. * Proton should not have a compile-time dependency on a third party logging framework * Proton's log output is considered to be part of its public interface. Therefore, in the spirit of Proton's cross-language consistency goals, this output should be consistent between proton-c and proton-j. * The goals that general-purpose logging frameworks try to meet - performance, ease of use etc - also apply. -- 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-270) Make artifactId for proton tests more descriptive
[ https://issues.apache.org/jira/browse/PROTON-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-270: Assignee: Philip Harvey Make artifactId for proton tests more descriptive - Key: PROTON-270 URL: https://issues.apache.org/jira/browse/PROTON-270 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.4 Reporter: Keith Wall Assignee: Philip Harvey Fix For: 0.5 As raised by Robbie on the proton list (http://mail-archives.apache.org/mod_mbox/qpid-proton/201303.mbox/%3ccafitrptig+tzl-tsvjop1qdtu74mxwzqxg_lwlysdnfv9sq...@mail.gmail.com%3e) Hi all, I just noticed the maven artifactId for the proton tests for 0.4: dependency groupIdorg.apache.qpid/groupId artifactIdtests/artifactId version0.4/version /dependency Can we add 'proton' to that Id for consistency with all the other artifacts, and perhaps also help clue users in on what they actually are? -- 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
