Re: proton-j reactor branch
Excellent. Thanks. In that case, having the other bits available for end of June sounds achievable. Regards - Adrian -Rafael Schloming r...@alum.mit.edu wrote: - To: proton@qpid.apache.org proton@qpid.apache.org From: Rafael Schloming r...@alum.mit.edu Date: 06/15/2015 08:19PM Subject: Re: proton-j reactor branch On Mon, Jun 15, 2015 at 3:07 PM, Adrian Preston prest...@uk.ibm.com wrote: 3) Write Jython shims do the existing Python tests can run against the Proton-J reactor. I have much of this done in my local checkout, I just need to patch it up a bit and push it. --Rafael Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[jira] [Created] (PROTON-881) Proton-j reactor implementation
Adrian Preston created PROTON-881: - Summary: Proton-j reactor implementation Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-877) proton-c sasl client hangs on server pipeline
[ https://issues.apache.org/jira/browse/PROTON-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14531717#comment-14531717 ] Adrian Preston commented on PROTON-877: --- The patch works for me in that I can now get proton-c reactor to proton-j interop working. But it appears to introduce a bunch of valgrind failures in the c tests. Please disregard if the patch is intended as a quick and dirty workaround. Here's the failure output that I'm seeing: 7: Test command: /usr/bin/valgrind --error-exitcode=1 --quiet --leak-check=full --trace-children=yes /home/prestona/proton/qpid-proton/build/proton-c/src/tests/c-refcount-tests 7: Test timeout computed to be: 1500 7/9 Test #7: c-refcount-tests . Passed0.46 sec test 8 Start 8: c-reactor-tests 8: Test command: /usr/bin/valgrind --error-exitcode=1 --quiet --leak-check=full --trace-children=yes /home/prestona/proton/qpid-proton/build/proton-c/src/tests/c-reactor-tests 8: Test timeout computed to be: 1500 8: ==3806== 24 bytes in 1 blocks are possibly lost in loss record 1 of 29 8: ==3806==at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 8: ==3806==by 0x4E4FBCD: pn_error (error.c:37) 8: ==3806==by 0x4E6F1C8: pn_io_initialize (io.c:54) 8: ==3806==by 0x4E4C0F9: pn_class_new (object.c:65) 8: ==3806==by 0x4E65A80: pn_reactor_initialize_cast (reactor.c:69) 8: ==3806==by 0x4E4C0F9: pn_class_new (object.c:65) 8: ==3806==by 0x4E65B65: pn_reactor (reactor.c:107) 8: ==3806==by 0x4017D4: main (reactor.c:278) 8: ==3806== 8: ==3806== 24 bytes in 1 blocks are possibly lost in loss record 2 of 29 8: ==3806==at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 8: ==3806==by 0x4E4FBCD: pn_error (error.c:37) 8: ==3806==by 0x4E6F994: pn_selector_initialize (selector.c:50) 8: ==3806==by 0x4E4C0F9: pn_class_new (object.c:65) 8: ==3806==by 0x4E6F901: pn_io_selector (io.c:301) 8: ==3806==by 0x4E6838F: pn_iodispatch (iohandler.c:65) 8: ==3806==by 0x4E66BCF: pn_handler_dispatch (handler.c:102) 8: ==3806==by 0x4E666FA: pn_reactor_process (reactor.c:402) 8: ==3806==by 0x4E66987: pn_reactor_run (reactor.c:487) 8: ==3806==by 0x401868: main (reactor.c:289) 8: ==3806== 8: ==3806== 32 bytes in 1 blocks are possibly lost in loss record 3 of 29 8: ==3806==at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 8: ==3806==by 0x4E6FB53: pn_selector_add (selector.c:84) 8: ==3806==by 0x4E66BCF: pn_handler_dispatch (handler.c:102) 8: ==3806==by 0x4E666FA: pn_reactor_process (reactor.c:402) 8: ==3806==by 0x4E66987: pn_reactor_run (reactor.c:487) 8: ==3806==by 0x401868: main (reactor.c:289) 8: ==3806== 8: ==3806== 32 bytes in 1 blocks are possibly lost in loss record 4 of 29 8: ==3806==at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 8: ==3806==by 0x4E6FB63: pn_selector_add (selector.c:85) 8: ==3806==by 0x4E66BCF: pn_handler_dispatch (handler.c:102) 8: ==3806==by 0x4E666FA: pn_reactor_process (reactor.c:402) 8: ==3806==by 0x4E66987: pn_reactor_run (reactor.c:487) 8: ==3806==by 0x401868: main (reactor.c:289) 8: ==3806== 8: ==3806== 40 bytes in 1 blocks are possibly lost in loss record 5 of 29 8: ==3806==at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 8: ==3806==by 0x4E4C00C: pn_object_new (object.c:203) 8: ==3806==by 0x4E4C0E8: pn_class_new (object.c:63) 8: ==3806==by 0x4E4E8D1: pn_record (record.c:63) 8: ==3806==by 0x4E65A78: pn_reactor_initialize_cast (reactor.c:68) 8: ==3806==by 0x4E4C0F9: pn_class_new (object.c:65) 8: ==3806==by 0x4E65B65: pn_reactor (reactor.c:107) 8: ==3806==by 0x4017D4: main (reactor.c:278) 8: ==3806== 8: ==3806== 40 bytes in 1 blocks are possibly lost in loss record 6 of 29 8: ==3806==at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 8: ==3806==by 0x4E4C00C: pn_object_new (object.c:203) 8: ==3806==by 0x4E4C0E8: pn_class_new (object.c:63) 8: ==3806==by 0x4E66A90: pn_handler_new (handler.c:59) 8: ==3806==by 0x4E65A92: pn_reactor_initialize_cast (reactor.c:71) 8: ==3806==by 0x4E4C0F9: pn_class_new (object.c:65) 8: ==3806==by 0x4E65B65: pn_reactor (reactor.c:107) 8: ==3806==by 0x4017D4: main (reactor.c:278) 8: ==3806== 8: ==3806== 40 bytes in 1 blocks are possibly lost in loss record 7 of 29 8: ==3806==at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 8: ==3806==by 0x4E4C00C: pn_object_new (object.c:203) 8: ==3806==by 0x4E4C0E8: pn_class_new (object.c:63) 8: ==3806==by 0x4E66A90: pn_handler_new (handler.c:59) 8: ==3806==by 0x4E65A9D: pn_reactor_initialize_cast (reactor.c:72) 8: ==3806==by 0x4E4C0F9: pn_class_new (object.c:65) 8: ==3806==by 0x4E65B65
Re: [jira] [Commented] (PROTON-877) proton-c sasl client hangs on server pipeline
Oh dear. I think I might have confused ASF GitHub Bot. This is a PR relating to PROTON-881, in which I (foolishly) mentioned ROTON-877... Regards - Adrian Adrian Preston, IBM WebSphere MQ Development - Hursley - MQ Light -ASF GitHub Bot (JIRA) j...@apache.org wrote: - To: proton@qpid.apache.org From: ASF GitHub Bot (JIRA) j...@apache.org Date: 05/07/2015 01:41AM Subject: [jira] [Commented] (PROTON-877) proton-c sasl client hangs on server pipeline [ https://issues.apache.org/jira/browse/PROTON-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14531789#comment-14531789 ] ASF GitHub Bot commented on PROTON-877: --- GitHub user prestona opened a pull request: https://github.com/apache/qpid-proton/pull/30 Reactor This is an initial implementation of a proton-j version of the reactor. It comes with samples, unit tests and interoperation tests. It should be good enough to kick the tyres but requires further test cases, code cleanup and Javadoc. For the most part, the code is additive to the proton-j codebase. Currently the interops test requires Rafael's patch, attached to PROTON-877, to complete successfully. You can merge this pull request into a Git repository by running: $ git pull https://github.com/prestona/qpid-proton reactor Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/30.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #30 commit e0187017456a4df58df2f1d04b1941d99eacbe10 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-04-17T13:33:11Z PROTON-881: Initial commit of proton-j reactor implementation commit 739005e7ca49b0e85873406ea4a6b9392252a1fe Author: Adrian Preston prest...@uk.ibm.com Date: 2015-04-17T14:34:53Z PROTON-881: Write an Echo example and get it working commit 88df5e7490183e01dfc8c63d2cfe3123286e604b Author: Adrian Preston prest...@uk.ibm.com Date: 2015-04-17T16:55:27Z PROTON-881: Add a Cat example. commit cd09de66362580f0c5ceab464d71c7ad4300b517 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-04-21T15:23:12Z PROTON-881: Add a Send example, and supporting changes in the reactor. commit 0ac98e76be51fbd890613518541364301b191cc2 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-04-22T20:35:36Z PROTON-881: Add Recv sample and required code changes / additions to the reactor commit b6e18b5a35da5865fe0ae5fd9e161a04170e9750 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-04-29T22:57:47Z PROTON-881: Rough first pass at a proton-j - proton-c interop. test. This adds a Python test case which starts both a Python (proton-c) reactor and also spawns a JVM running a (proton-j) reactor. The expected outcome is that the proton-j reactor is able to send a message to the proton-c reactor. Right now, there are a lot of rough edges on both the Pyton and Java sides of this test case. commit 2e6f5cdd1754b266e81afbc49ae4333a75287d57 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-04-30T12:58:28Z PROTON-881: Tidy up proton-j to proton-c reactor interop tests commit 7faa7e2322c4782b9acc173194dc8bb1887a5a89 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-04-30T13:51:46Z PROTON-881: Only try interoperation tests with proton-j if proton-j has been built! commit 1eb41f603b0a4c5da9c686af1369837e7c6f2184 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-05-01T14:36:00Z PROTON-881: Add reactor interop tests that send messages from proton-c to proton-j commit 51529f675a11f49089e4a50a6bbced3955c26d63 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-05-01T14:55:07Z PROTON-881: Tidy up Selectable to remove bits of a c style record implementation commit 5748bb9880432bab64c42d34f4d7277163077427 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-05-02T21:30:40Z PROTON-881: Add error handling for accept socket connection path through Acceptor Adds error handling for various problems that can occur when accepting a connection (to a listening socket). Also adds unittests that cover these cases. commit e9d4a78d294f08e7eb1bd7a3f28bd3f97ce6b9df Author: Adrian Preston prest...@uk.ibm.com Date: 2015-05-04T20:01:19Z PROTON-881: Add reactor unit tests based on those in proton-c/src/tests/reactor.c commit d6c4ba7bb18d3b8ce02a8dcd52c0f1e569694bb7 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-05-04T20:57:53Z PROTON-881: Add code to release resources (e.g. sockets, selectors, etc.) The proton-j codebase does not, generally, implement cleanup logic in the same way as proton-c (explicit reference counting) and for some resources (such as sockets, selectors, etc.) cannot always way for garbage
Re: Question about pn_reactor and threads.
Hi Alan, I've been playing with the reactor a bit, and one of my early thoughts was: how do you scale this thing across multiple cores? The architecture I've worked with before uses (approximately) one selector + thread pair per core and balances connections across the selectors. Anything non-blocking is done on the selector/thread pair (to avoid context switches and maintain a small working set for each thread). Anything with the potential to block gets dispatched into a thread pool. I /think/ the way you would use the reactor for this kind of architecture is to have one reactor + thread pair per core. That said, I've not tested this hypothesis. If the architecture that you're thinking of always dispatches ready file descriptors into a pool of threads - then I'm _not_ sure that this is something that the reactor (as it currently stands) can easily be slotted into. Regards - Adrian -Alan Conway acon...@redhat.com wrote: - To: proton@qpid.apache.org From: Alan Conway acon...@redhat.com Date: 04/30/2015 07:47PM Subject: Question about pn_reactor and threads. Can the proton reactor be used to deliver work from multiple connections to a thread pool, where work from a given connection is only handled by one thread at a time (so access to each pn_transport and it's stuff is serialized)? That is a pretty standard model for servers. It doesn't look to me like this is the case but I may be missing something. If it is the case, what's the pattern for doing it? Cheers, Alan. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[jira] [Created] (PROTON-869) [proton-c] should be straightforward to associate handlers with acceptors
Adrian Preston created PROTON-869: - Summary: [proton-c] should be straightforward to associate handlers with acceptors Key: PROTON-869 URL: https://issues.apache.org/jira/browse/PROTON-869 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor Currently it is only possible to associate a handler with an acceptor by casting it to pn_selectable_t. This could be broken by a future change to the implementation of pn_acceptor_t. Related: the acceptor implementation does not generate a PN_SELECTABLE_ERROR event if the act of accepting a socket connection fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Error handling in the proton-c reactor (and how it might relate to a Java port)
Thanks Rafael, This is really helpful. I'll have a look through the Python reactor code (kicking myself for not thinking to do this earlier...) and try and get the Java port to handle errors in a similar way. Regards - Adrian On Fri, Apr 24, 2015 at 11:06 PM, Rafael Schloming r...@alum.mit.edu wrote: Hi Adrian, See inline for answers... On Thu, Apr 23, 2015 at 12:17 PM, Adrian Preston prest...@uk.ibm.com wrote: Hello all, While porting the proton-c reactor to Java, I've found a few error paths that I wasn't sure how best to handle. I have some ideas (see below), but if this stuff is already written down somewhere - feel free to suitably admonish me (and then point me towards it...) 1) When an error occurs while the reactor is servicing a connection: the connection is closed with a transport error. This is already implemented by various functions in reactor/connection.c (e.g. pni_handle_bound, to pick one at random), so I expect Java following suit shouldn't be too contentious. Yes 2) When an error occurs while the reactor is accepting a connection: a PN_SELECTABLE_ERROR event is delivered to the acceptor's collector. This might necessitate a new pn_acceptor_attachments function to associate a handler with an acceptor (casting to selectable strikes me as something that might break in the future...). Aside: should it be possible to associate a pn_error (Java Throwable?) with an event, so that it is possible to report the underlying cause for a PN_SELECTABLE_ERROR? A pn_acceptor_attachments function makes sense to me. Regarding your other question. In general I've been trying to stick to having each event reference only a single object, and also reference state in the object model rather than carry state itself, so I might consider adding an accessor to pn_selectable_t to store/extract error information instead of storing it on the event. 3) In the Java reactor it is possible for an unchecked (derived from RuntimeException) exception to be thrown from a handler. Delivering a PN_SELECTABLE_ERROR to the selectable seems like the wrong thing to do (because the handler that threw the exception might not be associated with a selectable, or the exception could be thrown while handling PN_SELECTABLE_ERROR). Logging the exception then swallowing it seems likely to result in situations where the reactor appears to have hung. So the best I've come up with is that the Java equivalent of pn_reactor_process throws an exception - but then I'm not clear what state the reactor should be left in? Permanently failing, by throwing a ReactorBorked exception from any future pn_reactor_process invocation? Also, if this happens should the reactor be responsible for reclaiming the resources used by its children (e.g. closing their sockets)? The python wrapper of the reactor has a similar situation since python code can also throw runtime exceptions. From my experience coding against the API, you definitely want to know sooner rather than later exactly what has gone wrong. It can be easy to miss errors that scroll by in a log, so I would definitely not attempt to continue executing automatically. That said I would try not to leave the reactor in a permanently borked state either since you might want the option to fire events related to shutdown after an error. What I've done in python is roughly the following. I catch and save any exceptions that occur during dispatch of the current event to its handlers. When that event has been dispatched to all handlers, I throw an exception (it's anonymous currently, but it should probably be some sort of DispatchException) from Reactor.process() that references any exceptions that occurred during dispatch of that event. This by default results in the reactor failing fast when an exception occurs, but also leave things in a state where the user can easily log the exception and call process again if they wish to continue. Regarding reclaiming resources, I don't attempt to close sockets or anything like that since for my use cases when the reactor fails the whole process exits. In C this will happen when the reactor is freed, but obviously in python and/or java you would be depending on GC to make that happen and it might not be soon enough, so it may make sense to add a method that would explicitly do that sort of cleanup. --Rafael Regards - Adrian Adrian Preston, IBM WebSphere MQ Development - Hursley - MQ Light -Rafael Schloming r...@alum.mit.edu wrote: - To: proton@qpid.apache.org proton@qpid.apache.org From: Rafael Schloming r...@alum.mit.edu Date: 04/24/2015 11:06AM Subject: Re: Error handling in the proton-c reactor (and how it might relate to a Java port) Hi Adrian, See inline for answers... On Thu, Apr 23, 2015 at 12:17 PM, Adrian Preston prest...@uk.ibm.com wrote: Hello all, While porting the proton-c reactor to Java, I've found
[jira] [Updated] (PROTON-869) [proton-c] should be straightforward to associate handlers with acceptors
[ https://issues.apache.org/jira/browse/PROTON-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Preston updated PROTON-869: -- Attachment: proton-869.patch This patch adds a new pn_acceptor_attachments function, which (indirectly) allows a handler to be associated with a acceptor without casting. It also checks for an invalid socket being returned by the acceptor's call to pn_accept and generates a PN_SELECTABLE_ERROR event. [proton-c] should be straightforward to associate handlers with acceptors - Key: PROTON-869 URL: https://issues.apache.org/jira/browse/PROTON-869 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor Attachments: proton-869.patch Currently it is only possible to associate a handler with an acceptor by casting it to pn_selectable_t. This could be broken by a future change to the implementation of pn_acceptor_t. Related: the acceptor implementation does not generate a PN_SELECTABLE_ERROR event if the act of accepting a socket connection fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Error handling in the proton-c reactor (and how it might relate to a Java port)
Hello all, While porting the proton-c reactor to Java, I've found a few error paths that I wasn't sure how best to handle. I have some ideas (see below), but if this stuff is already written down somewhere - feel free to suitably admonish me (and then point me towards it...) 1) When an error occurs while the reactor is servicing a connection: the connection is closed with a transport error. This is already implemented by various functions in reactor/connection.c (e.g. pni_handle_bound, to pick one at random), so I expect Java following suit shouldn't be too contentious. 2) When an error occurs while the reactor is accepting a connection: a PN_SELECTABLE_ERROR event is delivered to the acceptor's collector. This might necessitate a new pn_acceptor_attachments function to associate a handler with an acceptor (casting to selectable strikes me as something that might break in the future...). Aside: should it be possible to associate a pn_error (Java Throwable?) with an event, so that it is possible to report the underlying cause for a PN_SELECTABLE_ERROR? 3) In the Java reactor it is possible for an unchecked (derived from RuntimeException) exception to be thrown from a handler. Delivering a PN_SELECTABLE_ERROR to the selectable seems like the wrong thing to do (because the handler that threw the exception might not be associated with a selectable, or the exception could be thrown while handling PN_SELECTABLE_ERROR). Logging the exception then swallowing it seems likely to result in situations where the reactor appears to have hung. So the best I've come up with is that the Java equivalent of pn_reactor_process throws an exception - but then I'm not clear what state the reactor should be left in? Permanently failing, by throwing a ReactorBorked exception from any future pn_reactor_process invocation? Also, if this happens should the reactor be responsible for reclaiming the resources used by its children (e.g. closing their sockets)? Thanks, - Adrian Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
proton-j reactor implementation?
Hello all, I've been following the development of the reactor API and think that it looks really neat. Is anyone working on a pure Java version? I'd be interested in helping. Regards - Adrian Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[jira] [Updated] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
[ https://issues.apache.org/jira/browse/PROTON-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Preston updated PROTON-811: -- Attachment: 0001-proton-j-updates-for-idle-timeout-mk4.patch Reworked the patch to fix formatting, remove dependencies on Java 7 features and move the getters / setters for timeouts into Transport.java. I also had some success in enabling additional jython tests - but ran into difficulties with tests.engine.IdleTimeoutTest.testTimeout (which requires pn_transport_get_frames_input to be implemented) and also proton_tests.engine.ServerTest.testIdleTimeout and proton_tests.engine.ServerTest.testKeepalive which both need un-implemented frame counting functions and appear to suffer from some difference between SASL implementations (a bit of digging suggests that the Python wrappers for the SASL object always set SASL client mode when run against the Java shims, and this breaks the TestServer - but my lack of Python expertise stopped me getting any further). [PATCH] proton-j: no way to implement idle timeout of a connection -- Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Adrian Preston Attachments: 0001-idle_timeout.patch, 0001-proton-j-updates-for-idle-timeout-mk3.patch, 0001-proton-j-updates-for-idle-timeout-mk4.patch, 0001-proton-j-updates-for-idle-timeout.patch Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
[ https://issues.apache.org/jira/browse/PROTON-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Preston updated PROTON-811: -- Attachment: 0001-proton-j-updates-for-idle-timeout-mk3.patch Updated patch with an implementation of Transport.tick(long) that is much closer to the proton-c implementation. [PATCH] proton-j: no way to implement idle timeout of a connection -- Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Adrian Preston Attachments: 0001-idle_timeout.patch, 0001-proton-j-updates-for-idle-timeout-mk3.patch, 0001-proton-j-updates-for-idle-timeout.patch Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
[ https://issues.apache.org/jira/browse/PROTON-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14298521#comment-14298521 ] Adrian Preston commented on PROTON-811: --- Once again, thanks for the quick feedback. I should have probably taken a look at the C implementation first, so cheers for pointing me at that. I don't think there is much difference between a timeout or deadline based approach - but since the C code uses deadlines (and got their first), I think that consistency should win. I'll re-work based on the C code. [PATCH] proton-j: no way to implement idle timeout of a connection -- Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Adrian Preston Attachments: 0001-idle_timeout.patch, 0001-proton-j-updates-for-idle-timeout.patch Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
[ https://issues.apache.org/jira/browse/PROTON-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Preston updated PROTON-811: -- Attachment: 0001-idle_timeout.patch Patch attached. [PATCH] proton-j: no way to implement idle timeout of a connection -- Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: perl-binding Affects Versions: 0.8 Reporter: Adrian Preston Attachments: 0001-idle_timeout.patch Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
Adrian Preston created PROTON-811: - Summary: [PATCH] proton-j: no way to implement idle timeout of a connection Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: perl-binding Affects Versions: 0.8 Reporter: Adrian Preston Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
[ https://issues.apache.org/jira/browse/PROTON-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Preston updated PROTON-811: -- Component/s: (was: perl-binding) proton-j [PATCH] proton-j: no way to implement idle timeout of a connection -- Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Adrian Preston Attachments: 0001-idle_timeout.patch Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
[ https://issues.apache.org/jira/browse/PROTON-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14297487#comment-14297487 ] Adrian Preston commented on PROTON-811: --- Hi Rafael, Thanks for the feedback - I'll have a go at reworking the patch, as per your suggestions. [PATCH] proton-j: no way to implement idle timeout of a connection -- Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Adrian Preston Attachments: 0001-idle_timeout.patch Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
