Re: problems with master after sasl changes
On 04/21/2015 12:52 PM, Rafael Schloming wrote: I'm seeing a couple of issues with the recently landed sasl changes. I'm getting four test failures in the python tests (see details at the end). I'm also seeing interop issues with the proton.js built prior to these changes, and with these changes in place the javascript build seems to be messed up (not finding new symbols). Is anyone else seeing similar issues? I can't even get as far as the tests. On a clean build (cyrus-sasl-lib-2.1.23-31 installed) I get: /home/gordon/projects/proton-git/proton-c/src/sasl/cyrus_sasl.c: In function ‘pn_sasl_free’: /home/gordon/projects/proton-git/proton-c/src/sasl/cyrus_sasl.c:656:15: error: implicit declaration of function ‘sasl_client_done’ [-Wimplicit-function-declaration] /home/gordon/projects/proton-git/proton-c/src/sasl/cyrus_sasl.c:658:15: error: implicit declaration of function ‘sasl_server_done’ [-Wimplicit-function-declaration] make[2]: *** [proton-c/CMakeFiles/qpid-proton.dir/src/sasl/cyrus_sasl.c.o] Error 1 If I set the SASL_IMPL in cmake to null (is that how you turn it off), then I get: CMakeFiles/qpid-proton.dir/src/dispatcher/dispatcher.c.o: In function `pni_dispatch_action': /home/gordon/projects/proton-git/proton-c/src/dispatcher/dispatcher.c:67: undefined reference to `pn_do_response' /home/gordon/projects/proton-git/proton-c/src/dispatcher/dispatcher.c:66: undefined reference to `pn_do_challenge' /home/gordon/projects/proton-git/proton-c/src/dispatcher/dispatcher.c:65: undefined reference to `pn_do_init' /home/gordon/projects/proton-git/proton-c/src/dispatcher/dispatcher.c:64: undefined reference to `pn_do_mechanisms' /home/gordon/projects/proton-git/proton-c/src/dispatcher/dispatcher.c:68: undefined reference to `pn_do_outcome' CMakeFiles/qpid-proton.dir/src/transport/transport.c.o: In function `pn_io_layer_setup': /home/gordon/projects/proton-git/proton-c/src/transport/transport.c:199: undefined reference to `sasl_header_layer' CMakeFiles/qpid-proton.dir/src/transport/transport.c.o: In function `pn_transport_finalize': /home/gordon/projects/proton-git/proton-c/src/transport/transport.c:574: undefined reference to `pn_sasl_free' CMakeFiles/qpid-proton.dir/src/transport/transport.c.o: In function `pn_transport_bind': /home/gordon/projects/proton-git/proton-c/src/transport/transport.c:623: undefined reference to `pni_sasl_set_remote_hostname' /home/gordon/projects/proton-git/proton-c/src/transport/transport.c:619: undefined reference to `pn_sasl' /home/gordon/projects/proton-git/proton-c/src/transport/transport.c:620: undefined reference to `pni_sasl_set_user_password' CMakeFiles/qpid-proton.dir/src/transport/transport.c.o: In function `pn_io_layer_input_autodetect': /home/gordon/projects/proton-git/proton-c/src/transport/transport.c:257: undefined reference to `sasl_write_header_layer' /home/gordon/projects/proton-git/proton-c/src/transport/transport.c:255: undefined reference to `pn_sasl' CMakeFiles/qpid-proton.dir/src/transport/transport.c.o: In function `pn_transport_get_user': /home/gordon/projects/proton-git/proton-c/src/transport/transport.c:520: undefined reference to `pn_sasl_get_user' collect2: error: ld returned 1 exit status
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507185#comment-14507185 ] ASF subversion and git services commented on PROTON-490: Commit a977f933d91e08bbc321a4d7f9fd3bdb8dade63e in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a977f93 ] PROTON-490: Revert PROTON-490: futurize proton-c/bindings This reverts commit 81085e348ce15c088a82a117e4892c760a57b9fe. [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507184#comment-14507184 ] ASF subversion and git services commented on PROTON-490: Commit a977f933d91e08bbc321a4d7f9fd3bdb8dade63e in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a977f93 ] PROTON-490: Revert PROTON-490: futurize proton-c/bindings This reverts commit 81085e348ce15c088a82a117e4892c760a57b9fe. [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507066#comment-14507066 ] ASF subversion and git services commented on PROTON-490: Commit a977f933d91e08bbc321a4d7f9fd3bdb8dade63e in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a977f93 ] PROTON-490: Revert PROTON-490: futurize proton-c/bindings This reverts commit 81085e348ce15c088a82a117e4892c760a57b9fe. [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507065#comment-14507065 ] ASF subversion and git services commented on PROTON-490: Commit a977f933d91e08bbc321a4d7f9fd3bdb8dade63e in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a977f93 ] PROTON-490: Revert PROTON-490: futurize proton-c/bindings This reverts commit 81085e348ce15c088a82a117e4892c760a57b9fe. [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-848-and-849: stop leaking the tra...
Github user rhs commented on the pull request: https://github.com/apache/qpid-proton/pull/20#issuecomment-95188769 Looks good to me. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-848) [proton-j] TransportSession state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507124#comment-14507124 ] ASF GitHub Bot commented on PROTON-848: --- Github user rhs commented on the pull request: https://github.com/apache/qpid-proton/pull/20#issuecomment-95188769 Looks good to me. [proton-j] TransportSession state is never discarded Key: PROTON-848 URL: https://issues.apache.org/jira/browse/PROTON-848 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 TransportImpl keeps a _transportSessionState map of SessionImpl - TransportSession objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507207#comment-14507207 ] ASF subversion and git services commented on PROTON-490: Commit 677729af4f4eea3076bfe493ad217b65aa125178 in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=677729a ] PROTON-490: futurize proton-c [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507209#comment-14507209 ] ASF subversion and git services commented on PROTON-490: Commit 979471f5ee355b3eca43f8cf176ebc7e241ab603 in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=979471f ] PROTON-490: futurize the python code under the test directory [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507210#comment-14507210 ] ASF subversion and git services commented on PROTON-490: Commit 5d7a458635eb55167e33875e040b8147230c4c1b in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5d7a458 ] PROTON-490: port mllib document parser to Python 3 Ported from the original patch supplied by Mickael Maison. Uses the six compatibility library. [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507208#comment-14507208 ] ASF subversion and git services commented on PROTON-490: Commit aae1d20a42dcaded08b8daec4cf43bd5e1fde970 in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=aae1d20 ] PROTON-490: futurize examples [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507212#comment-14507212 ] ASF subversion and git services commented on PROTON-490: Commit e87a6d313ecf2f468852de83126b1fdd7924b737 in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e87a6d3 ] PROTON-490: port mllib document parser to Python 3 [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-859) cyrus sasl not compatible with pre 2.1.24 versions
Gordon Sim created PROTON-859: - Summary: cyrus sasl not compatible with pre 2.1.24 versions Key: PROTON-859 URL: https://issues.apache.org/jira/browse/PROTON-859 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Gordon Sim Assignee: Andrew Stitcher sasl_client_done/sasl_server_done are not available (sasl_done is) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-850) inconsistent state when reusing link name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507479#comment-14507479 ] ASF subversion and git services commented on PROTON-850: Commit fd26ec66bcd1fda328ceca119efc43bf787e0bcf in qpid-proton's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=fd26ec6 ] PROTON-850: ensure attach updates correct link object inconsistent state when reusing link name - Key: PROTON-850 URL: https://issues.apache.org/jira/browse/PROTON-850 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.9 Reporter: Gordon Sim Attachments: PROTON_850.py If a link is closed, and a new link with the same name is created and opened, the attach received for the second link from the peer is applied to the old link. If the old link is freed after being closed, this is avoided, but I'm not sure that is possible via e.g. the python bindings. The root of the problem I think is that a handle is reused after the link is closed, whether freed or not, but when processing an incoming attach, it is the link name that is used to find the appropriate link, which iterates through all links until it matches one by name, which in this case is the old, closed link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-850) inconsistent state when reusing link name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-850. --- Resolution: Fixed Fix Version/s: 0.10 Assignee: Gordon Sim inconsistent state when reusing link name - Key: PROTON-850 URL: https://issues.apache.org/jira/browse/PROTON-850 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.9 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 Attachments: PROTON_850.py If a link is closed, and a new link with the same name is created and opened, the attach received for the second link from the peer is applied to the old link. If the old link is freed after being closed, this is avoided, but I'm not sure that is possible via e.g. the python bindings. The root of the problem I think is that a handle is reused after the link is closed, whether freed or not, but when processing an incoming attach, it is the link name that is used to find the appropriate link, which iterates through all links until it matches one by name, which in this case is the old, closed link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-853: stop erroneous attach being ...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/21 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new link attach for a link in the process of being detached
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507618#comment-14507618 ] ASF subversion and git services commented on PROTON-853: Commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=252f5f0 ] PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850) [proton-j] the transport emitted a new link attach for a link in the process of being detached -- Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-154) proton-j: link attach, detach, attach sequence on single session does not result in a new link for the 2nd attach
[
https://issues.apache.org/jira/browse/PROTON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507616#comment-14507616
]
ASF subversion and git services commented on PROTON-154:
Commit d2262bb7e2ead5b12ed2d4baf94cca6f06e0146c in qpid-proton's branch
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d2262bb ]
PROTON-853: revert the change from PROTON-154, including the test since it
doesnt actually fail without the change.
This reverts commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5.
proton-j: link attach, detach, attach sequence on single session does not
result in a new link for the 2nd attach
-
Key: PROTON-154
URL: https://issues.apache.org/jira/browse/PROTON-154
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, proton-j
Reporter: Hiram Chirino
Assignee: Dominic Evans
Fix For: 0.9
Attachments: PROTON-154-test.patch, PROTON-154.patch
Protocol trace:
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | SENT: Attach{name='topic', handle=1, role=SENDER,
sndSettleMode=2, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, 2target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | RECV: Flow{nextIncomingId=1, incomingWindow=2048,
nextOutgoingId=0, outgoingWindow=2048, handle=1, deliveryCount=0,
linkCredit=100, available=null, drain=false, echo=false, properties=null}
tcp://127.0.0.1:58348 | RECV: Detach{handle=1, closed=true, error=null}
tcp://127.0.0.1:58348 | SENT: Detach{handle=1, closed=false, error=null}
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0, source=null,
target=Target{address='644cf32c-d6c7-45eb-a8b7-3018d4c9594e', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
no link is produced on the second attach when you call:
protonConnection.linkHead(UNINITIALIZED_SET, INITIALIZED_SET);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-857) reduce memory usage for the TransportSession link handle tracking
[ https://issues.apache.org/jira/browse/PROTON-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507624#comment-14507624 ] ASF subversion and git services commented on PROTON-857: Commit 74e16dfe00f21621e8dbc27cea41ae12ad9a66c7 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=74e16df ] PROTON-857: use maps to track handle usage, avoid pre-allocating large arrays we typically wont utilise fully Also reduces handle-max to 65535, giving 65536 usable handles like proton-c currently has. reduce memory usage for the TransportSession link handle tracking - Key: PROTON-857 URL: https://issues.apache.org/jira/browse/PROTON-857 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.10 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 Attachments: 0001-PROTON-857-use-maps-to-track-handle-usage-avoid-pre-.patch The TransportSession class currently maintains two 'maps' of [local|remote] handle-TransportLink using arrays of size handle-max + 1 (since we start from 0 when using handles, just like array indexes). The handle-max value used to be 1024 in proton-j but was recently changed to be 65536 in PROTON-844, allowing us to track 65537 handles. This change exposes the transports already somewhat inefficient storage of handles by requiring ~64x as much memory per open session, which in most cases wont use the extra capacity and indeed may often only need to use a single handle at a time (or worse, none, if a session isnt actually used for some weird reason). The handle tracking should be updated to use a HashMap, in similar fashion to how the session channel numbers are tracked by the transport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new link attach for a link in the process of being detached
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507622#comment-14507622 ] ASF subversion and git services commented on PROTON-853: Commit f2d7d669155a2ca57606c9381f4f1720739be79b in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f2d7d66 ] PROTON-853: dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850. This closes #21 [proton-j] the transport emitted a new link attach for a link in the process of being detached -- Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-848) [proton-j] TransportSession state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-848. --- Resolution: Fixed [proton-j] TransportSession state is never discarded Key: PROTON-848 URL: https://issues.apache.org/jira/browse/PROTON-848 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 TransportImpl keeps a _transportSessionState map of SessionImpl - TransportSession objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-853) [proton-j] the transport emitted a new link attach for a link in the process of being detached
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-853: -- Fix Version/s: 0.10 [proton-j] the transport emitted a new link attach for a link in the process of being detached -- Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-857) reduce memory usage for the TransportSession link handle tracking
[ https://issues.apache.org/jira/browse/PROTON-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-857. --- Resolution: Fixed reduce memory usage for the TransportSession link handle tracking - Key: PROTON-857 URL: https://issues.apache.org/jira/browse/PROTON-857 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.10 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 Attachments: 0001-PROTON-857-use-maps-to-track-handle-usage-avoid-pre-.patch The TransportSession class currently maintains two 'maps' of [local|remote] handle-TransportLink using arrays of size handle-max + 1 (since we start from 0 when using handles, just like array indexes). The handle-max value used to be 1024 in proton-j but was recently changed to be 65536 in PROTON-844, allowing us to track 65537 handles. This change exposes the transports already somewhat inefficient storage of handles by requiring ~64x as much memory per open session, which in most cases wont use the extra capacity and indeed may often only need to use a single handle at a time (or worse, none, if a session isnt actually used for some weird reason). The handle tracking should be updated to use a HashMap, in similar fashion to how the session channel numbers are tracked by the transport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-853) [proton-j] the transport emitted a new link attach for a link in the process of being detached
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned PROTON-853: - Assignee: Robbie Gemmell [proton-j] the transport emitted a new link attach for a link in the process of being detached -- Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: problems with master after sasl changes
On 04/22/2015 05:42 PM, Gordon Sim wrote: On 04/21/2015 12:52 PM, Rafael Schloming wrote: I'm seeing a couple of issues with the recently landed sasl changes. I'm getting four test failures in the python tests (see details at the end). I'm also seeing interop issues with the proton.js built prior to these changes, and with these changes in place the javascript build seems to be messed up (not finding new symbols). Is anyone else seeing similar issues? I can't even get as far as the tests. On a clean build (cyrus-sasl-lib-2.1.23-31 installed) I get: /home/gordon/projects/proton-git/proton-c/src/sasl/cyrus_sasl.c: In function ‘pn_sasl_free’: /home/gordon/projects/proton-git/proton-c/src/sasl/cyrus_sasl.c:656:15: error: implicit declaration of function ‘sasl_client_done’ [-Wimplicit-function-declaration] /home/gordon/projects/proton-git/proton-c/src/sasl/cyrus_sasl.c:658:15: error: implicit declaration of function ‘sasl_server_done’ [-Wimplicit-function-declaration] make[2]: *** [proton-c/CMakeFiles/qpid-proton.dir/src/sasl/cyrus_sasl.c.o] Error 1 This is a cyrus version issue, see https://issues.apache.org/jira/browse/PROTON-859 If I set the SASL_IMPL in cmake to null (is that how you turn it off), then I get: I got past this with a completely fresh build directory.
[jira] [Commented] (PROTON-849) [proton-j] TransportLink state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507614#comment-14507614 ] ASF subversion and git services commented on PROTON-849: Commit f7e7ddde81cfbe02d1c24cf02df0e9a663c8dbc1 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f7e7ddd ] PROTON-848, PROTON-849: dont store the TransportSession or TransportLink state in maps, use the references set on the associated Session and Link objects. Update channel+link reference handling to behave more like proton-c in order to resolve the resulting test failures. This closes #20 [proton-j] TransportLink state is never discarded - Key: PROTON-849 URL: https://issues.apache.org/jira/browse/PROTON-849 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 TransportImpl keeps a _transportLinkStatemap of LinkImpl - TransportLink objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-848) [proton-j] TransportSession state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507613#comment-14507613 ] ASF subversion and git services commented on PROTON-848: Commit f7e7ddde81cfbe02d1c24cf02df0e9a663c8dbc1 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f7e7ddd ] PROTON-848, PROTON-849: dont store the TransportSession or TransportLink state in maps, use the references set on the associated Session and Link objects. Update channel+link reference handling to behave more like proton-c in order to resolve the resulting test failures. This closes #20 [proton-j] TransportSession state is never discarded Key: PROTON-848 URL: https://issues.apache.org/jira/browse/PROTON-848 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 TransportImpl keeps a _transportSessionState map of SessionImpl - TransportSession objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new link attach for a link in the process of being detached
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507617#comment-14507617 ] ASF GitHub Bot commented on PROTON-853: --- Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/21 [proton-j] the transport emitted a new link attach for a link in the process of being detached -- Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-850) inconsistent state when reusing link name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507623#comment-14507623 ] ASF subversion and git services commented on PROTON-850: Commit f2d7d669155a2ca57606c9381f4f1720739be79b in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f2d7d66 ] PROTON-853: dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850. This closes #21 inconsistent state when reusing link name - Key: PROTON-850 URL: https://issues.apache.org/jira/browse/PROTON-850 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.9 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 Attachments: PROTON_850.py If a link is closed, and a new link with the same name is created and opened, the attach received for the second link from the peer is applied to the old link. If the old link is freed after being closed, this is avoided, but I'm not sure that is possible via e.g. the python bindings. The root of the problem I think is that a handle is reused after the link is closed, whether freed or not, but when processing an incoming attach, it is the link name that is used to find the appropriate link, which iterates through all links until it matches one by name, which in this case is the old, closed link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-848) [proton-j] TransportSession state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507619#comment-14507619 ] ASF GitHub Bot commented on PROTON-848: --- Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/20 [proton-j] TransportSession state is never discarded Key: PROTON-848 URL: https://issues.apache.org/jira/browse/PROTON-848 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 TransportImpl keeps a _transportSessionState map of SessionImpl - TransportSession objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new link attach for a link in the process of being detached
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507615#comment-14507615 ] ASF subversion and git services commented on PROTON-853: Commit d2262bb7e2ead5b12ed2d4baf94cca6f06e0146c in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d2262bb ] PROTON-853: revert the change from PROTON-154, including the test since it doesnt actually fail without the change. This reverts commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5. [proton-j] the transport emitted a new link attach for a link in the process of being detached -- Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-154) proton-j: link attach, detach, attach sequence on single session does not result in a new link for the 2nd attach
[
https://issues.apache.org/jira/browse/PROTON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507620#comment-14507620
]
ASF subversion and git services commented on PROTON-154:
Commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab in qpid-proton's branch
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=252f5f0 ]
PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850)
proton-j: link attach, detach, attach sequence on single session does not
result in a new link for the 2nd attach
-
Key: PROTON-154
URL: https://issues.apache.org/jira/browse/PROTON-154
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, proton-j
Reporter: Hiram Chirino
Assignee: Dominic Evans
Fix For: 0.9
Attachments: PROTON-154-test.patch, PROTON-154.patch
Protocol trace:
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | SENT: Attach{name='topic', handle=1, role=SENDER,
sndSettleMode=2, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, 2target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | RECV: Flow{nextIncomingId=1, incomingWindow=2048,
nextOutgoingId=0, outgoingWindow=2048, handle=1, deliveryCount=0,
linkCredit=100, available=null, drain=false, echo=false, properties=null}
tcp://127.0.0.1:58348 | RECV: Detach{handle=1, closed=true, error=null}
tcp://127.0.0.1:58348 | SENT: Detach{handle=1, closed=false, error=null}
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0, source=null,
target=Target{address='644cf32c-d6c7-45eb-a8b7-3018d4c9594e', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
no link is produced on the second attach when you call:
protonConnection.linkHead(UNINITIALIZED_SET, INITIALIZED_SET);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-850) inconsistent state when reusing link name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507621#comment-14507621 ] ASF subversion and git services commented on PROTON-850: Commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=252f5f0 ] PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850) inconsistent state when reusing link name - Key: PROTON-850 URL: https://issues.apache.org/jira/browse/PROTON-850 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.9 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 Attachments: PROTON_850.py If a link is closed, and a new link with the same name is created and opened, the attach received for the second link from the peer is applied to the old link. If the old link is freed after being closed, this is avoided, but I'm not sure that is possible via e.g. the python bindings. The root of the problem I think is that a handle is reused after the link is closed, whether freed or not, but when processing an incoming attach, it is the link name that is used to find the appropriate link, which iterates through all links until it matches one by name, which in this case is the old, closed link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-848-and-849: stop leaking the tra...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/20 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [RFC] Strategy for porting Proton to Python 3
Update: I'm going to change the development strategy a bit here. Turns out the first patch for PROTON-490 doesn't work for older versions of python - 2.5 specifically. I've reverted this change for the time being. Instead of introducing this piecemeal on trunk, I'd rather develop it on a branch. By doing this we'll get a complete understanding of the impact of this work - including the feasibility of supporting older versions of python - without disrupting trunk. I've created a kgiusti-python3 branch for this work FWIW: the six compatibility library claims to only support Python 2.5+. That's as far back as any of the compatibility tools I've looked at go - none claim to support 2.4 or previous. That's probably due to the fact that a majority of the py3 features that replace deprecated 2.x elements where only backported as far as 2.5. Pre-2.5 simply doesn't have alternatives to these deprecated language elements. Once I've got something that works for 2.5+, we can scope the technical debt required to support pre-2.5. -K - Original Message - From: Ken Giusti kgiu...@redhat.com To: proton@qpid.apache.org Sent: Friday, April 17, 2015 9:00:31 AM Subject: Re: [RFC] Strategy for porting Proton to Python 3 - Original Message - From: Robbie Gemmell robbie.gemm...@gmail.com To: proton@qpid.apache.org Sent: Thursday, April 16, 2015 6:28:18 PM Subject: Re: [RFC] Strategy for porting Proton to Python 3 On 16 April 2015 at 23:03, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 16 April 2015 at 20:38, Ken Giusti kgiu...@redhat.com wrote: And within moments, I hit my first Really Big Problem: Jython Yep, turns out Jython can't parse 'futurized' python code. Especially dislikes the except exception, var --- except exception as var change. Which isn't very helpful, since the 'as' variant is the only syntax supported by Python 3 (that comma-syntax has been removed). This makes porting the python unit tests to python3 a no go. The non-test python stuff, like the bindings and examples, are not run under jython so it's not a problem there. So what to do? Here's a couple of options that I can think of: 1) don't port the tests to python 3. 2) create two copies of the python tests, one 'old' copy for running under jython, and a new copy for running under python2 and 3. Remove the old tests once jython can handle the modern syntax. 3) Stop running jython tests 4) A better idea I haven't thought of yet. I'm pretty much against option 1 - we need to be able to test the bindings under python 3. I'm open to the others, especially #4. Opinions? -K We are using jython 2.5.3, which is the current 'final' release, Ugh - these python2-python3 wrapper modules (like six and future) only work with 2.6+ - at least according to their docs. We'll see how far I can go with those wrappers jython. /me remembers answering Yes I do! when interviewing for this position and being asked Do you enjoy a challenge? Damn... however on checking the site there have been a couple of RCs for 2.7 in the last month that suggest it might actually be nearing completion (it has been baking slowly for a couple of years since an initial beta), so perhaps we could look to upgrade to bring support for 'as'. I just tried it out for giggles. I cleared out my checkout, flipped the version to 2.7-rc2, ran the build, and went to get a drink while the ~3x sized jar downloaded. I returned to 211 test failures, seemingly from lots of TypeError: Type not compatible with array type, so there is possibly a little bit of work needed to make such a switch. Some of them passed at least :) I also noticed that Jython 2.7 requires Java 7, so the tests would no longer work on Java 6 if we used it. I'm fine with dropping support for it entirely, but would dislike leaving the compiler target set for Java 6 (as it is now) if we cant actually run the tests on it. - Original Message - From: Ken Giusti kgiu...@redhat.com To: proton@qpid.apache.org Cc: Dominic Evans dominic.ev...@uk.ibm.com Sent: Thursday, April 16, 2015 9:54:35 AM Subject: [RFC] Strategy for porting Proton to Python 3 Hi all, I'm building on the work done by Dominic and Mickael to get all the proton python bits to work under both python2 and python3. See [1]. I think this will entail a lot of little changes to the python sources and the unit tests. Rather than check in a single huge patch, I'm going to break it up over several patches. The first bunch of patches will simply 'modernize' the existing python code. Old style syntax that is not forward compatible with python 3 will be replaced (eg. print foo -- print(foo), etc). I'll use a tool called 'futurize'
[jira] [Created] (PROTON-857) reduce memory usage for the TransportSession link handle tracking
Robbie Gemmell created PROTON-857: - Summary: reduce memory usage for the TransportSession link handle tracking Key: PROTON-857 URL: https://issues.apache.org/jira/browse/PROTON-857 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.10 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 The TransportSession class currently maintains two 'maps' of [local|remote] handle-TransportLink using arrays of size handle-max + 1 (since we start from 0 when using handles, just like array indexes). The handle-max value used to be 1024 in proton-j but was recently changed to be 65536 in PROTON-844, allowing us to track 65537 handles. This change exposes the transports already somewhat inefficient storage of handles by requiring ~64x as much memory per open session, which in most cases wont use the extra capacity and indeed may often only need to use a single handle at a time (or worse, none, if a session isnt actually used for some weird reason). The handle tracking should be updated to use a HashMap, in similar fashion to how the session channel numbers are tracked by the transport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-858) unbalanced maps can get corrupted
Gordon Sim created PROTON-858: - Summary: unbalanced maps can get corrupted Key: PROTON-858 URL: https://issues.apache.org/jira/browse/PROTON-858 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Reporter: Gordon Sim Priority: Critical I came across an issue caused by proton's inability to find a delivery for the id specified in a disposition it received, although the delivery with that id did indeed exist. On further analysis, it appears that maps that are not well balanced can get corrupted, such that the lookup function fails, even when the map 'contains' an entry with the required key. When adding an entry whose key maps to the same addressable index in the map as an existing entry, a free entry is taken from the end of the list and linked to that existing entry. However if all the entries outside the addressable range are used - and since addressable = 0.86*capacity, there are actually not that many of those - then a free entry from the addressable range is used for a key that does not map to that index. This can then lead to a situation where the deletion of an entry causes another to become unfindable. (Detailed example: assume capacity is 16, i.e. first 13 entries (indices 0 to 12) are addressable, last three (indices 13, 14 and 15) are not. Add value a with key 1, value b with key 2, value c with key 3. These take the first three addressable entries respectively. Now add items that map to those same addressable indexes, e.g. a2 with key 14, b2 with key 15, c2 with key 16. The three free non-addressable entries at the end are used for these i.e. indices 15, 14 and 13 respectively, and they are linked to the first three entries (at indices 1, 2 and 3 respectively). Now add d with key 4, which takes the 4th addressable index, then add d2 with key 17, which maps to the same addressable index. We take the next free entry which is at index 12 - *inside* the addressable range - set the key to 10, value to d2 and link it to the entry at index 4. Now delete key 17, which is at index 15. Then add value n with key 12. Index 12 is already taken by d2, so we use the newly vacated entry at index15 and link that to the end of d2 at index 12. Now we delete key 20 at index 12. Its the middle link in a chain of three so we join the previous entry - d at index 4 to the next entry n at index 15. Now you can't find n by its key 12). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-848) [proton-j] TransportSession state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-848: -- Fix Version/s: 0.10 [proton-j] TransportSession state is never discarded Key: PROTON-848 URL: https://issues.apache.org/jira/browse/PROTON-848 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Priority: Critical Fix For: 0.10 TransportImpl keeps a _transportSessionState map of SessionImpl - TransportSession objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-849) [proton-j] TransportLink state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned PROTON-849: - Assignee: Robbie Gemmell [proton-j] TransportLink state is never discarded - Key: PROTON-849 URL: https://issues.apache.org/jira/browse/PROTON-849 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 TransportImpl keeps a _transportLinkStatemap of LinkImpl - TransportLink objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-848) [proton-j] TransportSession state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned PROTON-848: - Assignee: Robbie Gemmell [proton-j] TransportSession state is never discarded Key: PROTON-848 URL: https://issues.apache.org/jira/browse/PROTON-848 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 TransportImpl keeps a _transportSessionState map of SessionImpl - TransportSession objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-849) [proton-j] TransportLink state is never discarded
[ https://issues.apache.org/jira/browse/PROTON-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-849: -- Fix Version/s: 0.10 [proton-j] TransportLink state is never discarded - Key: PROTON-849 URL: https://issues.apache.org/jira/browse/PROTON-849 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 TransportImpl keeps a _transportLinkStatemap of LinkImpl - TransportLink objects. Entries are only ever inserted to this map, meaning they get retained until the transport itself is discarded (I.e until the connection using the transport goes away). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-857) reduce memory usage for the TransportSession link handle tracking
[ https://issues.apache.org/jira/browse/PROTON-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-857: -- Attachment: 0001-PROTON-857-use-maps-to-track-handle-usage-avoid-pre-.patch Attaching a patch with changes. Builds on top of earlier not-yet-committed work from PROTON-848 / PROTON-849. reduce memory usage for the TransportSession link handle tracking - Key: PROTON-857 URL: https://issues.apache.org/jira/browse/PROTON-857 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.10 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 Attachments: 0001-PROTON-857-use-maps-to-track-handle-usage-avoid-pre-.patch The TransportSession class currently maintains two 'maps' of [local|remote] handle-TransportLink using arrays of size handle-max + 1 (since we start from 0 when using handles, just like array indexes). The handle-max value used to be 1024 in proton-j but was recently changed to be 65536 in PROTON-844, allowing us to track 65537 handles. This change exposes the transports already somewhat inefficient storage of handles by requiring ~64x as much memory per open session, which in most cases wont use the extra capacity and indeed may often only need to use a single handle at a time (or worse, none, if a session isnt actually used for some weird reason). The handle tracking should be updated to use a HashMap, in similar fashion to how the session channel numbers are tracked by the transport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PROTON-857) reduce memory usage for the TransportSession link handle tracking
[ https://issues.apache.org/jira/browse/PROTON-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506799#comment-14506799 ] Robbie Gemmell edited comment on PROTON-857 at 4/22/15 10:37 AM: - Attaching a patch with changes. Builds on top of earlier not-yet-committed work from PROTON-848 / PROTON-849. Patch uses maps as mentioned, and also reduces handle-max by 1 to 65535, allowing for 65536 usable handles like proton-c is currently able to utilise. was (Author: gemmellr): Attaching a patch with changes. Builds on top of earlier not-yet-committed work from PROTON-848 / PROTON-849. reduce memory usage for the TransportSession link handle tracking - Key: PROTON-857 URL: https://issues.apache.org/jira/browse/PROTON-857 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.10 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 Attachments: 0001-PROTON-857-use-maps-to-track-handle-usage-avoid-pre-.patch The TransportSession class currently maintains two 'maps' of [local|remote] handle-TransportLink using arrays of size handle-max + 1 (since we start from 0 when using handles, just like array indexes). The handle-max value used to be 1024 in proton-j but was recently changed to be 65536 in PROTON-844, allowing us to track 65537 handles. This change exposes the transports already somewhat inefficient storage of handles by requiring ~64x as much memory per open session, which in most cases wont use the extra capacity and indeed may often only need to use a single handle at a time (or worse, none, if a session isnt actually used for some weird reason). The handle tracking should be updated to use a HashMap, in similar fashion to how the session channel numbers are tracked by the transport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-844) proton-j: ArrayIndexOutOfBounds exception if remote peer sends a handle 1024
[ https://issues.apache.org/jira/browse/PROTON-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506810#comment-14506810 ] Robbie Gemmell commented on PROTON-844: --- Small note that I noticed when working on PROTON-857 that proton-c only looks to be able to cope with a handle-max of 65535 (i.e. 65536 handles), due to its use of method allocate_alias in proton-c/src/transport/transport.c, so I reduced the updated handle-max in proton-j by 1 as part of those changes. proton-j: ArrayIndexOutOfBounds exception if remote peer sends a handle 1024 - Key: PROTON-844 URL: https://issues.apache.org/jira/browse/PROTON-844 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Dominic Evans Fix For: 0.10 If a remote peer attempts to attach with a handle 1024, its advertised handle-max, a proton-j service will hit an ArrayIndexOutOfBoundsException in the call to getLinkFromRemoteHandle Similarly, if a proton-j client attempts to allocate a local handle when all 1024 are used up, it chooses UnsignedInteger.MAX_VALUE rather than throwing an Exception locally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-844) proton-j: ArrayIndexOutOfBounds exception if remote peer sends a handle 1024
[ https://issues.apache.org/jira/browse/PROTON-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-844: -- Fix Version/s: 0.10 proton-j: ArrayIndexOutOfBounds exception if remote peer sends a handle 1024 - Key: PROTON-844 URL: https://issues.apache.org/jira/browse/PROTON-844 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Dominic Evans Fix For: 0.10 If a remote peer attempts to attach with a handle 1024, its advertised handle-max, a proton-j service will hit an ArrayIndexOutOfBoundsException in the call to getLinkFromRemoteHandle Similarly, if a proton-j client attempts to allocate a local handle when all 1024 are used up, it chooses UnsignedInteger.MAX_VALUE rather than throwing an Exception locally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-853: stop erroneous attach being ...
Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/21#issuecomment-95147399 +1 from me, not seen any issues in our FV after applying these commits + PROTON-850 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new link attach for a link in the process of being detached
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506921#comment-14506921 ] ASF GitHub Bot commented on PROTON-853: --- Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/21#issuecomment-95147399 +1 from me, not seen any issues in our FV after applying these commits + PROTON-850 [proton-j] the transport emitted a new link attach for a link in the process of being detached -- Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-858) unbalanced maps can get corrupted
[ https://issues.apache.org/jira/browse/PROTON-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506923#comment-14506923 ] Gordon Sim commented on PROTON-858: --- Note that in example above, size is never greater than 8, so load is at most 0.5 and expansion is never necessary. Note also that although the description says 'unbalanced', it doesn't require a huge imbalance for there to be problems, just an 'unlucky' sequence. unbalanced maps can get corrupted - Key: PROTON-858 URL: https://issues.apache.org/jira/browse/PROTON-858 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Reporter: Gordon Sim Priority: Critical I came across an issue caused by proton's inability to find a delivery for the id specified in a disposition it received, although the delivery with that id did indeed exist. On further analysis, it appears that maps that are not well balanced can get corrupted, such that the lookup function fails, even when the map 'contains' an entry with the required key. When adding an entry whose key maps to the same addressable index in the map as an existing entry, a free entry is taken from the end of the list and linked to that existing entry. However if all the entries outside the addressable range are used - and since addressable = 0.86*capacity, there are actually not that many of those - then a free entry from the addressable range is used for a key that does not map to that index. This can then lead to a situation where the deletion of an entry causes another to become unfindable. (Detailed example: assume capacity is 16, i.e. first 13 entries (indices 0 to 12) are addressable, last three (indices 13, 14 and 15) are not. Add value a with key 1, value b with key 2, value c with key 3. These take the first three addressable entries respectively. Now add items that map to those same addressable indexes, e.g. a2 with key 14, b2 with key 15, c2 with key 16. The three free non-addressable entries at the end are used for these i.e. indices 15, 14 and 13 respectively, and they are linked to the first three entries (at indices 1, 2 and 3 respectively). Now add d with key 4, which takes the 4th addressable index, then add d2 with key 17, which maps to the same addressable index. We take the next free entry which is at index 12 - *inside* the addressable range - set the key to 10, value to d2 and link it to the entry at index 4. Now delete key 17, which is at index 15. Then add value n with key 12. Index 12 is already taken by d2, so we use the newly vacated entry at index15 and link that to the end of d2 at index 12. Now we delete key 20 at index 12. Its the middle link in a chain of three so we join the previous entry - d at index 4 to the next entry n at index 15. Now you can't find n by its key 12). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
