[jira] [Commented] (PROTON-1496) epoll proactor - improved timers implementation with single timerfd kernel resource
[ https://issues.apache.org/jira/browse/PROTON-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245694#comment-17245694 ] ASF GitHub Bot commented on PROTON-1496: cliffjansen commented on pull request #275: URL: https://github.com/apache/qpid-proton/pull/275#issuecomment-740416108 Reworked with naming changes and a single timerfd as suggested. A few TSAN and Coverity fixes too. 9722a7f9d3afadffe1883305aff64bfaf977f596 2ec1ba5026ad821f0f7f6919cd14762f04dcadd2 06833acb10f30343d1e2e970a31e11cb290e32ff d31ad9652a1a63f856ed10772e362b4a155ecbf4 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > epoll proactor - improved timers implementation with single timerfd kernel > resource > --- > > Key: PROTON-1496 > URL: https://issues.apache.org/jira/browse/PROTON-1496 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.0, proton-c-0.32.0 > Environment: Linux environments with epoll support >Reporter: Clifford Jansen >Assignee: Clifford Jansen >Priority: Major > Fix For: proton-c-0.33.0 > > > The epoll proactor allocates a timerfd per connection. This is a convenience > for the initial implementation and may surprise some applications running > into system limits on file descriptors twice as fast as expected. > The timer is used for heartbeats. It should be possible to write a > per-proactor heartbeat timer that is shared among the connections -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1496) epoll proactor - improved timers implementation with single timerfd kernel resource
[ https://issues.apache.org/jira/browse/PROTON-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245692#comment-17245692 ] ASF GitHub Bot commented on PROTON-1496: cliffjansen closed pull request #275: URL: https://github.com/apache/qpid-proton/pull/275 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > epoll proactor - improved timers implementation with single timerfd kernel > resource > --- > > Key: PROTON-1496 > URL: https://issues.apache.org/jira/browse/PROTON-1496 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.0, proton-c-0.32.0 > Environment: Linux environments with epoll support >Reporter: Clifford Jansen >Assignee: Clifford Jansen >Priority: Major > Fix For: proton-c-0.33.0 > > > The epoll proactor allocates a timerfd per connection. This is a convenience > for the initial implementation and may surprise some applications running > into system limits on file descriptors twice as fast as expected. > The timer is used for heartbeats. It should be possible to write a > per-proactor heartbeat timer that is shared among the connections -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] cliffjansen commented on pull request #275: PROTON-1496: epoll proactor - single timer queue and timerfd for all …
cliffjansen commented on pull request #275: URL: https://github.com/apache/qpid-proton/pull/275#issuecomment-740416108 Reworked with naming changes and a single timerfd as suggested. A few TSAN and Coverity fixes too. 9722a7f9d3afadffe1883305aff64bfaf977f596 2ec1ba5026ad821f0f7f6919cd14762f04dcadd2 06833acb10f30343d1e2e970a31e11cb290e32ff d31ad9652a1a63f856ed10772e362b4a155ecbf4 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] cliffjansen closed pull request #275: PROTON-1496: epoll proactor - single timer queue and timerfd for all …
cliffjansen closed pull request #275: URL: https://github.com/apache/qpid-proton/pull/275 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245418#comment-17245418 ] ASF subversion and git services commented on PROTON-2237: - Commit 756d0de77637f3078e28b73fd24979b3e48e179a in qpid-proton's branch refs/heads/master from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=756d0de ] Merge branch 'python-check-property-keys' Closes PR #256 / PROTON-2237 > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245411#comment-17245411 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/master from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245417#comment-17245417 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/master from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245416#comment-17245416 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/master from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245414#comment-17245414 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/master from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245412#comment-17245412 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/master from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245415#comment-17245415 ] ASF GitHub Bot commented on PROTON-2237: asfgit merged pull request #256: URL: https://github.com/apache/qpid-proton/pull/256 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245413#comment-17245413 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/master from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245410#comment-17245410 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/master from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245409#comment-17245409 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/master from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] asfgit merged pull request #256: PROTON-2237: Correct checking of Proton message property keys
asfgit merged pull request #256: URL: https://github.com/apache/qpid-proton/pull/256 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245407#comment-17245407 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/python-check-property-keys from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245408#comment-17245408 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/python-check-property-keys from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245402#comment-17245402 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/python-check-property-keys from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245404#comment-17245404 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/python-check-property-keys from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245406#comment-17245406 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/python-check-property-keys from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245403#comment-17245403 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/python-check-property-keys from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245405#comment-17245405 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/python-check-property-keys from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245401#comment-17245401 ] ASF subversion and git services commented on PROTON-2237: - Commit 66f8696721fab2cc982c05eb7d94572bb2956841 in qpid-proton's branch refs/heads/python-check-property-keys from Kim van der Riet [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=66f8696 ] PROTON-2237: Correct checking of Proton message property keys PROTON-2237: Alternative approach which converts all child classes of string/unicode to the base class, including proton symbol and char types. PROTON-2237: Changed logic of key check so that subclasses of string *except* proton.symbol and proton.char will be encoded as strings PROTON-2237: Added unit tests to check illegal key types are detected and handled, also subclasses of string type keys are converted to type string PROTON-2237: Finalized handling property keys, added tests for these cases. PROTON-2237: Fix for dictionary keys changed during iteration error, deeper test for key conversions PROTON-2237: Final tidy-up of logic and structure, added function doc to explain what is happening. NO-JIRA: Minor code format fix: added space into if stmt. PROTON-2237: Rearrange logic so as to avoid python version check. Minor re-arrange of tests. > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245373#comment-17245373 ] ASF GitHub Bot commented on PROTON-2237: kpvdr opened a new pull request #256: URL: https://github.com/apache/qpid-proton/pull/256 Proposed fix for PROTON-2237. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] kpvdr opened a new pull request #256: PROTON-2237: Correct checking of Proton message property keys
kpvdr opened a new pull request #256: URL: https://github.com/apache/qpid-proton/pull/256 Proposed fix for PROTON-2237. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet resolved PROTON-2237. -- Resolution: Fixed > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245367#comment-17245367 ] ASF GitHub Bot commented on PROTON-2237: kpvdr closed pull request #256: URL: https://github.com/apache/qpid-proton/pull/256 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2237) [python] Non-string message property keys not handled correctly
[ https://issues.apache.org/jira/browse/PROTON-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet reassigned PROTON-2237: Assignee: Kim van der Riet > [python] Non-string message property keys not handled correctly > --- > > Key: PROTON-2237 > URL: https://issues.apache.org/jira/browse/PROTON-2237 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > The AMQP 1.0 spec allows only string keys for message properties. > Proton's Python binding has a method (_message.py:91 _check_property_keys()) > for checking message property keys, but it does not handle all cases > correctly: > # Proton types Symbol and Char are derived from string, and are allowed in > the test. This results in an illegal encoding. > # Because in Python 2, many coders carelessly use string literals without > the required u'' prefix (and thus results in a bytes type), bytes types are > converted to unicode string types. However, the encode() function is being > used, which simply returns a binary type in Python 2 and raises an error in > Python 3. This should probably be the decode() method, which returns a string > and works for both Python 2 and 3. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] kpvdr closed pull request #256: PROTON-2237: Correct checking of Proton message property keys
kpvdr closed pull request #256: URL: https://github.com/apache/qpid-proton/pull/256 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2169) Build fails with ModuleNotFoundError when python3-distutils is missing
[
https://issues.apache.org/jira/browse/PROTON-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245205#comment-17245205
]
ASF GitHub Bot commented on PROTON-2169:
jiridanek commented on pull request #274:
URL: https://github.com/apache/qpid-proton/pull/274#issuecomment-739920203
> As a quick note here, the failure in the checks above was due to known
issue [PROTON-2231](https://issues.apache.org/jira/browse/PROTON-2231) related
to the c threaderciser. The failure should be unrelated to this PR.
The reason I got stuck on the PR is that it is actually quite difficult to
install python (python-devel) without distutils. Its in fact impossible in
ubuntu, due to package dependencies. It looks like doing that is extremely rare
and maybe not worth checking for in CMake...
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Build fails with ModuleNotFoundError when python3-distutils is missing
> --
>
> Key: PROTON-2169
> URL: https://issues.apache.org/jira/browse/PROTON-2169
> Project: Qpid Proton
> Issue Type: Bug
> Components: build
>Affects Versions: proton-c-0.30.0
>Reporter: Jiri Daněk
>Priority: Major
>
> Compile as in PROTON-2145, that means
> {noformat}
> mkdir _build
> cd _build
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
> -DSYSINSTALL_BINDINGS=ON\
> -DBUILD_STATIC_LIBS=ON\
> -DBUILD_TESTING=OFF\
> -DBUILD_WITH_CXX=ON\
> -DENABLE_FUZZ_TESTING=OFF\
> -DFUZZ_REGRESSION_TESTS=OFF
> make -j4
> make install
> {noformat}
> When I don't have {{python3-distutils}} installed, I get
> {noformat}
> -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
> Traceback (most recent call last):
> File "", line 1, in
> ModuleNotFoundError: No module named 'distutils.sysconfig'
> -- Looking for Python module sphinx - not found
> -- Looking for Python module sphinx_automodapi - not found
> -- Sphinx modules not found; doc generation disabled.
> CMake Error at python/CMakeLists.txt:139 (install):
> install FILES given no DESTINATION!
> CMake Error at python/CMakeLists.txt:145 (install):
> install TARGETS given no LIBRARY DESTINATION for module target "_cproton".
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek commented on pull request #274: PROTON-2169 Require distutils to build Python binding
jiridanek commented on pull request #274: URL: https://github.com/apache/qpid-proton/pull/274#issuecomment-739920203 > As a quick note here, the failure in the checks above was due to known issue [PROTON-2231](https://issues.apache.org/jira/browse/PROTON-2231) related to the c threaderciser. The failure should be unrelated to this PR. The reason I got stuck on the PR is that it is actually quite difficult to install python (python-devel) without distutils. Its in fact impossible in ubuntu, due to package dependencies. It looks like doing that is extremely rare and maybe not worth checking for in CMake... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8489) Connection thread looping
[
https://issues.apache.org/jira/browse/QPID-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245112#comment-17245112
]
Daniil Kirilyuk commented on QPID-8489:
---
Added log file
> Connection thread looping
> -
>
> Key: QPID-8489
> URL: https://issues.apache.org/jira/browse/QPID-8489
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.2
>Reporter: Daniil Kirilyuk
>Priority: Minor
> Attachments: QPID-8489.log, simple_recv.cpp, thread-dump.st
>
>
> Error happens quite rarely and is not easy to reproduce. Although the problem
> was partly fixed by fixing QPID-8477, it still can be reproduced. The main
> symptom is significant increase of CPU usage even when no messages are sent
> to broker anymore. CPU usage can rise from 30% to 90% and higher, making
> broker unusable. After such CPU rise the only way to fix broker will be
> restarting it.
> Analysis has shown, that error occurs with CPP proton client in cases when
> 1) SSL connection is used
> 2) connection errors on client side are ignored
> 3) connection is dropped due to the client process termination / network
> disconnection
> *Steps to reproduce*
> # Java broker should be installed
> # Broker should be configured to allow one connection
> # Prepare certificates
> # Install Qpid::Proton 0.28.0
> wget
> [http://archive.apache.org/dist/qpid/proton/0.28.0/qpid-proton-0.28.0.tar.gz]
> gunzip qpid-proton-0.28.0.tar.gz
> mkdir -p qpid-proton-0.28.0/build && pushd qpid-proton-0.28.0/build && cmake
> .. && make all && popd
> # Replace and edit example *qpid-proton-0.28.0/cpp/examples/simple_recv.cpp*
> with the one attached
> # Build again
> cd qpid-proton-0.28.0/build
> make
> # Break the broker
> ./cpp/examples/simple_recv & ./cpp/examples/simple_recv
> Connection error
> {color:#ffab00}^C <= Hit Ctrl+C to kill process{color}
> # {color:#172b4d}If CPU usage didn't increased, find the PID of the first
> simple_recv process using ps-ef | grep simple_recv and kill it using kill -9
> PID.{color}
> *Analysis*
> CPU usage rises when connection is dropped on the client side or when network
> is broken between client and broker. The main point is that client isn't well
> behaved and connection shouldn't be closed correctly.
> On broker side connection becomes "orphaned": it is still maintained by
> broker, but no real reading / writing is performed. Following method calls
> are performed in an endless loop for each "orphaned" connection:
> SelectorThread.performSelect()
> SelectorThread.ConnectionProcessor.processConnection()
> NetworkConnectionScheduler.processConnection()
> NonBlockingConnection.doWork()
> As there nothing physically read or written, both methods
> NonBlockingConnection.doRead() and NonBlockingConnection.doWrite() execute
> very fast (several milliseconds) without any blocking processes and after
> that connection is immediately rescheduled for processing in
> NetworkConnectionScheduler. After that loop repeats.
> As the connection lifecycle is normal, there is logged nothing unusual or
> suspicious (nothing is seen in log at all).
> In thread dump (see attachment) there is seen, that utilized are mostly
> thread with names virtualhost-default-iopool-XX. Typical stacktrace looks
> like following:
> {noformat}
> "virtualhost-default-iopool-39" #92 prio=5 os_prio=0 tid=0x7f47ec335800
> nid=0x37196 waiting on condition
> [0x7f476a4e3000]"virtualhost-default-iopool-39" #92 prio=5 os_prio=0
> tid=0x7f47ec335800 nid=0x37196 waiting on condition [0x7f476a4e3000]
> java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native
> Method) - parking to wait for <0xf39105d0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:532)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory$$Lambda$18/422330142.run(Unknown
> Source) at java.lang.Thread.run(Thread.java:748)}
> {noformat}
> The main symptom of an error is rising CPU usage, which can reach up to 90%
> in case, when several connections are "orphaned". Additional factor leading
> to the problem is disable
[jira] [Updated] (QPID-8489) Connection thread looping
[
https://issues.apache.org/jira/browse/QPID-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniil Kirilyuk updated QPID-8489:
--
Attachment: QPID-8489.log
> Connection thread looping
> -
>
> Key: QPID-8489
> URL: https://issues.apache.org/jira/browse/QPID-8489
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.2
>Reporter: Daniil Kirilyuk
>Priority: Minor
> Attachments: QPID-8489.log, simple_recv.cpp, thread-dump.st
>
>
> Error happens quite rarely and is not easy to reproduce. Although the problem
> was partly fixed by fixing QPID-8477, it still can be reproduced. The main
> symptom is significant increase of CPU usage even when no messages are sent
> to broker anymore. CPU usage can rise from 30% to 90% and higher, making
> broker unusable. After such CPU rise the only way to fix broker will be
> restarting it.
> Analysis has shown, that error occurs with CPP proton client in cases when
> 1) SSL connection is used
> 2) connection errors on client side are ignored
> 3) connection is dropped due to the client process termination / network
> disconnection
> *Steps to reproduce*
> # Java broker should be installed
> # Broker should be configured to allow one connection
> # Prepare certificates
> # Install Qpid::Proton 0.28.0
> wget
> [http://archive.apache.org/dist/qpid/proton/0.28.0/qpid-proton-0.28.0.tar.gz]
> gunzip qpid-proton-0.28.0.tar.gz
> mkdir -p qpid-proton-0.28.0/build && pushd qpid-proton-0.28.0/build && cmake
> .. && make all && popd
> # Replace and edit example *qpid-proton-0.28.0/cpp/examples/simple_recv.cpp*
> with the one attached
> # Build again
> cd qpid-proton-0.28.0/build
> make
> # Break the broker
> ./cpp/examples/simple_recv & ./cpp/examples/simple_recv
> Connection error
> {color:#ffab00}^C <= Hit Ctrl+C to kill process{color}
> # {color:#172b4d}If CPU usage didn't increased, find the PID of the first
> simple_recv process using ps-ef | grep simple_recv and kill it using kill -9
> PID.{color}
> *Analysis*
> CPU usage rises when connection is dropped on the client side or when network
> is broken between client and broker. The main point is that client isn't well
> behaved and connection shouldn't be closed correctly.
> On broker side connection becomes "orphaned": it is still maintained by
> broker, but no real reading / writing is performed. Following method calls
> are performed in an endless loop for each "orphaned" connection:
> SelectorThread.performSelect()
> SelectorThread.ConnectionProcessor.processConnection()
> NetworkConnectionScheduler.processConnection()
> NonBlockingConnection.doWork()
> As there nothing physically read or written, both methods
> NonBlockingConnection.doRead() and NonBlockingConnection.doWrite() execute
> very fast (several milliseconds) without any blocking processes and after
> that connection is immediately rescheduled for processing in
> NetworkConnectionScheduler. After that loop repeats.
> As the connection lifecycle is normal, there is logged nothing unusual or
> suspicious (nothing is seen in log at all).
> In thread dump (see attachment) there is seen, that utilized are mostly
> thread with names virtualhost-default-iopool-XX. Typical stacktrace looks
> like following:
> {noformat}
> "virtualhost-default-iopool-39" #92 prio=5 os_prio=0 tid=0x7f47ec335800
> nid=0x37196 waiting on condition
> [0x7f476a4e3000]"virtualhost-default-iopool-39" #92 prio=5 os_prio=0
> tid=0x7f47ec335800 nid=0x37196 waiting on condition [0x7f476a4e3000]
> java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native
> Method) - parking to wait for <0xf39105d0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:532)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory$$Lambda$18/422330142.run(Unknown
> Source) at java.lang.Thread.run(Thread.java:748)}
> {noformat}
> The main symptom of an error is rising CPU usage, which can reach up to 90%
> in case, when several connections are "orphaned". Additional factor leading
> to the problem is disabled keep-alive option for a connection or lon
