[jira] [Commented] (PROTON-1538) Epoll proactor unguarded memory access
[ https://issues.apache.org/jira/browse/PROTON-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137652#comment-16137652 ] Justin Ross commented on PROTON-1538: - [~cliffjansen], is this still open? > Epoll proactor unguarded memory access > -- > > Key: PROTON-1538 > URL: https://issues.apache.org/jira/browse/PROTON-1538 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > ThreadSanitizer singled out the epoll_event for network sockets to be a risk > of out of order access by multiple threads. > On inspection it is possible that two threads could try rearming the socket > out of order, allowing the wrong events of interest to be registered. > Reusing the existing connection context mutex would be costly for > guarding this since the system call is frequent and relatively long > compared to other acquisitions of the mutex. Adding a new mutex that > guards this operation should fix things with negligible performance > cost. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1538) Epoll proactor unguarded memory access
[ https://issues.apache.org/jira/browse/PROTON-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1538: Fix Version/s: (was: proton-j-0.18.0) proton-c-0.18.0 > Epoll proactor unguarded memory access > -- > > Key: PROTON-1538 > URL: https://issues.apache.org/jira/browse/PROTON-1538 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > ThreadSanitizer singled out the epoll_event for network sockets to be a risk > of out of order access by multiple threads. > On inspection it is possible that two threads could try rearming the socket > out of order, allowing the wrong events of interest to be registered. > Reusing the existing connection context mutex would be costly for > guarding this since the system call is frequent and relatively long > compared to other acquisitions of the mutex. Adding a new mutex that > guards this operation should fix things with negligible performance > cost. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1549) Document legal values for the reconnect parameter
[ https://issues.apache.org/jira/browse/PROTON-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1549: Fix Version/s: (was: proton-c-0.18.0) proton-c-0.19.0 > Document legal values for the reconnect parameter > - > > Key: PROTON-1549 > URL: https://issues.apache.org/jira/browse/PROTON-1549 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: proton-c-0.19.0 > > > https://github.com/apache/qpid-proton/blob/cfa3663568e3717e7978a3c0223a8c3b0f945656/proton-c/bindings/python/proton/reactor.py#L683 > A value of True fails. It expects an object implementing a reconnect > strategy. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1550) Epoll proactor performance improvement
Cliff Jansen created PROTON-1550: Summary: Epoll proactor performance improvement Key: PROTON-1550 URL: https://issues.apache.org/jira/browse/PROTON-1550 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: proton-c-0.18.0 Environment: Linux Reporter: Cliff Jansen Fix For: proton-c-0.18.0 While stress testing and evaluating performance of the epoll proactor there have been indications that as the number of connections increase, the throughput increases more slowly than overall cpu use. Instrumenting and profiling suggest that, at least for applications like qpid-dispatch, there can be a large number of simultaneous pending pn_connection_wake() requests for thread-safe handoff of messages from one connection context to another. As the number of connections rise, the use of adaptive spin locks for this purpose is suspected to be an inefficient strategy, perhaps resulting in a lock convoy. A trial use of one or more lockless queues could yield substantial performance gain or at least better understanding of current hot spots. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1461) [c++] Proton C++ client silently retains presettled messages
[ https://issues.apache.org/jira/browse/PROTON-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1461: Fix Version/s: proton-c-0.18.0 > [c++] Proton C++ client silently retains presettled messages > > > Key: PROTON-1461 > URL: https://issues.apache.org/jira/browse/PROTON-1461 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.0 > Environment: Fedora 25 > Test message source: Qpid Dispatch Router with address that has > 'distributionMode: multicast' > Test client: example simple_recv.cpp >Reporter: Chuck Rolke >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > With distributionMode 'multicast' the router sends messages presettled. In > this mode the simple_recv program memory grows without bound until OOM. > Switching the router to use distribution mode 'closest' causes the router to > send messages unsettled. In this mode the same simple_recv client sends back > a disposition and program memory use is normal. > A brokered connection, like to Apache Artemis, behaves normally with > unsettled messages and dispositions for each. > For comparison example program proton-0.18.0/examples/python/simple_recv.py > receives router multicast presettled messages and experiences no memory > growth. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1549) Document legal values for the reconnect parameter
Justin Ross created PROTON-1549: --- Summary: Document legal values for the reconnect parameter Key: PROTON-1549 URL: https://issues.apache.org/jira/browse/PROTON-1549 Project: Qpid Proton Issue Type: Improvement Components: python-binding Reporter: Justin Ross Assignee: Justin Ross Fix For: proton-c-0.18.0 https://github.com/apache/qpid-proton/blob/cfa3663568e3717e7978a3c0223a8c3b0f945656/proton-c/bindings/python/proton/reactor.py#L683 A value of True fails. It expects an object implementing a reconnect strategy. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding
[
https://issues.apache.org/jira/browse/PROTON-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137324#comment-16137324
]
ASF GitHub Bot commented on PROTON-1532:
Github user alanconway commented on the issue:
https://github.com/apache/qpid-proton/pull/116
@gberginc we do indeed publish a gem https://rubygems.org/gems/qpid_proton/
- I'm not in charge of that but it should be updated as part of the upcoming
0.18 release, so sometime before end Sept.
> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> When I try to connect to an AMQP endpoint using the URL of the form
> amqp://user:password@host:port, I get an error about a missing "plain"
> method. This occurs in [this
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
> This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
> => true
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
> => # @impl=# @__swigtype__="_p_pn_transport_t",
> @proton_wrapper=#>>
> 2.3.3 :003 > sasl = transport.sasl
> => # @impl=# @__swigtype__="_p_pn_sasl_t">>
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem
> 0.10.1 from Rubygems as well as in Centos 7, following the source code
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding
> does not use it in that way, but it does set the username and password on the
> connection.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #116: PROTON-1532: Allow insecure mechanism in SASL
Github user alanconway commented on the issue: https://github.com/apache/qpid-proton/pull/116 @gberginc we do indeed publish a gem https://rubygems.org/gems/qpid_proton/ - I'm not in charge of that but it should be updated as part of the upcoming 0.18 release, so sometime before end Sept. --- 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. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding
[
https://issues.apache.org/jira/browse/PROTON-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137319#comment-16137319
]
ASF GitHub Bot commented on PROTON-1532:
Github user gberginc commented on the issue:
https://github.com/apache/qpid-proton/pull/116
@alanconway I will review and test your update, thank you very much! I will
report back and then also close this PR.
The documentation in the readme is correct as I followed those steps to
create a gem for my experiments.
> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> When I try to connect to an AMQP endpoint using the URL of the form
> amqp://user:password@host:port, I get an error about a missing "plain"
> method. This occurs in [this
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
> This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
> => true
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
> => # @impl=# @__swigtype__="_p_pn_transport_t",
> @proton_wrapper=#>>
> 2.3.3 :003 > sasl = transport.sasl
> => # @impl=# @__swigtype__="_p_pn_sasl_t">>
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem
> 0.10.1 from Rubygems as well as in Centos 7, following the source code
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding
> does not use it in that way, but it does set the username and password on the
> connection.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #116: PROTON-1532: Allow insecure mechanism in SASL
Github user gberginc commented on the issue: https://github.com/apache/qpid-proton/pull/116 @alanconway I will review and test your update, thank you very much! I will report back and then also close this PR. The documentation in the readme is correct as I followed those steps to create a gem for my experiments. --- 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. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding
[
https://issues.apache.org/jira/browse/PROTON-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137297#comment-16137297
]
ASF GitHub Bot commented on PROTON-1532:
Github user alanconway commented on the issue:
https://github.com/apache/qpid-proton/pull/116
@gberginc I just this very minute pushed the fixes to the master branch you
can get it right away. It will be in the next source code release which is
planned for mid Sept. There isn't a proper example, look at
tests/test_container.rb for some samples of use.
I am unsure about whether we publish a gem - I am taking over the ruby code
after a lapse of care. There are instructions for making a gem at
https://github.com/alanconway/qpid-proton/blob/master/proton-c/bindings/ruby/README.rdoc#L25
I don't know if they work - I would appreciate if you can try them and
raise an issue if they don't.
> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> When I try to connect to an AMQP endpoint using the URL of the form
> amqp://user:password@host:port, I get an error about a missing "plain"
> method. This occurs in [this
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
> This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
> => true
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
> => # @impl=# @__swigtype__="_p_pn_transport_t",
> @proton_wrapper=#>>
> 2.3.3 :003 > sasl = transport.sasl
> => # @impl=# @__swigtype__="_p_pn_sasl_t">>
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem
> 0.10.1 from Rubygems as well as in Centos 7, following the source code
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding
> does not use it in that way, but it does set the username and password on the
> connection.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #116: PROTON-1532: Allow insecure mechanism in SASL
Github user alanconway commented on the issue: https://github.com/apache/qpid-proton/pull/116 @gberginc I just this very minute pushed the fixes to the master branch you can get it right away. It will be in the next source code release which is planned for mid Sept. There isn't a proper example, look at tests/test_container.rb for some samples of use. I am unsure about whether we publish a gem - I am taking over the ruby code after a lapse of care. There are instructions for making a gem at https://github.com/alanconway/qpid-proton/blob/master/proton-c/bindings/ruby/README.rdoc#L25 I don't know if they work - I would appreciate if you can try them and raise an issue if they don't. --- 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. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #116: PROTON-1532: Allow insecure mechanism in SASL
Github user alanconway commented on the issue: https://github.com/apache/qpid-proton/pull/116 Commit 36b64f73ffe7e9add93c32da622474d2ee29dce6 in qpid-proton's branch refs/heads/master from Alan Conway [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=36b64f7 ] PROTON-1532: ruby Container support for SASL, client and server. add Container.connect options for client-side SASL settings use on_connection_bound for server-side SASL settings based on incoming connection/transport For example code see proton-c/bindings/ruby/tests/test_container.rb Proper examples will be added later. --- 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. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding
[
https://issues.apache.org/jira/browse/PROTON-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137302#comment-16137302
]
ASF GitHub Bot commented on PROTON-1532:
Github user alanconway commented on the issue:
https://github.com/apache/qpid-proton/pull/116
Commit 36b64f73ffe7e9add93c32da622474d2ee29dce6 in qpid-proton's branch
refs/heads/master from Alan Conway
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=36b64f7 ]
PROTON-1532: ruby Container support for SASL, client and server.
add Container.connect options for client-side SASL settings
use on_connection_bound for server-side SASL settings based on incoming
connection/transport
For example code see proton-c/bindings/ruby/tests/test_container.rb
Proper examples will be added later.
> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> When I try to connect to an AMQP endpoint using the URL of the form
> amqp://user:password@host:port, I get an error about a missing "plain"
> method. This occurs in [this
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
> This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
> => true
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
> => # @impl=# @__swigtype__="_p_pn_transport_t",
> @proton_wrapper=#>>
> 2.3.3 :003 > sasl = transport.sasl
> => # @impl=# @__swigtype__="_p_pn_sasl_t">>
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem
> 0.10.1 from Rubygems as well as in Centos 7, following the source code
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding
> does not use it in that way, but it does set the username and password on the
> connection.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding
[
https://issues.apache.org/jira/browse/PROTON-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved PROTON-1532.
-
Resolution: Fixed
Fix Version/s: proton-c-0.18.0
> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> When I try to connect to an AMQP endpoint using the URL of the form
> amqp://user:password@host:port, I get an error about a missing "plain"
> method. This occurs in [this
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
> This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
> => true
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
> => # @impl=# @__swigtype__="_p_pn_transport_t",
> @proton_wrapper=#>>
> 2.3.3 :003 > sasl = transport.sasl
> => # @impl=# @__swigtype__="_p_pn_sasl_t">>
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem
> 0.10.1 from Rubygems as well as in Centos 7, following the source code
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding
> does not use it in that way, but it does set the username and password on the
> connection.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding
[
https://issues.apache.org/jira/browse/PROTON-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137277#comment-16137277
]
ASF subversion and git services commented on PROTON-1532:
-
Commit 36b64f73ffe7e9add93c32da622474d2ee29dce6 in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=36b64f7 ]
PROTON-1532: ruby Container support for SASL, client and server.
- add Container.connect options for client-side SASL settings
- use on_connection_bound for server-side SASL settings based on incoming
connection/transport
For example code see proton-c/bindings/ruby/tests/test_container.rb
Proper examples will be added later.
> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
>
> When I try to connect to an AMQP endpoint using the URL of the form
> amqp://user:password@host:port, I get an error about a missing "plain"
> method. This occurs in [this
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
> This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
> => true
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
> => # @impl=# @__swigtype__="_p_pn_transport_t",
> @proton_wrapper=#>>
> 2.3.3 :003 > sasl = transport.sasl
> => # @impl=# @__swigtype__="_p_pn_sasl_t">>
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem
> 0.10.1 from Rubygems as well as in Centos 7, following the source code
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding
> does not use it in that way, but it does set the username and password on the
> connection.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-209) Update README file(s) to more specific about required versions of tools
[ https://issues.apache.org/jira/browse/PROTON-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-209. Resolution: Fixed > Update README file(s) to more specific about required versions of tools > --- > > Key: PROTON-209 > URL: https://issues.apache.org/jira/browse/PROTON-209 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Affects Versions: 0.3 >Reporter: Philip Harvey >Assignee: Justin Ross >Priority: Minor > Labels: docs > Fix For: proton-c-0.18.0 > > > We should be more explicit about which version of the following tools are > required by Proton, either in the top level README or in READMEs in the > relevant sub-folders: > - Python (see PROTON-199). > - Swig > - cmake? (the required version is specified in the CMakeLists.txt files but > maybe it would be polite to mention in the README too). > - Maven? (or maybe we can omit this for same reasons as cmake version) > - possibly others, e.g. openssl, gcc, epydoc, Perl, Ruby etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-209) Update README file(s) to more specific about required versions of tools
[ https://issues.apache.org/jira/browse/PROTON-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137232#comment-16137232 ] Justin Ross commented on PROTON-209: I went with Ruby 1.9 based on current info. Will reopen if that proves wrong. > Update README file(s) to more specific about required versions of tools > --- > > Key: PROTON-209 > URL: https://issues.apache.org/jira/browse/PROTON-209 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Affects Versions: 0.3 >Reporter: Philip Harvey >Assignee: Justin Ross >Priority: Minor > Labels: docs > Fix For: proton-c-0.18.0 > > > We should be more explicit about which version of the following tools are > required by Proton, either in the top level README or in READMEs in the > relevant sub-folders: > - Python (see PROTON-199). > - Swig > - cmake? (the required version is specified in the CMakeLists.txt files but > maybe it would be polite to mention in the README too). > - Maven? (or maybe we can omit this for same reasons as cmake version) > - possibly others, e.g. openssl, gcc, epydoc, Perl, Ruby etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-209) Update README file(s) to more specific about required versions of tools
[ https://issues.apache.org/jira/browse/PROTON-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137231#comment-16137231 ] ASF subversion and git services commented on PROTON-209: Commit 0606126665f91edbc568ee386f0e85675823e10b in qpid-proton's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0606126 ] PROTON-209: Add the minimum Ruby version and make the version notation consistent across deps > Update README file(s) to more specific about required versions of tools > --- > > Key: PROTON-209 > URL: https://issues.apache.org/jira/browse/PROTON-209 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Affects Versions: 0.3 >Reporter: Philip Harvey >Assignee: Justin Ross >Priority: Minor > Labels: docs > Fix For: proton-c-0.18.0 > > > We should be more explicit about which version of the following tools are > required by Proton, either in the top level README or in READMEs in the > relevant sub-folders: > - Python (see PROTON-199). > - Swig > - cmake? (the required version is specified in the CMakeLists.txt files but > maybe it would be polite to mention in the README too). > - Maven? (or maybe we can omit this for same reasons as cmake version) > - possibly others, e.g. openssl, gcc, epydoc, Perl, Ruby etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding
[
https://issues.apache.org/jira/browse/PROTON-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137225#comment-16137225
]
ASF GitHub Bot commented on PROTON-1532:
Github user gberginc commented on the issue:
https://github.com/apache/qpid-proton/pull/116
@alanconway do you perhaps have a timeline for this to be released as a
Gem? For the development I am able to use my own branch of this gem, but will
need a published gem in the end.
> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
>
> When I try to connect to an AMQP endpoint using the URL of the form
> amqp://user:password@host:port, I get an error about a missing "plain"
> method. This occurs in [this
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
> This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
> => true
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
> => # @impl=# @__swigtype__="_p_pn_transport_t",
> @proton_wrapper=#>>
> 2.3.3 :003 > sasl = transport.sasl
> => # @impl=# @__swigtype__="_p_pn_sasl_t">>
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem
> 0.10.1 from Rubygems as well as in Centos 7, following the source code
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding
> does not use it in that way, but it does set the username and password on the
> connection.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #116: PROTON-1532: Allow insecure mechanism in SASL
Github user gberginc commented on the issue: https://github.com/apache/qpid-proton/pull/116 @alanconway do you perhaps have a timeline for this to be released as a Gem? For the development I am able to use my own branch of this gem, but will need a published gem in the end. --- 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. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-209) Update README file(s) to more specific about required versions of tools
[ https://issues.apache.org/jira/browse/PROTON-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137216#comment-16137216 ] Justin Ross commented on PROTON-209: Alan answered here - https://issues.apache.org/jira/browse/PROTON-1175?focusedCommentId=16136913=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16136913 > Update README file(s) to more specific about required versions of tools > --- > > Key: PROTON-209 > URL: https://issues.apache.org/jira/browse/PROTON-209 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Affects Versions: 0.3 >Reporter: Philip Harvey >Assignee: Justin Ross >Priority: Minor > Labels: docs > Fix For: proton-c-0.18.0 > > > We should be more explicit about which version of the following tools are > required by Proton, either in the top level README or in READMEs in the > relevant sub-folders: > - Python (see PROTON-199). > - Swig > - cmake? (the required version is specified in the CMakeLists.txt files but > maybe it would be polite to mention in the README too). > - Maven? (or maybe we can omit this for same reasons as cmake version) > - possibly others, e.g. openssl, gcc, epydoc, Perl, Ruby etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Setting SASL realm
Reading the SASL docs I think we also need to allow SASL realm to be set on a per-connection basis, in CONNECTION_BOUND - and expose that in all bindings. This is because the realm may be set by the server based on incoming vhost. CONNECTION_BOUND is the only point where we a) have the incoming vhost and b) authentication is not yet done, so it seems the right place. I think it's a simple setter on the SASL object, any other ideas? On Fri, 2017-08-11 at 18:55 +, Gordon Sim wrote: > > On Aug. 11, 2017, 5:46 p.m., Andrew Stitcher wrote: > > > This looks fine. > > > > > > Can you just confirm that adding this extra field to the frame is still > > > amqp 1.0 protocol compliant (I dont have time to check that today). > > From spec: > > > > > > > > > "This field can be used by AMQP proxies to determine the correct back-end > service to connect the > client to, and to determine the domain to validate the client’s credentials > against." > > > - Gordon > > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/61596/#review182725 > --- > > > On Aug. 11, 2017, 5:24 p.m., Gordon Sim wrote: > > > > --- > > This is an automatically generated e-mail. To reply, visit: > > https://reviews.apache.org/r/61596/ > > --- > > > > (Updated Aug. 11, 2017, 5:24 p.m.) > > > > > > Review request for qpid and Andrew Stitcher. > > > > > > Bugs: PROTON-1535 > > https://issues.apache.org/jira/browse/PROTON-1535 > > > > > > Repository: qpid-proton-git > > > > > > Description > > --- > > > > allow hostname to be set for sasl-init > > > > > > Diffs > > - > > > > proton-c/include/proton/sasl-plugin.h cbc6684 > > proton-c/src/sasl/sasl-internal.h fc141b4 > > proton-c/src/sasl/sasl.c a39e602 > > > > > > Diff: https://reviews.apache.org/r/61596/diff/1/ > > > > > > Testing > > --- > > > > > > Thanks, > > > > Gordon Sim > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1175) Document BlockingConnection resource cleanup
[ https://issues.apache.org/jira/browse/PROTON-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136913#comment-16136913 ] Alan Conway commented on PROTON-1175: - [~jr...@redhat.com] I haven't tested old versions, but AFAIK it should all work on 1.9.3 forwards. I fixed one 2.4 compat problem but the fix is compatible back to 1.9.3 (I think - not tested) Before we make an official claim for 1.9.3 we should test it in CI. Ruby 2 is not as drastic a change as python 3, so keeping compat is not onerous - at least not that I've found so far. > Document BlockingConnection resource cleanup > > > Key: PROTON-1175 > URL: https://issues.apache.org/jira/browse/PROTON-1175 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Cliff Jansen >Assignee: Justin Ross > Labels: docs > Fix For: proton-c-0.18.0 > > > The documentation is silent on resource cleanup for BlockingConnections. > Currently if the BlockingConnection is not closed, the file descriptors and > other reactor machinery are leaked. > Standard Python techniques should be used to ensure resource clean up > (try..finally blocks etc.) > Only the sync_client example hints this might be desirable, let alone > necessary. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7895) [linearstore] Excessive CPU utilization for some kernel clocksources
[ https://issues.apache.org/jira/browse/QPID-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136911#comment-16136911 ] ASF subversion and git services commented on QPID-7895: --- Commit 4e98f6c08ef531e15217f812f6624f18cf2d50fb in qpid-cpp's branch refs/heads/master from [~kpvdr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=4e98f6c ] QPID-7895: Update to linearstore to make the flush timer more intelligent and only run when there is flushable content in the write buffers > [linearstore] Excessive CPU utilization for some kernel clocksources > > > Key: QPID-7895 > URL: https://issues.apache.org/jira/browse/QPID-7895 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > For some kernel clocksources (eg acpi_pm), it has been observed that there is > an excessively high CPU utilization which correlates with the linearstore's > flush timeout being set to a very low value (100us). This is a problem for > some customers which require almost instant flush to obtain > pseudo-synchronous store behavior (hence the 100us flush timer) and run many > brokers (up to hundreds) on a single machine. In these cases, the CPU is > 100% utilized. > A check of the source shows that the flush timer is firing continuously, > irrespective of whether any disk I/O has taken place. > It is proposed that a change to linearstore be made which will only run the > timer when needed (ie while there is content in the write buffers that needs > flushing). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7895) [linearstore] Excessive CPU utilization for some kernel clocksources
Kim van der Riet created QPID-7895: -- Summary: [linearstore] Excessive CPU utilization for some kernel clocksources Key: QPID-7895 URL: https://issues.apache.org/jira/browse/QPID-7895 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Kim van der Riet Assignee: Kim van der Riet For some kernel clocksources (eg acpi_pm), it has been observed that there is an excessively high CPU utilization which correlates with the linearstore's flush timeout being set to a very low value (100us). This is a problem for some customers which require almost instant flush to obtain pseudo-synchronous store behavior (hence the 100us flush timer) and run many brokers (up to hundreds) on a single machine. In these cases, the CPU is 100% utilized. A check of the source shows that the flush timer is firing continuously, irrespective of whether any disk I/O has taken place. It is proposed that a change to linearstore be made which will only run the timer when needed (ie while there is content in the write buffers that needs flushing). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-314) java.lang.AssertionError at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
[
https://issues.apache.org/jira/browse/QPIDJMS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136824#comment-16136824
]
Jiri Danek commented on QPIDJMS-314:
I'd be happy to promptly provide additional information if the reproduction
steps I provided don't happen to work for you.
> java.lang.AssertionError at
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> -
>
> Key: QPIDJMS-314
> URL: https://issues.apache.org/jira/browse/QPIDJMS-314
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.24.0
>Reporter: Jiri Danek
>
> I have a test suite which sometimes causes qpid-jms to die on AssertionError
> from netty. Rerunning the single failing test does not seem to reproduce it,
> I have to run the whole suite.
> First, start a broker. I am using ActiveMQ Artemis. The travis build uses a
> docker image with the broker. Then run the test suite in a loop, until it
> fails.
> {noformat}
> git clone g...@github.com:jdanekrh/cli-java.git
> cd cli-java/
> git checkout jd_code_push
> ret=0
> while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
> {noformat}
> Here is log from when it failed in Travis,
> https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207
> I do not know how to debug this (it never happened when I was running it
> under debugger). Also, even if I could get it in a debugger, I would not know
> what to do next.
> The relevant part of maven output is
> {noformat}
> [...]
> Receiving:
> 6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
> 15:36:17.444Connecting: 1 0 1
> 15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0,
> 'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id':
> 'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id':
> None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None,
> 'reply_to': None, 'correlation_id': None, 'content_type': None,
> 'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time':
> 1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id':
> None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
> Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec
> <<< FAILURE! - in AacMainTest
> sendAndReceiveWithAllSenderCLISwitches(String) Time elapsed: 0.336 sec <<<
> FAILURE!
> java.lang.AssertionError
> at
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> at
> io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
> at
> io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
> at
> io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> at java.lang.Thread.run(Thread.java:748)
> sendAndReceiveSingleMessage() Time elapsed: 0.049 sec <<< FAILURE!
> java.lang.AssertionError
> at
> io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
> at
> io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
> at
> io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
> at
> io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
> at
> io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
> at java.lang.Thread.run(Thread.java:748)
> Results :
> Failed tests:
> AbstractMainTest.sendAndReceiveSingleMessage
> sendAndReceiveWithAllSenderCLISwitches(String).sendAndReceiveWithAllSenderCLISwitches(String)
> Run 1: PASS
> Run 2: PASS
> Run 3: PASS
> Run 4: PASS
> Run 5: PASS
> Run
[jira] [Updated] (QPIDJMS-314) java.lang.AssertionError at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
[
https://issues.apache.org/jira/browse/QPIDJMS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Danek updated QPIDJMS-314:
---
Description:
I have a test suite which sometimes causes qpid-jms to die on AssertionError
from netty. Rerunning the single failing test does not seem to reproduce it, I
have to run the whole suite.
First, start a broker. I am using ActiveMQ Artemis. The travis build uses a
docker image with the broker. Then run the test suite in a loop, until it fails.
{noformat}
git clone g...@github.com:jdanekrh/cli-java.git
cd cli-java/
git checkout jd_code_push
ret=0
while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
{noformat}
Here is log from when it failed in Travis,
https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207
I do not know how to debug this (it never happened when I was running it under
debugger). Also, even if I could get it in a debugger, I would not know what to
do next.
The relevant part of maven output is
{noformat}
[...]
Receiving:
6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
15:36:17.444Connecting: 1 0 1
15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0,
'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id':
'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id':
None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None,
'reply_to': None, 'correlation_id': None, 'content_type': None,
'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time':
1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id':
None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec <<<
FAILURE! - in AacMainTest
sendAndReceiveWithAllSenderCLISwitches(String) Time elapsed: 0.336 sec <<<
FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)
sendAndReceiveSingleMessage() Time elapsed: 0.049 sec <<< FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)
Results :
Failed tests:
AbstractMainTest.sendAndReceiveSingleMessage
sendAndReceiveWithAllSenderCLISwitches(String).sendAndReceiveWithAllSenderCLISwitches(String)
Run 1: PASS
Run 2: PASS
Run 3: PASS
Run 4: PASS
Run 5: PASS
Run 6: PASS
Run 7: AbstractMainTest.sendAndReceiveWithAllSenderCLISwitches
Run 8: PASS
Run 9: PASS
Run 10: PASS
Run 11: PASS
Tests run: 11, Failures: 2, Errors: 0, Skipped: 0
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] bom SUCCESS [ 0.002 s]
[INFO] parent . SUCCESS [ 0.915 s]
[INFO] tests .. SUCCESS [ 7.428 s]
[INFO] jmslib . SUCCESS [ 0.038 s]
[INFO] cli-activemq ... SUCCESS [ 13.471 s]
[INFO] cli-artemis-jms SUCCESS [ 10.811 s]
[INFO]
[jira] [Created] (QPIDJMS-314) java.lang.AssertionError at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
Jiri Danek created QPIDJMS-314:
--
Summary: java.lang.AssertionError at
io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
Key: QPIDJMS-314
URL: https://issues.apache.org/jira/browse/QPIDJMS-314
Project: Qpid JMS
Issue Type: Bug
Components: qpid-jms-client
Affects Versions: 0.24.0
Reporter: Jiri Danek
I have a test suite which sometimes causes qpid-jms to die on AssertionError
from netty. Rerunning the single failing test does not seem to reproduce it, I
have to run the whole suite.
First, start a broker. I am using ActiveMQ Artemis. The travis build uses a
docker image with the broker. Then run the test suite in a loop, until it fails.
{noformat}
git clone g...@github.com:jdanekrh/cli-java.git
cd cli-java/
git checkout jd_code_push
ret=0
while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
{noformat}
Here is log from when it failed in Travis,
https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207
I do not know how to debug this (it never happened when I was running it under
debugger). Also, even if I could get it in a debugger, I would not know what to
do next.
The relevant part of maven output is
{noformat}
[...]
Receiving:
6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
15:36:17.444Connecting: 1 0 1
15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0,
'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id':
'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id':
None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None,
'reply_to': None, 'correlation_id': None, 'content_type': None,
'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time':
1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id':
None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec <<<
FAILURE! - in AacMainTest
sendAndReceiveWithAllSenderCLISwitches(String) Time elapsed: 0.336 sec <<<
FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)
sendAndReceiveSingleMessage() Time elapsed: 0.049 sec <<< FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)
Results :
Failed tests:
AbstractMainTest.sendAndReceiveSingleMessage
sendAndReceiveWithAllSenderCLISwitches(String).sendAndReceiveWithAllSenderCLISwitches(String)
Run 1: PASS
Run 2: PASS
Run 3: PASS
Run 4: PASS
Run 5: PASS
Run 6: PASS
Run 7: AbstractMainTest.sendAndReceiveWithAllSenderCLISwitches
Run 8: PASS
Run 9: PASS
Run 10: PASS
Run 11: PASS
Tests run: 11, Failures: 2, Errors: 0, Skipped: 0
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] bom SUCCESS [ 0.002 s]
[INFO] parent . SUCCESS [ 0.915 s]
[INFO] tests .. SUCCESS [ 7.428 s]
[INFO]
[jira] [Updated] (QPIDJMS-314) java.lang.AssertionError at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
[
https://issues.apache.org/jira/browse/QPIDJMS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Danek updated QPIDJMS-314:
---
Description:
I have a test suite which sometimes causes qpid-jms to die on AssertionError
from netty. Rerunning the single failing test does not seem to reproduce it, I
have to run the whole suite.
First, start a broker. I am using ActiveMQ Artemis. The travis build uses a
docker image with the broker. Then run the test suite in a loop, until it fails.
{noformat}
git clone g...@github.com:jdanekrh/cli-java.git
cd cli-java/
git checkout jd_code_push
ret=0
while [[ ret -eq 0 ]]; do mvn test; ret=$?; done
{noformat}
Here is log from when it failed in Travis,
https://travis-ci.org/rh-messaging-qe/cli-java/jobs/267185207
I do not know how to debug this (it never happened when I was running it under
debugger). Also, even if I could get it in a debugger, I would not know what to
do next.
The relevant part of maven output is
{noformat}
[...]
Receiving:
6,1,sendAndReceiveWithAllSenderCLISwitches(String),sendAndReceiveWithAllSenderCLISwitches(String),null,null,null
15:36:17.444Connecting: 1 0 1
15:36:17.515Sending: {'durable': True, 'priority': 4, 'ttl': 0,
'first-acquirer': False, 'delivery-count': 0, 'redelivered': False, 'id':
'ID:aConnIdPrefix32a68f56-629b-4111-a36c-aede9135c52c:1:1:1-1', 'user_id':
None, 'address': 'lalaLand_l6o9ghgpom4jmu15cln21gpoi5', 'subject': None,
'reply_to': None, 'correlation_id': None, 'content_type': None,
'content_encoding': None, 'absolute-expiry-time': 0, 'creation-time':
1503408977545, 'group-id': None, 'group-sequence': 0, 'reply-to-group-id':
None, 'properties': {'JMSXDeliveryCount': 1}, 'content': None}
Tests run: 21, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 10.384 sec <<<
FAILURE! - in AacMainTest
sendAndReceiveWithAllSenderCLISwitches(String) Time elapsed: 0.336 sec <<<
FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)
sendAndReceiveSingleMessage() Time elapsed: 0.049 sec <<< FAILURE!
java.lang.AssertionError
at io.netty.channel.epoll.EpollEventLoop.remove(EpollEventLoop.java:159)
at
io.netty.channel.epoll.AbstractEpollChannel.doDeregister(AbstractEpollChannel.java:142)
at
io.netty.channel.epoll.AbstractEpollChannel.doClose(AbstractEpollChannel.java:118)
at
io.netty.channel.epoll.AbstractEpollStreamChannel.doClose(AbstractEpollStreamChannel.java:703)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:685)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$700(AbstractChannel.java:419)
at
io.netty.channel.AbstractChannel$AbstractUnsafe$5.run(AbstractChannel.java:646)
at
io.netty.util.concurrent.GlobalEventExecutor$TaskRunner.run(GlobalEventExecutor.java:233)
at
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
at java.lang.Thread.run(Thread.java:748)
Results :
Failed tests:
AbstractMainTest.sendAndReceiveSingleMessage
sendAndReceiveWithAllSenderCLISwitches(String).sendAndReceiveWithAllSenderCLISwitches(String)
Run 1: PASS
Run 2: PASS
Run 3: PASS
Run 4: PASS
Run 5: PASS
Run 6: PASS
Run 7: AbstractMainTest.sendAndReceiveWithAllSenderCLISwitches
Run 8: PASS
Run 9: PASS
Run 10: PASS
Run 11: PASS
Tests run: 11, Failures: 2, Errors: 0, Skipped: 0
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] bom SUCCESS [ 0.002 s]
[INFO] parent . SUCCESS [ 0.915 s]
[INFO] tests .. SUCCESS [ 7.428 s]
[INFO] jmslib . SUCCESS [ 0.038 s]
[INFO] cli-activemq ... SUCCESS [ 13.471 s]
[INFO] cli-artemis-jms SUCCESS [ 10.811 s]
[INFO]
