[jira] [Created] (QPIDIT-118) Add char and decimal in amqpnetlite shim
Xin Chen created QPIDIT-118: --- Summary: Add char and decimal in amqpnetlite shim Key: QPIDIT-118 URL: https://issues.apache.org/jira/browse/QPIDIT-118 Project: Apache QPID Interoperability Test Suite Issue Type: Improvement Components: .Net Lite Shim Reporter: Xin Chen Encoding support for char and decimal has been added in the .Net Lite library. The decimal type is implemented by Amqp.Types.Decimal. It is not the C# decimal type because .Net does not use the standard IEEE 754 decimal32/64/128 encoding. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-942) allow resumable link routes to be refused
[ https://issues.apache.org/jira/browse/DISPATCH-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-942. - Resolution: Fixed > allow resumable link routes to be refused > - > > Key: DISPATCH-942 > URL: https://issues.apache.org/jira/browse/DISPATCH-942 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > > If link routing through a router network to a set of brokers, it is possible > that the client asks for e/g/ a durable subscription - i.e.a link whose > terminus state should survive the client being disconnected. However in some > deployments it may not be possible (or desirable to keep the necessary state > to do so) to reroute the link back to the same broker on the client > reconnecting. In such cases, it would be desirable to be able to configure > the router such that it refuses to link route such link requests to avoid > mis-set expectations and potentially having stale subscriptions growing. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-943) segfault in remote_sasl
[
https://issues.apache.org/jira/browse/DISPATCH-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved DISPATCH-943.
-
Resolution: Fixed
> segfault in remote_sasl
> ---
>
> Key: DISPATCH-943
> URL: https://issues.apache.org/jira/browse/DISPATCH-943
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
>
> {noformat}
> (gdb) bt
> #0 0x7f42df02ae00 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x7f42df2435f4 in lock (m=0x18) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:112
> #2 pn_connection_wake (c=) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:1349
> #3 0x7f42df6c0573 in remote_sasl_free (transport=0x7f42bc05fa90) at
> /home/gordon/projects/dispatch/src/remote_sasl.c:247
> #4 0x7f42df46f1fb in pni_sasl_impl_free (transport=0x7f42bc05fa90) at
> /home/gordon/projects/proton/proton-c/src/sasl/sasl.c:167
> #5 pn_sasl_free (transport=0x7f42bc05fa90) at
> /home/gordon/projects/proton/proton-c/src/sasl/sasl.c:733
> #6 0x7f42df467c70 in pn_transport_finalize (object=0x7f42bc05fa90) at
> /home/gordon/projects/proton/proton-c/src/core/transport.c:664
> #7 0x7f42df4599a9 in pn_class_decref (clazz=0x7f42df681ca0 ,
> clazz@entry=0x7f42df681520 , object=0x7f42bc05fa90) at
> /home/gordon/projects/proton/proton-c/src/core/object/object.c:95
> #8 0x7f42df459bbf in pn_decref (object=) at
> /home/gordon/projects/proton/proton-c/src/core/object/object.c:253
> #9 0x7f42df467911 in pn_transport_free (transport=) at
> /home/gordon/projects/proton/proton-c/src/core/transport.c:643
> #10 0x7f42df4627b4 in pn_connection_driver_destroy
> (d=d@entry=0x7f42bc046538) at
> /home/gordon/projects/proton/proton-c/src/core/connection_driver.c:94
> #11 0x7f42df2426fc in pconnection_final_free (pc=0x7f42bc045f90) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:827
> #12 0x7f42df243404 in pconnection_cleanup (pc=) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:843
> #13 0x7f42df245cdc in pconnection_done (pc=0x7f42bc045f90) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:964
> #14 pn_proactor_done (p=, batch=0x7f42bc046530) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:2038
> #15 0x7f42df6e8e03 in thread_run (arg=0xa72860) at
> /home/gordon/projects/dispatch/src/server.c:960
> #16 0x7f42df02873a in start_thread () from /lib64/libpthread.so.0
> #17 0x7f42de515e7f in clone () from /lib64/libc.so.6
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-944) remote_sasl plugin leaving connections open
[ https://issues.apache.org/jira/browse/DISPATCH-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-944. - Resolution: Fixed > remote_sasl plugin leaving connections open > --- > > Key: DISPATCH-944 > URL: https://issues.apache.org/jira/browse/DISPATCH-944 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7873) [Broker-J] Delete store notion confused
[ https://issues.apache.org/jira/browse/QPID-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-7873. -- Resolution: Fixed I reviewed the changes made in commit [https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=e8efe56]. They look good, though I committed additional changes to do some code clean-up > [Broker-J] Delete store notion confused > --- > > Key: QPID-7873 > URL: https://issues.apache.org/jira/browse/QPID-7873 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > org.apache.qpid.server.store.MessageStore#onDelete > org.apache.qpid.server.store.DurableConfigurationStore#onDelete > org.apache.qpid.server.protocol.v1_0.store.LinkStore#delete > The Java Broker's delete store notion conflates the removal of the structures > from the store (e.g. the removal of a table from a RDBMS, for instance) with > the destruction of the store itself (e.g. removal of Derby or BDB files). We > are also unclear about whether we expect a store to be in an open state when > the store is deleted. > This problem does not currently cause a functional defect. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-942) allow resumable link routes to be refused
[ https://issues.apache.org/jira/browse/DISPATCH-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399523#comment-16399523 ] ASF subversion and git services commented on DISPATCH-942: -- Commit e62b5fb211f20281a8aeac5e324b3f391610effa in qpid-dispatch's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e62b5fb ] DISPATCH-942: introduce new router config option to allow/disallow "resumable" links > allow resumable link routes to be refused > - > > Key: DISPATCH-942 > URL: https://issues.apache.org/jira/browse/DISPATCH-942 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > > If link routing through a router network to a set of brokers, it is possible > that the client asks for e/g/ a durable subscription - i.e.a link whose > terminus state should survive the client being disconnected. However in some > deployments it may not be possible (or desirable to keep the necessary state > to do so) to reroute the link back to the same broker on the client > reconnecting. In such cases, it would be desirable to be able to configure > the router such that it refuses to link route such link requests to avoid > mis-set expectations and potentially having stale subscriptions growing. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-943) segfault in remote_sasl
[
https://issues.apache.org/jira/browse/DISPATCH-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399524#comment-16399524
]
ASF subversion and git services commented on DISPATCH-943:
--
Commit 9bcf0831386bfd0cef1591e7a672624c7d2c1849 in qpid-dispatch's branch
refs/heads/master from [~gsim]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=9bcf083 ]
DISPATCH-943: do not wakeup the other connection on free as it may also be
being freed
> segfault in remote_sasl
> ---
>
> Key: DISPATCH-943
> URL: https://issues.apache.org/jira/browse/DISPATCH-943
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
>
> {noformat}
> (gdb) bt
> #0 0x7f42df02ae00 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x7f42df2435f4 in lock (m=0x18) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:112
> #2 pn_connection_wake (c=) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:1349
> #3 0x7f42df6c0573 in remote_sasl_free (transport=0x7f42bc05fa90) at
> /home/gordon/projects/dispatch/src/remote_sasl.c:247
> #4 0x7f42df46f1fb in pni_sasl_impl_free (transport=0x7f42bc05fa90) at
> /home/gordon/projects/proton/proton-c/src/sasl/sasl.c:167
> #5 pn_sasl_free (transport=0x7f42bc05fa90) at
> /home/gordon/projects/proton/proton-c/src/sasl/sasl.c:733
> #6 0x7f42df467c70 in pn_transport_finalize (object=0x7f42bc05fa90) at
> /home/gordon/projects/proton/proton-c/src/core/transport.c:664
> #7 0x7f42df4599a9 in pn_class_decref (clazz=0x7f42df681ca0 ,
> clazz@entry=0x7f42df681520 , object=0x7f42bc05fa90) at
> /home/gordon/projects/proton/proton-c/src/core/object/object.c:95
> #8 0x7f42df459bbf in pn_decref (object=) at
> /home/gordon/projects/proton/proton-c/src/core/object/object.c:253
> #9 0x7f42df467911 in pn_transport_free (transport=) at
> /home/gordon/projects/proton/proton-c/src/core/transport.c:643
> #10 0x7f42df4627b4 in pn_connection_driver_destroy
> (d=d@entry=0x7f42bc046538) at
> /home/gordon/projects/proton/proton-c/src/core/connection_driver.c:94
> #11 0x7f42df2426fc in pconnection_final_free (pc=0x7f42bc045f90) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:827
> #12 0x7f42df243404 in pconnection_cleanup (pc=) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:843
> #13 0x7f42df245cdc in pconnection_done (pc=0x7f42bc045f90) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:964
> #14 pn_proactor_done (p=, batch=0x7f42bc046530) at
> /home/gordon/projects/proton/proton-c/src/proactor/epoll.c:2038
> #15 0x7f42df6e8e03 in thread_run (arg=0xa72860) at
> /home/gordon/projects/dispatch/src/server.c:960
> #16 0x7f42df02873a in start_thread () from /lib64/libpthread.so.0
> #17 0x7f42de515e7f in clone () from /lib64/libc.so.6
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-944) remote_sasl plugin leaving connections open
[ https://issues.apache.org/jira/browse/DISPATCH-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399525#comment-16399525 ] ASF subversion and git services commented on DISPATCH-944: -- Commit 0f05f836f12390e898babcac234f176778670493 in qpid-dispatch's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=0f05f83 ] DISPATCH-944: Ensure socket is closed > remote_sasl plugin leaving connections open > --- > > Key: DISPATCH-944 > URL: https://issues.apache.org/jira/browse/DISPATCH-944 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7873) [Broker-J] Delete store notion confused
[ https://issues.apache.org/jira/browse/QPID-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399520#comment-16399520 ] ASF subversion and git services commented on QPID-7873: --- Commit 06f06e4fb8d4afb16355016cfc6e4905652b2f2c in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=06f06e4 ] QPID-7873: [Broker-J] Code clean-up > [Broker-J] Delete store notion confused > --- > > Key: QPID-7873 > URL: https://issues.apache.org/jira/browse/QPID-7873 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > org.apache.qpid.server.store.MessageStore#onDelete > org.apache.qpid.server.store.DurableConfigurationStore#onDelete > org.apache.qpid.server.protocol.v1_0.store.LinkStore#delete > The Java Broker's delete store notion conflates the removal of the structures > from the store (e.g. the removal of a table from a RDBMS, for instance) with > the destruction of the store itself (e.g. removal of Derby or BDB files). We > are also unclear about whether we expect a store to be in an open state when > the store is deleted. > This problem does not currently cause a functional defect. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8121) [Broker-J] Virtualhost scoped statistics messages absent from virtualhost logs
[
https://issues.apache.org/jira/browse/QPID-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399513#comment-16399513
]
ASF subversion and git services commented on QPID-8121:
---
Commit ec5b75bf814330c74f2ce276a5678f34424901b2 in qpid-broker-j's branch
refs/heads/7.0.x from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=ec5b75b ]
QPID-8121: [Broker-J] Include the VirtualHostPrincipal in the Subject used to
execute the StatisticsReportingTask for virtualhosts
(cherry picked from commit 7ab64198e4af7bc01d90756c117d0139151adb4b)
> [Broker-J] Virtualhost scoped statistics messages absent from virtualhost logs
> --
>
> Key: QPID-8121
> URL: https://issues.apache.org/jira/browse/QPID-8121
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.3
>
>
> The virtualhost scoped statistics messages is not being included in logs
> written by {{VirtualHostLoggers}}. It is being included in {{BrokerLoggers}}.
> The defect is simple that the {{StatisticsReportTask}} is running with a
> {{Subject}} that does not include the {{VirtualHostPrincipal}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8121) [Broker-J] Virtualhost scoped statistics messages absent from virtualhost logs
[
https://issues.apache.org/jira/browse/QPID-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8121.
--
Resolution: Fixed
Fix Version/s: qpid-java-broker-7.0.3
> [Broker-J] Virtualhost scoped statistics messages absent from virtualhost logs
> --
>
> Key: QPID-8121
> URL: https://issues.apache.org/jira/browse/QPID-8121
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.3
>
>
> The virtualhost scoped statistics messages is not being included in logs
> written by {{VirtualHostLoggers}}. It is being included in {{BrokerLoggers}}.
> The defect is simple that the {{StatisticsReportTask}} is running with a
> {{Subject}} that does not include the {{VirtualHostPrincipal}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-944) remote_sasl plugin leaving connections open
Gordon Sim created DISPATCH-944: --- Summary: remote_sasl plugin leaving connections open Key: DISPATCH-944 URL: https://issues.apache.org/jira/browse/DISPATCH-944 Project: Qpid Dispatch Issue Type: Bug Reporter: Gordon Sim Assignee: Gordon Sim -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-943) segfault in remote_sasl
Gordon Sim created DISPATCH-943:
---
Summary: segfault in remote_sasl
Key: DISPATCH-943
URL: https://issues.apache.org/jira/browse/DISPATCH-943
Project: Qpid Dispatch
Issue Type: Bug
Reporter: Gordon Sim
Assignee: Gordon Sim
{noformat}
(gdb) bt
#0 0x7f42df02ae00 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1 0x7f42df2435f4 in lock (m=0x18) at
/home/gordon/projects/proton/proton-c/src/proactor/epoll.c:112
#2 pn_connection_wake (c=) at
/home/gordon/projects/proton/proton-c/src/proactor/epoll.c:1349
#3 0x7f42df6c0573 in remote_sasl_free (transport=0x7f42bc05fa90) at
/home/gordon/projects/dispatch/src/remote_sasl.c:247
#4 0x7f42df46f1fb in pni_sasl_impl_free (transport=0x7f42bc05fa90) at
/home/gordon/projects/proton/proton-c/src/sasl/sasl.c:167
#5 pn_sasl_free (transport=0x7f42bc05fa90) at
/home/gordon/projects/proton/proton-c/src/sasl/sasl.c:733
#6 0x7f42df467c70 in pn_transport_finalize (object=0x7f42bc05fa90) at
/home/gordon/projects/proton/proton-c/src/core/transport.c:664
#7 0x7f42df4599a9 in pn_class_decref (clazz=0x7f42df681ca0 ,
clazz@entry=0x7f42df681520 , object=0x7f42bc05fa90) at
/home/gordon/projects/proton/proton-c/src/core/object/object.c:95
#8 0x7f42df459bbf in pn_decref (object=) at
/home/gordon/projects/proton/proton-c/src/core/object/object.c:253
#9 0x7f42df467911 in pn_transport_free (transport=) at
/home/gordon/projects/proton/proton-c/src/core/transport.c:643
#10 0x7f42df4627b4 in pn_connection_driver_destroy
(d=d@entry=0x7f42bc046538) at
/home/gordon/projects/proton/proton-c/src/core/connection_driver.c:94
#11 0x7f42df2426fc in pconnection_final_free (pc=0x7f42bc045f90) at
/home/gordon/projects/proton/proton-c/src/proactor/epoll.c:827
#12 0x7f42df243404 in pconnection_cleanup (pc=) at
/home/gordon/projects/proton/proton-c/src/proactor/epoll.c:843
#13 0x7f42df245cdc in pconnection_done (pc=0x7f42bc045f90) at
/home/gordon/projects/proton/proton-c/src/proactor/epoll.c:964
#14 pn_proactor_done (p=, batch=0x7f42bc046530) at
/home/gordon/projects/proton/proton-c/src/proactor/epoll.c:2038
#15 0x7f42df6e8e03 in thread_run (arg=0xa72860) at
/home/gordon/projects/dispatch/src/server.c:960
#16 0x7f42df02873a in start_thread () from /lib64/libpthread.so.0
#17 0x7f42de515e7f in clone () from /lib64/libc.so.6
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1787) [OSX] Travis CI failure to execute for Xcode 7.3 matrix'd build
[
https://issues.apache.org/jira/browse/PROTON-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-1787.
-
Resolution: Fixed
> [OSX] Travis CI failure to execute for Xcode 7.3 matrix'd build
> ---
>
> Key: PROTON-1787
> URL: https://issues.apache.org/jira/browse/PROTON-1787
> Project: Qpid Proton
> Issue Type: Task
> Environment: Travis CI
>Reporter: Roddie Kieley
>Assignee: Andrew Stitcher
>Priority: Major
>
> Recently the Travis CI build for 'Compiler: gcc Xcode: xcode7.3 C++' started
> failing due to the following:
> {code:java}
> .
> .
> .
> $ export CXX=g++
> $ export CC=gcc
> $ gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 7.3.0 (clang-703.0.31)
> Target: x86_64-apple-darwin15.6.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> before_install.1
> 296.52s$ brew update
> 66.75s$ brew upgrade python openssl
> 0.02s$ pip2 install --user --upgrade pip
> /Users/travis/.travis/job_stages: line 57: pip2: command not found
> The command "pip2 install --user --upgrade pip" failed and exited with 127
> during .
> Your build has been stopped.{code}
>
> This appears to be due to a recent change in homebrew whereby installing
> 'python' installed python 2 but now installs python 3.
> From a previous, working, travis
> [job|https://travis-ci.org/RoddieKieley/qpid-proton/jobs/327960307]
> {code}
> $ brew upgrade python openssl
> ==> Upgrading 2 outdated packages, with result:
> python 2.7.14_2, openssl 1.0.2n
> {code}
> From the latest [job|https://travis-ci.org/apache/qpid-proton/jobs/349877911]
> that's broken:
> {code}
> $ brew upgrade python openssl
> ==> Upgrading 2 outdated packages, with result:
> python 3.6.4_3, openssl 1.0.2n
> {code}
> Looking on http://formulae.brew.sh/ we see:
> {code}
> Recently removed formulae
> python3, php72-opcache, php72-snmp, php72-tidy, php72
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7541) [Java Broker] Close Consumers when a Queue is deleted
[
https://issues.apache.org/jira/browse/QPID-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399427#comment-16399427
]
Keith Wall commented on QPID-7541:
--
Yes - this is certainly a gap and something I would like to fix soon. For AMQP
1.0 connections, I think the Broker ought to be
[detaching|http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-detach]
the link with an appropriate error. The older protocols, AMQP 0-10 and AMQP
0-8..91 didn't really make provision for this. They have a {{message.cancel}}
and {{basic.cancel}} (respectively) but these where defined as sent from a
client to server and not the other way around. For these protocols all that
can be done is to close the session/channel or the close the entire connection.
Artyom, which client library are you using with the Broker?
> [Java Broker] Close Consumers when a Queue is deleted
> -
>
> Key: QPID-7541
> URL: https://issues.apache.org/jira/browse/QPID-7541
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Lorenz Quack
>Priority: Major
>
> Currently when a Queue is deleted the associated Consumers are not closed.
> This is essentially a resource leak.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1787) [OSX] Travis CI failure to execute for Xcode 7.3 matrix'd build
[
https://issues.apache.org/jira/browse/PROTON-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher reassigned PROTON-1787:
---
Assignee: Andrew Stitcher
> [OSX] Travis CI failure to execute for Xcode 7.3 matrix'd build
> ---
>
> Key: PROTON-1787
> URL: https://issues.apache.org/jira/browse/PROTON-1787
> Project: Qpid Proton
> Issue Type: Task
> Environment: Travis CI
>Reporter: Roddie Kieley
>Assignee: Andrew Stitcher
>Priority: Major
>
> Recently the Travis CI build for 'Compiler: gcc Xcode: xcode7.3 C++' started
> failing due to the following:
> {code:java}
> .
> .
> .
> $ export CXX=g++
> $ export CC=gcc
> $ gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 7.3.0 (clang-703.0.31)
> Target: x86_64-apple-darwin15.6.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> before_install.1
> 296.52s$ brew update
> 66.75s$ brew upgrade python openssl
> 0.02s$ pip2 install --user --upgrade pip
> /Users/travis/.travis/job_stages: line 57: pip2: command not found
> The command "pip2 install --user --upgrade pip" failed and exited with 127
> during .
> Your build has been stopped.{code}
>
> This appears to be due to a recent change in homebrew whereby installing
> 'python' installed python 2 but now installs python 3.
> From a previous, working, travis
> [job|https://travis-ci.org/RoddieKieley/qpid-proton/jobs/327960307]
> {code}
> $ brew upgrade python openssl
> ==> Upgrading 2 outdated packages, with result:
> python 2.7.14_2, openssl 1.0.2n
> {code}
> From the latest [job|https://travis-ci.org/apache/qpid-proton/jobs/349877911]
> that's broken:
> {code}
> $ brew upgrade python openssl
> ==> Upgrading 2 outdated packages, with result:
> python 3.6.4_3, openssl 1.0.2n
> {code}
> Looking on http://formulae.brew.sh/ we see:
> {code}
> Recently removed formulae
> python3, php72-opcache, php72-snmp, php72-tidy, php72
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1794) Improve detection strategy for executable python modules
[ https://issues.apache.org/jira/browse/PROTON-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1794. - Resolution: Fixed > Improve detection strategy for executable python modules > > > Key: PROTON-1794 > URL: https://issues.apache.org/jira/browse/PROTON-1794 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, python-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.22.0 > > > We should make sure that detected python modules are actually the ones run by > the detected python interpreter. > Currently we are just checking that the we can find an executable for the > module, but that doesn't ensure that it can actually run using the detected > python. > [This applies to the build system's handling of the tox python module] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8128) [cpp] Link to libqpid-proton-core, not libqpid-proton
[ https://issues.apache.org/jira/browse/QPID-8128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-8128. --- Resolution: Fixed > [cpp] Link to libqpid-proton-core, not libqpid-proton > - > > Key: QPID-8128 > URL: https://issues.apache.org/jira/browse/QPID-8128 > Project: Qpid > Issue Type: Task > Components: C++ Broker, C++ Client >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: qpid-cpp-1.38.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8128) [cpp] Link to libqpid-proton-core, not libqpid-proton
[ https://issues.apache.org/jira/browse/QPID-8128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399399#comment-16399399 ] Justin Ross commented on QPID-8128: --- https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;a=commit;h=b18583a6c05d0bb8cb9502f0823d902e17b2410e > [cpp] Link to libqpid-proton-core, not libqpid-proton > - > > Key: QPID-8128 > URL: https://issues.apache.org/jira/browse/QPID-8128 > Project: Qpid > Issue Type: Task > Components: C++ Broker, C++ Client >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: qpid-cpp-1.38.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8131) [cpp] Fix some problems with the legacystore tests
[ https://issues.apache.org/jira/browse/QPID-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-8131. --- Resolution: Fixed > [cpp] Fix some problems with the legacystore tests > -- > > Key: QPID-8131 > URL: https://issues.apache.org/jira/browse/QPID-8131 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Labels: testing > Fix For: qpid-cpp-1.38.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1794) Improve detection strategy for executable python modules
[ https://issues.apache.org/jira/browse/PROTON-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399392#comment-16399392 ] ASF subversion and git services commented on PROTON-1794: - Commit 6018725aa0266df07b43ff434bba73cffd14fae7 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6018725 ] PROTON-1794: Improve python module detection - Specifically detecting/running tox > Improve detection strategy for executable python modules > > > Key: PROTON-1794 > URL: https://issues.apache.org/jira/browse/PROTON-1794 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, python-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.22.0 > > > We should make sure that detected python modules are actually the ones run by > the detected python interpreter. > Currently we are just checking that the we can find an executable for the > module, but that doesn't ensure that it can actually run using the detected > python. > [This applies to the build system's handling of the tox python module] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1787) [OSX] Travis CI failure to execute for Xcode 7.3 matrix'd build
[
https://issues.apache.org/jira/browse/PROTON-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399393#comment-16399393
]
ASF subversion and git services commented on PROTON-1787:
-
Commit 04d466f36daaaf299f132e9f335ad276995894dd in qpid-proton's branch
refs/heads/master from [~rkieley]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=04d466f ]
PROTON-1787: Fix Travis CI MacOS Python mess
- Based on original work by Roddie Kieley
- Closes #139
> [OSX] Travis CI failure to execute for Xcode 7.3 matrix'd build
> ---
>
> Key: PROTON-1787
> URL: https://issues.apache.org/jira/browse/PROTON-1787
> Project: Qpid Proton
> Issue Type: Task
> Environment: Travis CI
>Reporter: Roddie Kieley
>Priority: Major
>
> Recently the Travis CI build for 'Compiler: gcc Xcode: xcode7.3 C++' started
> failing due to the following:
> {code:java}
> .
> .
> .
> $ export CXX=g++
> $ export CC=gcc
> $ gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 7.3.0 (clang-703.0.31)
> Target: x86_64-apple-darwin15.6.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> before_install.1
> 296.52s$ brew update
> 66.75s$ brew upgrade python openssl
> 0.02s$ pip2 install --user --upgrade pip
> /Users/travis/.travis/job_stages: line 57: pip2: command not found
> The command "pip2 install --user --upgrade pip" failed and exited with 127
> during .
> Your build has been stopped.{code}
>
> This appears to be due to a recent change in homebrew whereby installing
> 'python' installed python 2 but now installs python 3.
> From a previous, working, travis
> [job|https://travis-ci.org/RoddieKieley/qpid-proton/jobs/327960307]
> {code}
> $ brew upgrade python openssl
> ==> Upgrading 2 outdated packages, with result:
> python 2.7.14_2, openssl 1.0.2n
> {code}
> From the latest [job|https://travis-ci.org/apache/qpid-proton/jobs/349877911]
> that's broken:
> {code}
> $ brew upgrade python openssl
> ==> Upgrading 2 outdated packages, with result:
> python 3.6.4_3, openssl 1.0.2n
> {code}
> Looking on http://formulae.brew.sh/ we see:
> {code}
> Recently removed formulae
> python3, php72-opcache, php72-snmp, php72-tidy, php72
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1787) [OSX] Travis CI failure to execute for Xcode 7.3 matrix'd build
[
https://issues.apache.org/jira/browse/PROTON-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399394#comment-16399394
]
ASF GitHub Bot commented on PROTON-1787:
Github user asfgit closed the pull request at:
https://github.com/apache/qpid-proton/pull/139
> [OSX] Travis CI failure to execute for Xcode 7.3 matrix'd build
> ---
>
> Key: PROTON-1787
> URL: https://issues.apache.org/jira/browse/PROTON-1787
> Project: Qpid Proton
> Issue Type: Task
> Environment: Travis CI
>Reporter: Roddie Kieley
>Priority: Major
>
> Recently the Travis CI build for 'Compiler: gcc Xcode: xcode7.3 C++' started
> failing due to the following:
> {code:java}
> .
> .
> .
> $ export CXX=g++
> $ export CC=gcc
> $ gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 7.3.0 (clang-703.0.31)
> Target: x86_64-apple-darwin15.6.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> before_install.1
> 296.52s$ brew update
> 66.75s$ brew upgrade python openssl
> 0.02s$ pip2 install --user --upgrade pip
> /Users/travis/.travis/job_stages: line 57: pip2: command not found
> The command "pip2 install --user --upgrade pip" failed and exited with 127
> during .
> Your build has been stopped.{code}
>
> This appears to be due to a recent change in homebrew whereby installing
> 'python' installed python 2 but now installs python 3.
> From a previous, working, travis
> [job|https://travis-ci.org/RoddieKieley/qpid-proton/jobs/327960307]
> {code}
> $ brew upgrade python openssl
> ==> Upgrading 2 outdated packages, with result:
> python 2.7.14_2, openssl 1.0.2n
> {code}
> From the latest [job|https://travis-ci.org/apache/qpid-proton/jobs/349877911]
> that's broken:
> {code}
> $ brew upgrade python openssl
> ==> Upgrading 2 outdated packages, with result:
> python 3.6.4_3, openssl 1.0.2n
> {code}
> Looking on http://formulae.brew.sh/ we see:
> {code}
> Recently removed formulae
> python3, php72-opcache, php72-snmp, php72-tidy, php72
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7054) Crash when closing a sender after the connection has been closed (with patch).
[ https://issues.apache.org/jira/browse/QPID-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-7054. --- Resolution: Fixed > Crash when closing a sender after the connection has been closed (with patch). > -- > > Key: QPID-7054 > URL: https://issues.apache.org/jira/browse/QPID-7054 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: qpid-cpp-0.34 > Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago) > The broker is ActiveMQ 5.13.0. > The protocol used in AMQP 1.0. >Reporter: Håkan Johansson >Assignee: Justin Ross >Priority: Major > Labels: crash, patch > Fix For: qpid-cpp-1.38.0 > > Attachments: crash_test.cc, qpid-7054.2.patch, qpid-7054.patch > > > There will be a crash if you close your _Sender_ after the _Connection_ has > been closed. > To reproduce, compile and run the attached "crash_test.cc" file. > The test program is very simple. It creates _Connection_, _Session_, and > _Sender_ instances, then closes the connection explicitly followed by closing > the sender. The closing of the sender causes an exception to be thrown as the > connection is dead, but that is caught. > The crash happens when the _Session_ object is destructed at the end of the > test function. This causes the _SenderContext_ from the sender to be > destructed, which tries to close the underlying _pn_link_t_ object to be > freed, but that object refers to a deleted _pn_connection_t_ object. The > exception during _Sender::close_ stopped the proper cleanup to be done. > The _Sender::close_ method calls _ConnectionContext::detach_ to disconnect it > from its session. One problem here is that the _Connection::close_ method > made the connection forget all its sessions, but the sessions still remember > their connection, including the underlying proton objects. The connection > tries to reconnect to the broker and resets its internal connection, causing > the proton connection object to be freed. It then tells all its sessions > about this, but those are forgotten earlier. This means that we end up with > _pn_link_t_ objects that refer to a deleted _pn_connection_t_ object. > I have a attached a patch to this jira which stops the > _ConnectionContext::detach_ method from trying to do remote actions if not > connected. The row numbers in this patch assumes that the patch in QPID-7051 > is already applied, which might cause some offset warnings when applying this > patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #139: PROTON-1787: Pinned the homebrew python versi...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/139 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7999) Relocate distro-specific etc files
[ https://issues.apache.org/jira/browse/QPID-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-7999. --- Resolution: Fixed > Relocate distro-specific etc files > -- > > Key: QPID-7999 > URL: https://issues.apache.org/jira/browse/QPID-7999 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: qpid-cpp-1.38.0 > > > qpidd.in and qpidd-primary.in are Fedora-specific and ought to go in the > etc/fedora dir. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7089) Documentation should point to PPA for Debian/Ubuntu
[ https://issues.apache.org/jira/browse/QPID-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-7089. --- Resolution: Fixed > Documentation should point to PPA for Debian/Ubuntu > --- > > Key: QPID-7089 > URL: https://issues.apache.org/jira/browse/QPID-7089 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 > Environment: Debian/Ubuntu >Reporter: Morgan Lindqvist >Assignee: Justin Ross >Priority: Minor > Labels: easyfix > Fix For: qpid-cpp-1.38.0 > > > On the QPID C++ broker page > (https://qpid.apache.org/components/cpp-broker/index.html) there is a link in > the bottom of the page to "Installing Qpid C++" > (http://svn.apache.org/repos/asf/qpid/tags/qpid-cpp-0.34/qpid/cpp/INSTALL) > This installation instruction do not contain the information that there exist > a PPA for QPID C++ (or rather all of the QPID projects) and that precompiled > binaries can be installed. > The information that should be added is that the page > https://launchpad.net/~qpid contains instructions on how to install both > release and testing packages of QPID C++ broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7499) Define test script dependencies in CMake so make test picks up changes
[ https://issues.apache.org/jira/browse/QPID-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-7499. --- Resolution: Fixed > Define test script dependencies in CMake so make test picks up changes > -- > > Key: QPID-7499 > URL: https://issues.apache.org/jira/browse/QPID-7499 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.35.0 >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Labels: testing > Fix For: qpid-cpp-1.38.0 > > > https://github.com/apache/qpid-cpp/blob/master/src/tests/CMakeLists.txt#L127 > Currently the developer must run cmake again to copy the test scripts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7630) Add a CMake switch to allow -Werror to be switched off
[ https://issues.apache.org/jira/browse/QPID-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-7630. --- Resolution: Fixed > Add a CMake switch to allow -Werror to be switched off > -- > > Key: QPID-7630 > URL: https://issues.apache.org/jira/browse/QPID-7630 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: GNU compilers >Reporter: Chris Richardson >Assignee: Justin Ross >Priority: Major > Labels: patch > Fix For: qpid-cpp-1.38.0 > > Attachments: 1.36.0-disable-warnings-as-errors-switch.patch > > > It could be useful in some situations (eg: when packaging/installing) to be > able to disable warnings as errors in the build. This is the recommendation > for instance of the Gentoo packaging guide > (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section > "-Werror compiler flag not removed"). > See attached patch. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7054) Crash when closing a sender after the connection has been closed (with patch).
[ https://issues.apache.org/jira/browse/QPID-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399383#comment-16399383 ] ASF subversion and git services commented on QPID-7054: --- Commit b2bfd9b2a46d4d4529d9588df762c4a524a3f6a7 in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=b2bfd9b ] QPID-7054: Fix crash when closing a sender after the connection has been closed. Thanks to Håkan Johansson for the patch. > Crash when closing a sender after the connection has been closed (with patch). > -- > > Key: QPID-7054 > URL: https://issues.apache.org/jira/browse/QPID-7054 > Project: Qpid > Issue Type: Bug > Components: C++ Client >Affects Versions: qpid-cpp-0.34 > Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago) > The broker is ActiveMQ 5.13.0. > The protocol used in AMQP 1.0. >Reporter: Håkan Johansson >Assignee: Justin Ross >Priority: Major > Labels: crash, patch > Fix For: qpid-cpp-1.38.0 > > Attachments: crash_test.cc, qpid-7054.2.patch, qpid-7054.patch > > > There will be a crash if you close your _Sender_ after the _Connection_ has > been closed. > To reproduce, compile and run the attached "crash_test.cc" file. > The test program is very simple. It creates _Connection_, _Session_, and > _Sender_ instances, then closes the connection explicitly followed by closing > the sender. The closing of the sender causes an exception to be thrown as the > connection is dead, but that is caught. > The crash happens when the _Session_ object is destructed at the end of the > test function. This causes the _SenderContext_ from the sender to be > destructed, which tries to close the underlying _pn_link_t_ object to be > freed, but that object refers to a deleted _pn_connection_t_ object. The > exception during _Sender::close_ stopped the proper cleanup to be done. > The _Sender::close_ method calls _ConnectionContext::detach_ to disconnect it > from its session. One problem here is that the _Connection::close_ method > made the connection forget all its sessions, but the sessions still remember > their connection, including the underlying proton objects. The connection > tries to reconnect to the broker and resets its internal connection, causing > the proton connection object to be freed. It then tells all its sessions > about this, but those are forgotten earlier. This means that we end up with > _pn_link_t_ objects that refer to a deleted _pn_connection_t_ object. > I have a attached a patch to this jira which stops the > _ConnectionContext::detach_ method from trying to do remote actions if not > connected. The row numbers in this patch assumes that the patch in QPID-7051 > is already applied, which might cause some offset warnings when applying this > patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8131) [cpp] Fix some problems with the legacystore tests
[ https://issues.apache.org/jira/browse/QPID-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399385#comment-16399385 ] ASF subversion and git services commented on QPID-8131: --- Commit 646c3b1b501d5ec701c72d4d34b7caea733a97fa in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=646c3b1 ] QPID-8131: Fix a legacytest build failure and make sure the right tools are on the path for its tests > [cpp] Fix some problems with the legacystore tests > -- > > Key: QPID-8131 > URL: https://issues.apache.org/jira/browse/QPID-8131 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Labels: testing > Fix For: qpid-cpp-1.38.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8128) [cpp] Link to libqpid-proton-core, not libqpid-proton
[ https://issues.apache.org/jira/browse/QPID-8128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399382#comment-16399382 ] ASF subversion and git services commented on QPID-8128: --- Commit 3b6f718deb0d71e194e9ccdd276caea854c97d5d in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=3b6f718 ] QPID-8128: Remove the Proton version warning and raise the minimum version > [cpp] Link to libqpid-proton-core, not libqpid-proton > - > > Key: QPID-8128 > URL: https://issues.apache.org/jira/browse/QPID-8128 > Project: Qpid > Issue Type: Task > Components: C++ Broker, C++ Client >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: qpid-cpp-1.38.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7499) Define test script dependencies in CMake so make test picks up changes
[ https://issues.apache.org/jira/browse/QPID-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399386#comment-16399386 ] ASF subversion and git services commented on QPID-7499: --- Commit 58c0d36310b4c23a009cdbc7ef7a621976e351a2 in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=58c0d36 ] QPID-7499: Fix a cmake syntax error > Define test script dependencies in CMake so make test picks up changes > -- > > Key: QPID-7499 > URL: https://issues.apache.org/jira/browse/QPID-7499 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.35.0 >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Labels: testing > Fix For: qpid-cpp-1.38.0 > > > https://github.com/apache/qpid-cpp/blob/master/src/tests/CMakeLists.txt#L127 > Currently the developer must run cmake again to copy the test scripts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7499) Define test script dependencies in CMake so make test picks up changes
[ https://issues.apache.org/jira/browse/QPID-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399384#comment-16399384 ] ASF subversion and git services commented on QPID-7499: --- Commit 8ceb65eb9c7e6e1c988d9edea5b5539a7559c3d0 in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=8ceb65e ] QPID-7499: Copy test scripts in a way that preserves dependencies > Define test script dependencies in CMake so make test picks up changes > -- > > Key: QPID-7499 > URL: https://issues.apache.org/jira/browse/QPID-7499 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.35.0 >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Labels: testing > Fix For: qpid-cpp-1.38.0 > > > https://github.com/apache/qpid-cpp/blob/master/src/tests/CMakeLists.txt#L127 > Currently the developer must run cmake again to copy the test scripts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7089) Documentation should point to PPA for Debian/Ubuntu
[ https://issues.apache.org/jira/browse/QPID-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399379#comment-16399379 ] ASF subversion and git services commented on QPID-7089: --- Commit 26b6c3730a3672e39fe436811f417e5b04687858 in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=26b6c37 ] QPID-7089: Add a note linking to OS packages > Documentation should point to PPA for Debian/Ubuntu > --- > > Key: QPID-7089 > URL: https://issues.apache.org/jira/browse/QPID-7089 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 > Environment: Debian/Ubuntu >Reporter: Morgan Lindqvist >Assignee: Justin Ross >Priority: Minor > Labels: easyfix > Fix For: qpid-cpp-1.38.0 > > > On the QPID C++ broker page > (https://qpid.apache.org/components/cpp-broker/index.html) there is a link in > the bottom of the page to "Installing Qpid C++" > (http://svn.apache.org/repos/asf/qpid/tags/qpid-cpp-0.34/qpid/cpp/INSTALL) > This installation instruction do not contain the information that there exist > a PPA for QPID C++ (or rather all of the QPID projects) and that precompiled > binaries can be installed. > The information that should be added is that the page > https://launchpad.net/~qpid contains instructions on how to install both > release and testing packages of QPID C++ broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7630) Add a CMake switch to allow -Werror to be switched off
[ https://issues.apache.org/jira/browse/QPID-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399381#comment-16399381 ] ASF subversion and git services commented on QPID-7630: --- Commit 5d28224e6108136284ebef9a23a01d1e226d1404 in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=5d28224 ] QPID-7630: Add a CMake switch to allow -Werror to be switched off > Add a CMake switch to allow -Werror to be switched off > -- > > Key: QPID-7630 > URL: https://issues.apache.org/jira/browse/QPID-7630 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0 > Environment: GNU compilers >Reporter: Chris Richardson >Assignee: Justin Ross >Priority: Major > Labels: patch > Fix For: qpid-cpp-1.38.0 > > Attachments: 1.36.0-disable-warnings-as-errors-switch.patch > > > It could be useful in some situations (eg: when packaging/installing) to be > able to disable warnings as errors in the build. This is the recommendation > for instance of the Gentoo packaging guide > (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section > "-Werror compiler flag not removed"). > See attached patch. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7999) Relocate distro-specific etc files
[ https://issues.apache.org/jira/browse/QPID-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399378#comment-16399378 ] ASF subversion and git services commented on QPID-7999: --- Commit 88d08be32de9b6233fcad02539b9dcf303e4b16b in qpid-cpp's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=88d08be ] QPID-7999: Move Fedora-specific init scripts to the fedora dir; disable their installation, but keep them in the build output so packagers can pick them up as needed > Relocate distro-specific etc files > -- > > Key: QPID-7999 > URL: https://issues.apache.org/jira/browse/QPID-7999 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker, C++ Client >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: qpid-cpp-1.38.0 > > > qpidd.in and qpidd-primary.in are Fedora-specific and ought to go in the > etc/fedora dir. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-cpp pull request #12: WIP - A batch of C++ updates
Github user asfgit closed the pull request at: https://github.com/apache/qpid-cpp/pull/12 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399365#comment-16399365 ] Alan Conway commented on PROTON-1791: - It is interesting that the workaround works, but it is an accident and may not be reliable. In the recent rework of the ruby IO code, heartbeats and scheduled tasks did not get finished. If something is waking up the select loop often enough, then the heartbeat frames will be sent - but there's nothing in the library waking it up on purpose. The fact that this workaround works may mean there is excessive activity on the container's wake pipe, which I will also investigate. As far as workarounds - any regular activity will do, you can run a keepalive thread to poke the connection. You can use c.idle_timeout to find out what the remote end has requested. You don't need to send a message, probably better to do something with minimal side-effects, maybe open and close a dummy session. I'm working on this now, should have a proper fix soon... > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > Attachments: idle-disconnect.png > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 717u IPv4 584387 0t0 TCP > 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT) > ... > I think the CLOSE_WAIT status of file descriptor indicates that the TCP > connection has already been closed, but the file descriptor
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399348#comment-16399348 ] Jiri Daněk commented on PROTON-1791: It is a workaround, it is supposed to request the broker to send you empty frame every 5s (when set to 10), but I saw that it also caused the client to send empty frame to the broker every 30s (exactly as the broker asked). I am using my own build based on commit f1100fea2b67538b2 from Mar 7, that is a version after the 0.21 release (( > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > Attachments: idle-disconnect.png > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 717u IPv4 584387 0t0 TCP > 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT) > ... > I think the CLOSE_WAIT status of file descriptor indicates that the TCP > connection has already been closed, but the file descriptor wasn't closed. > After 9 hours or so there are enough of such file descriptors for OS to > complain about it. > We did all we could to close connections gracefully: > connection.container.stop > connection.close > connection = nil > but nothing seems to help. A simple but expensive workaround is to manually > invoke Ruby's garbage collection, > but ideally `connection.close` would close the file descriptor. > May I kindly ask you to look at this? > Thank you and Best Regards, > Miha > PS: The error occurs both on
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[
https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399242#comment-16399242
]
Miha Plesko commented on PROTON-1791:
-
[~jdanek] I've been trying to use the
{code:java}
:idle_timeout => 10{code}
in past days but it didn't seem to change anything. What gem version is it
supported in?
> TCP sockets remain open in CLOSE_WAIT state
> ---
>
> Key: PROTON-1791
> URL: https://issues.apache.org/jira/browse/PROTON-1791
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Affects Versions: proton-c-0.21.0
> Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4
> Confirmed on qpid_proton 0.19.0 and 0.21.0
>Reporter: Miha Plesko
>Assignee: Alan Conway
>Priority: Major
> Labels: bug
> Fix For: proton-c-0.22.0
>
> Attachments: idle-disconnect.png
>
>
> Hi guys,
> thanks for developing the awesome qpid_proton ruby gem, we're using it on
> daily basis!
> However, recently we noticed following error in our server log:
> Too many open files - socket(2) for "172.16.117.189" port 5672
> After some research it turns out that qpid_proton process is having
> increasingly
> more and more following file descriptors open:
> $ lsof -ap 108533
> ruby108533 miha 116u IPv4 562438 0t0 TCP
> 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 197u IPv4 561644 0t0 TCP
> 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 311u IPv4 560657 0t0 TCP
> 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 549u IPv4 565342 0t0 TCP
> 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 576u IPv4 565122 0t0 TCP
> 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 603u IPv4 565738 0t0 TCP
> 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 630u IPv4 563021 0t0 TCP
> 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 657u IPv4 568361 0t0 TCP
> 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 666u IPv4 563027 0t0 TCP
> 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 675u IPv4 567538 0t0 TCP
> 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 684u IPv4 567998 0t0 TCP
> 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 690u IPv4 574709 0t0 TCP
> 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 693u IPv4 578725 0t0 TCP
> 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 696u IPv4 576840 0t0 TCP
> 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 699u IPv4 577819 0t0 TCP
> 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 702u IPv4 582192 0t0 TCP
> 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 705u IPv4 582861 0t0 TCP
> 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 708u IPv4 577363 0t0 TCP
> 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 711u IPv4 578175 0t0 TCP
> 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 714u IPv4 587172 0t0 TCP
> 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 717u IPv4 584387 0t0 TCP
> 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT)
> ...
> I think the CLOSE_WAIT status of file descriptor indicates that the TCP
> connection has already been closed, but the file descriptor wasn't closed.
> After 9 hours or so there are enough of such file descriptors for OS to
> complain about it.
> We did all we could to close connections gracefully:
> connection.container.stop
> connection.close
> connection = nil
> but nothing seems to help. A simple but expensive workaround is to manually
> invoke Ruby's garbage collection,
> but ideally `connection.close` would close the file descriptor.
> May I kindly ask you to look at this?
> Thank you and Best Regards,
> Miha
> PS: The error occurs both on Ubuntu 16.04 and RHEL 7.4
> PS2: The error occurs both on qpid_proton 0.19.0 and 0.21.0
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[
https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399197#comment-16399197
]
Jiri Daněk commented on PROTON-1791:
[~miha-plesko] I've commented about a workaround on PROTON-1793. What the
{{--conn-heartbeat 10}} option there does is just
{{container.connect(idle_timeout: 10, ...),
https://github.com/jdanekrh/cli-proton-ruby/blob/0beb0a6791a551e3d4b1afb952064a6ab52094b2/lib/handlers/connector_handler.rb#L58
> TCP sockets remain open in CLOSE_WAIT state
> ---
>
> Key: PROTON-1791
> URL: https://issues.apache.org/jira/browse/PROTON-1791
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Affects Versions: proton-c-0.21.0
> Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4
> Confirmed on qpid_proton 0.19.0 and 0.21.0
>Reporter: Miha Plesko
>Assignee: Alan Conway
>Priority: Major
> Labels: bug
> Fix For: proton-c-0.22.0
>
> Attachments: idle-disconnect.png
>
>
> Hi guys,
> thanks for developing the awesome qpid_proton ruby gem, we're using it on
> daily basis!
> However, recently we noticed following error in our server log:
> Too many open files - socket(2) for "172.16.117.189" port 5672
> After some research it turns out that qpid_proton process is having
> increasingly
> more and more following file descriptors open:
> $ lsof -ap 108533
> ruby108533 miha 116u IPv4 562438 0t0 TCP
> 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 197u IPv4 561644 0t0 TCP
> 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 311u IPv4 560657 0t0 TCP
> 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 549u IPv4 565342 0t0 TCP
> 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 576u IPv4 565122 0t0 TCP
> 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 603u IPv4 565738 0t0 TCP
> 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 630u IPv4 563021 0t0 TCP
> 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 657u IPv4 568361 0t0 TCP
> 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 666u IPv4 563027 0t0 TCP
> 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 675u IPv4 567538 0t0 TCP
> 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 684u IPv4 567998 0t0 TCP
> 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 690u IPv4 574709 0t0 TCP
> 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 693u IPv4 578725 0t0 TCP
> 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 696u IPv4 576840 0t0 TCP
> 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 699u IPv4 577819 0t0 TCP
> 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 702u IPv4 582192 0t0 TCP
> 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 705u IPv4 582861 0t0 TCP
> 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 708u IPv4 577363 0t0 TCP
> 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 711u IPv4 578175 0t0 TCP
> 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 714u IPv4 587172 0t0 TCP
> 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT)
> ruby108533 miha 717u IPv4 584387 0t0 TCP
> 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT)
> ...
> I think the CLOSE_WAIT status of file descriptor indicates that the TCP
> connection has already been closed, but the file descriptor wasn't closed.
> After 9 hours or so there are enough of such file descriptors for OS to
> complain about it.
> We did all we could to close connections gracefully:
> connection.container.stop
> connection.close
> connection = nil
> but nothing seems to help. A simple but expensive workaround is to manually
> invoke Ruby's garbage collection,
> but ideally `connection.close` would close the file descriptor.
> May I kindly ask you to look at this?
> Thank you and Best Regards,
> Miha
> PS: The error occurs both on Ubuntu 16.04 and RHEL 7.4
> PS2: The error
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399181#comment-16399181 ] Miha Plesko commented on PROTON-1791: - Thanks for lightning fast reply [~aconway] and [~astitcher]! Since I don't want to be pushing you guys too much with "please fix this issue today and release 0.22.0 version tomorrow" :) I'd kindly ask for some help to workaround it for the deadline I'm catching (we're using 0.19.0 version ATM). Basically what I have is a MessagingHandler ([https://github.com/ManageIQ/manageiq-providers-nuage/blob/master/app/models/manageiq/providers/nuage/network_manager/event_catcher/messaging_handler.rb]) that is receiving messages. And it's getting disconnected. If I understand correctly I need to open a sender for each topic as well (alongside receiver) like this [https://github.com/apache/qpid-proton/blob/master/examples/ruby/simple_send.rb#L36] and implement on_sendable callback like this [https://github.com/apache/qpid-proton/blob/master/examples/ruby/simple_send.rb#L39-L45] where I send some dummy message every 5 seconds. Please correct me if I'm wrong or if there is some additional method I need to implement. And thanks again for your help. > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > Attachments: idle-disconnect.png > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 717u IPv4 584387 0t0
[jira] [Commented] (PROTON-1793) [ruby] not sending heartbeat frames to respect idle-timeout
[
https://issues.apache.org/jira/browse/PROTON-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399180#comment-16399180
]
Jiri Daněk commented on PROTON-1793:
Strangely, if you request heartbeats from your peer, and the period is less
than what the peer requested from us, the heartbeats start going in both
directions. This could be a workaround,
{noformat}
$ PN_TRACE_FRM=1 cli-proton-ruby-receiver -c 0 --log-msgs dict --broker
amqp://127.0.0.1:5672/lala --conn-heartbeat 10
[0x1fab9f0]: -> SASL
[0x1fab9f0]: <- SASL
[0x1fab9f0]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
[0x1fab9f0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
initial-response=b"anonymous@nixos"]
[0x1fab9f0]:0 <- @sasl-outcome(68) [code=0]
[0x1fab9f0]: <- AMQP
[0x1fab9f0]: -> AMQP
[0x1fab9f0]:0 -> @open(16)
[container-id="7b5d5572-8f69-43d8-a3af-a5168a3a31bd", channel-max=32767,
idle-time-out=5000]
[0x1fab9f0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
[0x1fab9f0]:0 -> @attach(18) [name="7b5d5572-8f69-43d8-a3af-a5168a3a31bd/1",
handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="lala", durable=0, timeout=0, dynamic=false], target=@target(41)
[durable=0, timeout=0, dynamic=false], initial-delivery-count=0,
max-message-size=0]
[0x1fab9f0]:0 <- @open(16) [container-id="amq", max-frame-size=4294967295,
channel-max=65535, idle-time-out=3,
offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container",
:"DELAYED_DELIVERY", :"SHARED-SUBS", :"ANONYMOUS-RELAY"],
properties={:product="apache-activemq-artemis",
:version="2.4.0.amq-710004-redhat-1"}]
[0x1fab9f0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
incoming-window=2147483647, outgoing-window=2147483647, handle-max=65535]
[0x1fab9f0]:0 <- @attach(18) [name="7b5d5572-8f69-43d8-a3af-a5168a3a31bd/1",
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="lala"], target=@target(41) [], incomplete-unsettled=false,
initial-delivery-count=0]
[0x1fab9f0]:0 -> @flow(19) [next-incoming-id=1, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
link-credit=10, drain=false]
[0x1fab9f0]:0 <- (EMPTY FRAME)
[0x1fab9f0]:0 <- (EMPTY FRAME)
[0x1fab9f0]:0 <- (EMPTY FRAME)
[0x1fab9f0]:0 <- (EMPTY FRAME)
[0x1fab9f0]:0 <- (EMPTY FRAME)
[0x1fab9f0]:0 <- (EMPTY FRAME)
[0x1fab9f0]:0 <- (EMPTY FRAME)
[0x1fab9f0]:0 -> (EMPTY FRAME)<- HERE
[0x1fab9f0]:0 <- (EMPTY FRAME)
[0x1fab9f0]:0 <- (EMPTY FRAME)
[...]
{noformat}
> [ruby] not sending heartbeat frames to respect idle-timeout
> ---
>
> Key: PROTON-1793
> URL: https://issues.apache.org/jira/browse/PROTON-1793
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Affects Versions: proton-c-0.21.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.22.0
>
>
> The ruby library does not send heartbeat frames when the remote end of a
> connection requests an idle-timeout.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399159#comment-16399159 ] Andrew Stitcher commented on PROTON-1791: - [~aconway] I should read your comments more closely! > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > Attachments: idle-disconnect.png > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 717u IPv4 584387 0t0 TCP > 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT) > ... > I think the CLOSE_WAIT status of file descriptor indicates that the TCP > connection has already been closed, but the file descriptor wasn't closed. > After 9 hours or so there are enough of such file descriptors for OS to > complain about it. > We did all we could to close connections gracefully: > connection.container.stop > connection.close > connection = nil > but nothing seems to help. A simple but expensive workaround is to manually > invoke Ruby's garbage collection, > but ideally `connection.close` would close the file descriptor. > May I kindly ask you to look at this? > Thank you and Best Regards, > Miha > PS: The error occurs both on Ubuntu 16.04 and RHEL 7.4 > PS2: The error occurs both on qpid_proton 0.19.0 and 0.21.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For
[jira] [Created] (PROTON-1794) Improve detection strategy for executable python modules
Andrew Stitcher created PROTON-1794: --- Summary: Improve detection strategy for executable python modules Key: PROTON-1794 URL: https://issues.apache.org/jira/browse/PROTON-1794 Project: Qpid Proton Issue Type: Improvement Components: proton-c, python-binding Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: proton-c-0.22.0 We should make sure that detected python modules are actually the ones run by the detected python interpreter. Currently we are just checking that the we can find an executable for the module, but that doesn't ensure that it can actually run using the detected python. [This applies to the build system's handling of the tox python module] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1793) [ruby] not sending heartbeat frames to respect idle-timeout
[ https://issues.apache.org/jira/browse/PROTON-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed PROTON-1793. --- Resolution: Duplicate > [ruby] not sending heartbeat frames to respect idle-timeout > --- > > Key: PROTON-1793 > URL: https://issues.apache.org/jira/browse/PROTON-1793 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.22.0 > > > The ruby library does not send heartbeat frames when the remote end of a > connection requests an idle-timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399156#comment-16399156 ] Alan Conway commented on PROTON-1791: - [~astitcher] this is a bug in the ruby client - it should be honouring heartbeats but isn't. > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > Attachments: idle-disconnect.png > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 717u IPv4 584387 0t0 TCP > 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT) > ... > I think the CLOSE_WAIT status of file descriptor indicates that the TCP > connection has already been closed, but the file descriptor wasn't closed. > After 9 hours or so there are enough of such file descriptors for OS to > complain about it. > We did all we could to close connections gracefully: > connection.container.stop > connection.close > connection = nil > but nothing seems to help. A simple but expensive workaround is to manually > invoke Ruby's garbage collection, > but ideally `connection.close` would close the file descriptor. > May I kindly ask you to look at this? > Thank you and Best Regards, > Miha > PS: The error occurs both on Ubuntu 16.04 and RHEL 7.4 > PS2: The error occurs both on qpid_proton 0.19.0 and 0.21.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail:
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399152#comment-16399152 ] Andrew Stitcher commented on PROTON-1791: - [~miha-plesko] I'm not 100% sure, but I think you are running into a configuration of ActiveMQ designed to limit the number of clients that are inactive and "hogging" a connection. I don't think it's an issue with sending heartbeats, as all the clients should be correctly honouring the negotiated heartbeat settings > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > Attachments: idle-disconnect.png > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 717u IPv4 584387 0t0 TCP > 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT) > ... > I think the CLOSE_WAIT status of file descriptor indicates that the TCP > connection has already been closed, but the file descriptor wasn't closed. > After 9 hours or so there are enough of such file descriptors for OS to > complain about it. > We did all we could to close connections gracefully: > connection.container.stop > connection.close > connection = nil > but nothing seems to help. A simple but expensive workaround is to manually > invoke Ruby's garbage collection, > but ideally `connection.close` would close the file descriptor. > May I kindly ask you to look at this? > Thank you and Best Regards, > Miha > PS: The error occurs both on Ubuntu 16.04
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399148#comment-16399148 ] Alan Conway commented on PROTON-1791: - Q: Do you happen to know why ActiveMQ would be sending us "local-idle-timeout expired" error every 2 minutes? Does qpid_proton gem not send heartbeats and ActiveMQ thinks we're dead? Looking at this comment here https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/core/container.rb#L271 the explanation seems quite possible. A: yes, someone else recently spotted this - PROTON-1793 I'm working on it now. Q2: Assuming the core problem is that qpid_proton isn't sending heartbeat, is there an easy workaround for this? Would manually opening a sender and send some dummy message to the ActiveMQ help? A: Yes - any activity at all on the connection will keep it alive. Just opening/closing a sender would do it, no message required. > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > Attachments: idle-disconnect.png > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 717u IPv4 584387 0t0 TCP > 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT) > ... > I think the CLOSE_WAIT status of file descriptor indicates that the TCP > connection has already been closed, but the file descriptor wasn't closed. > After 9 hours or so there are enough of such file descriptors for OS to >
[jira] [Created] (PROTON-1793) [ruby] not sending heartbeat frames to respect idle-timeout
Alan Conway created PROTON-1793: --- Summary: [ruby] not sending heartbeat frames to respect idle-timeout Key: PROTON-1793 URL: https://issues.apache.org/jira/browse/PROTON-1793 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: proton-c-0.21.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.22.0 The ruby library does not send heartbeat frames when the remote end of a connection requests an idle-timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399135#comment-16399135 ] Miha Plesko commented on PROTON-1791: - Attaching the WireShark capture of the traffic. 172.16.117.189 is IP address of the client. !idle-disconnect.png! > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > Attachments: idle-disconnect.png > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 717u IPv4 584387 0t0 TCP > 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT) > ... > I think the CLOSE_WAIT status of file descriptor indicates that the TCP > connection has already been closed, but the file descriptor wasn't closed. > After 9 hours or so there are enough of such file descriptors for OS to > complain about it. > We did all we could to close connections gracefully: > connection.container.stop > connection.close > connection = nil > but nothing seems to help. A simple but expensive workaround is to manually > invoke Ruby's garbage collection, > but ideally `connection.close` would close the file descriptor. > May I kindly ask you to look at this? > Thank you and Best Regards, > Miha > PS: The error occurs both on Ubuntu 16.04 and RHEL 7.4 > PS2: The error occurs both on qpid_proton 0.19.0 and 0.21.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To
[jira] [Updated] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miha Plesko updated PROTON-1791: Attachment: idle-disconnect.png > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > Attachments: idle-disconnect.png > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 717u IPv4 584387 0t0 TCP > 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT) > ... > I think the CLOSE_WAIT status of file descriptor indicates that the TCP > connection has already been closed, but the file descriptor wasn't closed. > After 9 hours or so there are enough of such file descriptors for OS to > complain about it. > We did all we could to close connections gracefully: > connection.container.stop > connection.close > connection = nil > but nothing seems to help. A simple but expensive workaround is to manually > invoke Ruby's garbage collection, > but ideally `connection.close` would close the file descriptor. > May I kindly ask you to look at this? > Thank you and Best Regards, > Miha > PS: The error occurs both on Ubuntu 16.04 and RHEL 7.4 > PS2: The error occurs both on qpid_proton 0.19.0 and 0.21.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-365) [Failover] failover.reconnectDelay not applied between connection attempts if peer Closes gracefully
[
https://issues.apache.org/jira/browse/QPIDJMS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399132#comment-16399132
]
ASF subversion and git services commented on QPIDJMS-365:
-
Commit daec046413b349f7187ed8490b9a6376c581c848 in qpid-jms's branch
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=daec046 ]
QPIDJMS-365 Correct failover reconnect delays when remote closes
Remember reconnect delay state until the connection is fully reconnected
to avoid restarting delay processing when the remote closes cleanly
after an initial open attempt due to some condition on the remote. Adds
additional error handling and logging as well as some refactoring of the
overall reconnect handling logic.
> [Failover] failover.reconnectDelay not applied between connection attempts if
> peer Closes gracefully
>
>
> Key: QPIDJMS-365
> URL: https://issues.apache.org/jira/browse/QPIDJMS-365
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
>
> When using Broker-J's High Availability feature, the client's failover
> abilities are used to allow the client to discover which Broker in the HA
> group has the master role. The client tries each Broker on the failover list
> until until one successfully responds to the {{Open}} indicating that it is
> current master.
>
> When a node is not in the master role, it gracefully closes the AMQP
> connection by sending a {{Close}} performative. During election periods, it
> is normal for all nodes in the HA group to respond with the {{Close}} until
> the election concludes.
> {noformat}
> Close{error=Error{condition=amqp:not-found, description='Virtual host
> 'localhost' is not active', info=null}}
> {noformat}
> The QpidJMS Client failover options includes a {{failover.reconnectDelay}}
> which "Controls the delay between successive reconnection attempts".
> However it appears that the reconnection delay is only applied between
> attempts when a connection fails owing to a 'transport' level failure
> (connection refused etc). If the connection fails at the AMQP level, the
> delay is not applied.
> This is impactful to the HA use-case for Broker-J. It means that during
> periods of reelection, the client, tightly spins in the reconnection loop,
> excessively consuming system resources. It is also necessary to ensure that
> {{failover.maxReconnectAttempts}} is set sufficiently large to allow for an
> election period to conclude successfully. Whilst the user could use
> unlimited reconnection attempts, this is unpleasant as it means the system
> won't fail in the case where the election does not conclude within a
> reasonable time period.
> Extract of TRACE level logging from
> {{org.apache.qpid.jms.provider.failover.FailoverProvider}} for the case when
> a AMQP connection is closed gracefully ({{Close}} performative):
> {noformat}
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- Failover: the provider reports failure: Connection closed by external
> action [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- handling Provider failure: Connection closed by external action
> [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - TRACE FailoverProvider
>- stack
> java.io.IOException: Connection closed by external action [condition =
> amqp:connection:forced]
> at
> org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.fireProviderException(AmqpProvider.java:1086)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.closeResource(AmqpAbstractResource.java:182)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:949)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:104)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:831)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
>
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399116#comment-16399116 ] Miha Plesko commented on PROTON-1791: - Thanks [~aconway], will try your patch tomorrow when I return to my office, but I think it should work since it's the same as my current workaround (see previous comment). Let me quickly explain how we're able to reproduce the problem. So we're being disconnected from ActiveMQ because of "amqp:resource-limit-exceeded: local-idle-timeout expired" error every 2 minutes or so and we create a new container immediately on error (in a loop). Then the sockets get stucked as described above. Q: Do you happen to know why ActiveMQ would be sending us "local-idle-timeout expired" error every 2 minutes? Does qpid_proton gem not send heartbeats and ActiveMQ thinks we're dead? Looking at this comment here https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/core/container.rb#L271 the explanation seems quite possible. Q2: Assuming the core problem is that qpid_proton isn't sending heartbeat, is there an easy workaround for this? Would manually opening a sender and send some dummy message to the ActiveMQ help? I thank you in advance, we're in great hurry for this issue to be resolved (this week) so I kindly ask for a quick reply. Regards, Miha > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp
[jira] [Created] (QPID-8131) [cpp] Fix some problems with the legacystore tests
Justin Ross created QPID-8131: - Summary: [cpp] Fix some problems with the legacystore tests Key: QPID-8131 URL: https://issues.apache.org/jira/browse/QPID-8131 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Justin Ross Assignee: Justin Ross Fix For: qpid-cpp-1.38.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398937#comment-16398937 ] Alan Conway edited comment on PROTON-1791 at 3/14/18 5:29 PM: -- [~miha-plesko]Please try the fix at: https://github.com/alanconway/qpid-proton/tree/ruby-close-fd It's a one-line fix and looks a lot like it might be your problem (proton was doing IO#close_read and close_write but never actually IO#close) However I haven't reproduced the problem yet, so if that does not fix things for you I need some more info on how you produce the problem. Ideally if you can isolate some example code to demonstrate the problem, or if you can, show me the code you're using and the steps you take to see it. I have tried using the proton examples/ruby programs to create many connections to a broker.rb and disconnect them, but lsof does not show file descriptors piling up. I also tried writing a test client that creates connections and closes them in a variety of ways, killing processes with open connections etc. Probably there is some specific tear-down sequence that is causing the problem for you that I have not hit on. Also your ruby and OS versions may be relevant. Thanks! Alan. was (Author: aconway): Please try the fix at: https://github.com/alanconway/qpid-proton/tree/ruby-close-fd It's a one-line fix and looks a lot like it might be your problem (proton was doing IO#close_read and close_write but never actually IO#close) However I haven't reproduced the problem yet, so if that does not fix things for you I need some more info on how you are produce the problem. Ideally if you can isolate some example code to demonstrate the problem, or if you can, show me the code you're using and the steps you take to see it. I have tried using the proton examples/ruby programs to create many connections to a broker.rb and disconnect them, but lsof does not show file descriptors piling up. I also tried writing a test client that creates connections and closes them in a variety of ways, killing processes with open connections etc. Probably there is some specific tear-down sequence that is causing the problem for you that I have not hit on. Also your ruby and OS versions may be relevant. Thanks! Alan. > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP >
[jira] [Commented] (PROTON-1791) TCP sockets remain open in CLOSE_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398937#comment-16398937 ] Alan Conway commented on PROTON-1791: - Please try the fix at: https://github.com/alanconway/qpid-proton/tree/ruby-close-fd It's a one-line fix and looks a lot like it might be your problem (proton was doing IO#close_read and close_write but never actually IO#close) However I haven't reproduced the problem yet, so if that does not fix things for you I need some more info on how you are produce the problem. Ideally if you can isolate some example code to demonstrate the problem, or if you can, show me the code you're using and the steps you take to see it. I have tried using the proton examples/ruby programs to create many connections to a broker.rb and disconnect them, but lsof does not show file descriptors piling up. I also tried writing a test client that creates connections and closes them in a variety of ways, killing processes with open connections etc. Probably there is some specific tear-down sequence that is causing the problem for you that I have not hit on. Also your ruby and OS versions may be relevant. Thanks! Alan. > TCP sockets remain open in CLOSE_WAIT state > --- > > Key: PROTON-1791 > URL: https://issues.apache.org/jira/browse/PROTON-1791 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.21.0 > Environment: Confirmed on Ubuntu 16.04 and RHEL 7.4 > Confirmed on qpid_proton 0.19.0 and 0.21.0 >Reporter: Miha Plesko >Assignee: Alan Conway >Priority: Major > Labels: bug > Fix For: proton-c-0.22.0 > > > Hi guys, > thanks for developing the awesome qpid_proton ruby gem, we're using it on > daily basis! > However, recently we noticed following error in our server log: > Too many open files - socket(2) for "172.16.117.189" port 5672 > After some research it turns out that qpid_proton process is having > increasingly > more and more following file descriptors open: > $ lsof -ap 108533 > ruby108533 miha 116u IPv4 562438 0t0 TCP > 172.16.117.189:53626->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 197u IPv4 561644 0t0 TCP > 172.16.117.189:53630->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 311u IPv4 560657 0t0 TCP > 172.16.117.189:53634->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 549u IPv4 565342 0t0 TCP > 172.16.117.189:53642->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 576u IPv4 565122 0t0 TCP > 172.16.117.189:53650->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 603u IPv4 565738 0t0 TCP > 172.16.117.189:53654->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 630u IPv4 563021 0t0 TCP > 172.16.117.189:53658->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 657u IPv4 568361 0t0 TCP > 172.16.117.189:53662->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 666u IPv4 563027 0t0 TCP > 172.16.117.189:53666->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 675u IPv4 567538 0t0 TCP > 172.16.117.189:53670->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 684u IPv4 567998 0t0 TCP > 172.16.117.189:53678->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 690u IPv4 574709 0t0 TCP > 172.16.117.189:53686->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 693u IPv4 578725 0t0 TCP > 172.16.117.189:53694->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 696u IPv4 576840 0t0 TCP > 172.16.117.189:53698->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 699u IPv4 577819 0t0 TCP > 172.16.117.189:53702->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 702u IPv4 582192 0t0 TCP > 172.16.117.189:53710->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 705u IPv4 582861 0t0 TCP > 172.16.117.189:53714->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 708u IPv4 577363 0t0 TCP > 172.16.117.189:53718->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 711u IPv4 578175 0t0 TCP > 172.16.117.189:53722->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 714u IPv4 587172 0t0 TCP > 172.16.117.189:53730->147.75.102.132:amqp (CLOSE_WAIT) > ruby108533 miha 717u IPv4 584387 0t0 TCP > 172.16.117.189:53734->147.75.102.132:amqp (CLOSE_WAIT) > ... > I think the
[jira] [Commented] (QPID-7541) [Java Broker] Close Consumers when a Queue is deleted
[ https://issues.apache.org/jira/browse/QPID-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398854#comment-16398854 ] Artyom Safronov commented on QPID-7541: --- Recently I found a strange behavior in my opinion. A queue was deleted but my client was not notified about this event. Is it normal situation? Should not the broker send "CLOSE" frame to a receiver/sender? > [Java Broker] Close Consumers when a Queue is deleted > - > > Key: QPID-7541 > URL: https://issues.apache.org/jira/browse/QPID-7541 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Lorenz Quack >Priority: Major > > Currently when a Queue is deleted the associated Consumers are not closed. > This is essentially a resource leak. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-367) Add support for XOAUTH2 Sasl Autentication
[ https://issues.apache.org/jira/browse/QPIDJMS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-367. Resolution: Fixed Fix Version/s: 0.31.0 > Add support for XOAUTH2 Sasl Autentication > -- > > Key: QPIDJMS-367 > URL: https://issues.apache.org/jira/browse/QPIDJMS-367 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Rob Godfrey >Assignee: Rob Godfrey >Priority: Major > Fix For: 0.31.0 > > > [https://developers.google.com/gmail/imap/xoauth2-protocol] defines a SASL > mechanism which allows for authentication using an OAUTH2 Acess Token. This > mechanism is supported by Qpid Broker-J and it would be useful if the Qpid > JMS client could connect using this mechanism. > The mechanics of the mechanism pass a username and token, the latter > essentially being equivalent to a password for these purposes. The Token > MUST be provided as a Base64 encoded string (the contents of which are a > token in JSON format, though this detail is opaque to the client). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPIDJMS-367) Add support for XOAUTH2 Sasl Autentication
[ https://issues.apache.org/jira/browse/QPIDJMS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPIDJMS-367: -- Assignee: Rob Godfrey > Add support for XOAUTH2 Sasl Autentication > -- > > Key: QPIDJMS-367 > URL: https://issues.apache.org/jira/browse/QPIDJMS-367 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Rob Godfrey >Assignee: Rob Godfrey >Priority: Major > > [https://developers.google.com/gmail/imap/xoauth2-protocol] defines a SASL > mechanism which allows for authentication using an OAUTH2 Acess Token. This > mechanism is supported by Qpid Broker-J and it would be useful if the Qpid > JMS client could connect using this mechanism. > The mechanics of the mechanism pass a username and token, the latter > essentially being equivalent to a password for these purposes. The Token > MUST be provided as a Base64 encoded string (the contents of which are a > token in JSON format, though this detail is opaque to the client). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-367) Add support for XOAUTH2 Sasl Autentication
[ https://issues.apache.org/jira/browse/QPIDJMS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398750#comment-16398750 ] ASF subversion and git services commented on QPIDJMS-367: - Commit 39570cfbf9866c94727d9aa57fed0076976605c8 in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=39570cf ] QPIDJMS-367: tweak doc slightly > Add support for XOAUTH2 Sasl Autentication > -- > > Key: QPIDJMS-367 > URL: https://issues.apache.org/jira/browse/QPIDJMS-367 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Rob Godfrey >Priority: Major > > [https://developers.google.com/gmail/imap/xoauth2-protocol] defines a SASL > mechanism which allows for authentication using an OAUTH2 Acess Token. This > mechanism is supported by Qpid Broker-J and it would be useful if the Qpid > JMS client could connect using this mechanism. > The mechanics of the mechanism pass a username and token, the latter > essentially being equivalent to a password for these purposes. The Token > MUST be provided as a Base64 encoded string (the contents of which are a > token in JSON format, though this detail is opaque to the client). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-367) Add support for XOAUTH2 Sasl Autentication
[ https://issues.apache.org/jira/browse/QPIDJMS-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398668#comment-16398668 ] ASF subversion and git services commented on QPIDJMS-367: - Commit 3d2ec9c5fc65d512418b21086ee6a59a00bb2df4 in qpid-jms's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=3d2ec9c ] QPIDJMS-367 : Add support for XOAUTH2 Sasl Autentication > Add support for XOAUTH2 Sasl Autentication > -- > > Key: QPIDJMS-367 > URL: https://issues.apache.org/jira/browse/QPIDJMS-367 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Rob Godfrey >Priority: Major > > [https://developers.google.com/gmail/imap/xoauth2-protocol] defines a SASL > mechanism which allows for authentication using an OAUTH2 Acess Token. This > mechanism is supported by Qpid Broker-J and it would be useful if the Qpid > JMS client could connect using this mechanism. > The mechanics of the mechanism pass a username and token, the latter > essentially being equivalent to a password for these purposes. The Token > MUST be provided as a Base64 encoded string (the contents of which are a > token in JSON format, though this detail is opaque to the client). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8130) [Broker-J] IAE "Comparison method violates its general contract!" can be thrown whilst comparing log file details of file logger
[
https://issues.apache.org/jira/browse/QPID-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8130:
-
Status: Reviewable (was: In Progress)
> [Broker-J] IAE "Comparison method violates its general contract!" can be
> thrown whilst comparing log file details of file logger
>
>
> Key: QPID-8130
> URL: https://issues.apache.org/jira/browse/QPID-8130
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-6.0.8,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.3
>
>
> IllegalArgumentException "Comparison method violates its general contract!"
> can be thrown whilst comparing log file details of BrokerFileLogger or
> ViortualHostFileLogger
> {noformat}
> 2018-03-14 13:06:57,951 DEBUG [qtp127624166-218]
> (o.a.q.s.m.p.s.r.RestServlet) - IllegalArgumentException processing request
> java.lang.IllegalArgumentException: Comparison method violates its general
> contract!
> at java.util.TimSort.mergeHi(TimSort.java:899)
> at java.util.TimSort.mergeAt(TimSort.java:516)
> at java.util.TimSort.mergeForceCollapse(TimSort.java:457)
> at java.util.TimSort.sort(TimSort.java:254)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:175)
> at
> org.apache.qpid.server.logging.logback.RolloverWatcher.getLogFileDetails(RolloverWatcher.java:130)
> at
> org.apache.qpid.server.logging.logback.BrokerFileLoggerImpl.getLogFiles(BrokerFileLoggerImpl.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.ConfiguredObjectMethodAttributeOrStatistic.getValue(ConfiguredObjectMethodAttributeOrStatistic.java:68)
> at
> org.apache.qpid.server.model.ConfiguredObjectMethodAttribute.getValue(ConfiguredObjectMethodAttribute.java:26)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.getAttribute(AbstractConfiguredObject.java:1856)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateAttributesIntoMap(ConfiguredObjectToMapConverter.java:86)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:64)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateChildrenIntoMap(ConfiguredObjectToMapConverter.java:271)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:69)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:247)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:128)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:341)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
> at
>
[jira] [Assigned] (QPID-8130) [Broker-J] IAE "Comparison method violates its general contract!" can be thrown whilst comparing log file details of file logger
[
https://issues.apache.org/jira/browse/QPID-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy reassigned QPID-8130:
Assignee: Alex Rudyy
> [Broker-J] IAE "Comparison method violates its general contract!" can be
> thrown whilst comparing log file details of file logger
>
>
> Key: QPID-8130
> URL: https://issues.apache.org/jira/browse/QPID-8130
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-6.0.8,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.3
>
>
> IllegalArgumentException "Comparison method violates its general contract!"
> can be thrown whilst comparing log file details of BrokerFileLogger or
> ViortualHostFileLogger
> {noformat}
> 2018-03-14 13:06:57,951 DEBUG [qtp127624166-218]
> (o.a.q.s.m.p.s.r.RestServlet) - IllegalArgumentException processing request
> java.lang.IllegalArgumentException: Comparison method violates its general
> contract!
> at java.util.TimSort.mergeHi(TimSort.java:899)
> at java.util.TimSort.mergeAt(TimSort.java:516)
> at java.util.TimSort.mergeForceCollapse(TimSort.java:457)
> at java.util.TimSort.sort(TimSort.java:254)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:175)
> at
> org.apache.qpid.server.logging.logback.RolloverWatcher.getLogFileDetails(RolloverWatcher.java:130)
> at
> org.apache.qpid.server.logging.logback.BrokerFileLoggerImpl.getLogFiles(BrokerFileLoggerImpl.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.ConfiguredObjectMethodAttributeOrStatistic.getValue(ConfiguredObjectMethodAttributeOrStatistic.java:68)
> at
> org.apache.qpid.server.model.ConfiguredObjectMethodAttribute.getValue(ConfiguredObjectMethodAttribute.java:26)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.getAttribute(AbstractConfiguredObject.java:1856)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateAttributesIntoMap(ConfiguredObjectToMapConverter.java:86)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:64)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateChildrenIntoMap(ConfiguredObjectToMapConverter.java:271)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:69)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:247)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:128)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:341)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
> at
> org.apache.qpid.server.management.plugin.filter.LoggingFilter.doFilter(LoggingFilter.java:63)
>
[jira] [Commented] (QPID-8130) [Broker-J] IAE "Comparison method violates its general contract!" can be thrown whilst comparing log file details of file logger
[
https://issues.apache.org/jira/browse/QPID-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398646#comment-16398646
]
ASF subversion and git services commented on QPID-8130:
---
Commit 890c5cec33ff28aabb0435e262ce235991119235 in qpid-broker-j's branch
refs/heads/master from Oleksandr Rudyy
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=890c5ce ]
QPID-8130: [Broker-J] Fix comparator for log file details
> [Broker-J] IAE "Comparison method violates its general contract!" can be
> thrown whilst comparing log file details of file logger
>
>
> Key: QPID-8130
> URL: https://issues.apache.org/jira/browse/QPID-8130
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-6.0.8,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.3
>
>
> IllegalArgumentException "Comparison method violates its general contract!"
> can be thrown whilst comparing log file details of BrokerFileLogger or
> ViortualHostFileLogger
> {noformat}
> 2018-03-14 13:06:57,951 DEBUG [qtp127624166-218]
> (o.a.q.s.m.p.s.r.RestServlet) - IllegalArgumentException processing request
> java.lang.IllegalArgumentException: Comparison method violates its general
> contract!
> at java.util.TimSort.mergeHi(TimSort.java:899)
> at java.util.TimSort.mergeAt(TimSort.java:516)
> at java.util.TimSort.mergeForceCollapse(TimSort.java:457)
> at java.util.TimSort.sort(TimSort.java:254)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:175)
> at
> org.apache.qpid.server.logging.logback.RolloverWatcher.getLogFileDetails(RolloverWatcher.java:130)
> at
> org.apache.qpid.server.logging.logback.BrokerFileLoggerImpl.getLogFiles(BrokerFileLoggerImpl.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.ConfiguredObjectMethodAttributeOrStatistic.getValue(ConfiguredObjectMethodAttributeOrStatistic.java:68)
> at
> org.apache.qpid.server.model.ConfiguredObjectMethodAttribute.getValue(ConfiguredObjectMethodAttribute.java:26)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.getAttribute(AbstractConfiguredObject.java:1856)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateAttributesIntoMap(ConfiguredObjectToMapConverter.java:86)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:64)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateChildrenIntoMap(ConfiguredObjectToMapConverter.java:271)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:69)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:247)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:128)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:341)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
> at
>
[jira] [Created] (QPIDJMS-367) Add support for XOAUTH2 Sasl Autentication
Rob Godfrey created QPIDJMS-367: --- Summary: Add support for XOAUTH2 Sasl Autentication Key: QPIDJMS-367 URL: https://issues.apache.org/jira/browse/QPIDJMS-367 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Reporter: Rob Godfrey [https://developers.google.com/gmail/imap/xoauth2-protocol] defines a SASL mechanism which allows for authentication using an OAUTH2 Acess Token. This mechanism is supported by Qpid Broker-J and it would be useful if the Qpid JMS client could connect using this mechanism. The mechanics of the mechanism pass a username and token, the latter essentially being equivalent to a password for these purposes. The Token MUST be provided as a Base64 encoded string (the contents of which are a token in JSON format, though this detail is opaque to the client). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8130) [Broker-J] IAE "Comparison method violates its general contract!" can be thrown whilst comparing log file details of file logger
Alex Rudyy created QPID-8130:
Summary: [Broker-J] IAE "Comparison method violates its general
contract!" can be thrown whilst comparing log file details of file logger
Key: QPID-8130
URL: https://issues.apache.org/jira/browse/QPID-8130
Project: Qpid
Issue Type: Improvement
Components: Broker-J
Affects Versions: qpid-java-broker-7.0.1, qpid-java-6.1.5,
qpid-java-broker-7.0.0, qpid-java-6.0.8, qpid-java-broker-7.0.2
Reporter: Alex Rudyy
Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.3
IllegalArgumentException "Comparison method violates its general contract!" can
be thrown whilst comparing log file details of BrokerFileLogger or
ViortualHostFileLogger
{noformat}
2018-03-14 13:06:57,951 DEBUG [qtp127624166-218] (o.a.q.s.m.p.s.r.RestServlet)
- IllegalArgumentException processing request
java.lang.IllegalArgumentException: Comparison method violates its general
contract!
at java.util.TimSort.mergeHi(TimSort.java:899)
at java.util.TimSort.mergeAt(TimSort.java:516)
at java.util.TimSort.mergeForceCollapse(TimSort.java:457)
at java.util.TimSort.sort(TimSort.java:254)
at java.util.Arrays.sort(Arrays.java:1512)
at java.util.ArrayList.sort(ArrayList.java:1454)
at java.util.Collections.sort(Collections.java:175)
at
org.apache.qpid.server.logging.logback.RolloverWatcher.getLogFileDetails(RolloverWatcher.java:130)
at
org.apache.qpid.server.logging.logback.BrokerFileLoggerImpl.getLogFiles(BrokerFileLoggerImpl.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.qpid.server.model.ConfiguredObjectMethodAttributeOrStatistic.getValue(ConfiguredObjectMethodAttributeOrStatistic.java:68)
at
org.apache.qpid.server.model.ConfiguredObjectMethodAttribute.getValue(ConfiguredObjectMethodAttribute.java:26)
at
org.apache.qpid.server.model.AbstractConfiguredObject.getAttribute(AbstractConfiguredObject.java:1856)
at
org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateAttributesIntoMap(ConfiguredObjectToMapConverter.java:86)
at
org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:64)
at
org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateChildrenIntoMap(ConfiguredObjectToMapConverter.java:271)
at
org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:69)
at
org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:247)
at
org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:128)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at
org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:341)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
at
org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
at
org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
at
org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.apache.qpid.server.management.plugin.filter.LoggingFilter.doFilter(LoggingFilter.java:63)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.apache.qpid.server.management.plugin.filter.ForbiddingTraceFilter.doFilter(ForbiddingTraceFilter.java:65)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:308)
at
[jira] [Commented] (QPID-7873) [Broker-J] Delete store notion confused
[ https://issues.apache.org/jira/browse/QPID-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398558#comment-16398558 ] Keith Wall commented on QPID-7873: -- Alex - your defect fix was good, but I felt that state handling was still not consistently applied across all implementations. Please review e8efe56 > [Broker-J] Delete store notion confused > --- > > Key: QPID-7873 > URL: https://issues.apache.org/jira/browse/QPID-7873 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > org.apache.qpid.server.store.MessageStore#onDelete > org.apache.qpid.server.store.DurableConfigurationStore#onDelete > org.apache.qpid.server.protocol.v1_0.store.LinkStore#delete > The Java Broker's delete store notion conflates the removal of the structures > from the store (e.g. the removal of a table from a RDBMS, for instance) with > the destruction of the store itself (e.g. removal of Derby or BDB files). We > are also unclear about whether we expect a store to be in an open state when > the store is deleted. > This problem does not currently cause a functional defect. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7873) [Broker-J] Delete store notion confused
[ https://issues.apache.org/jira/browse/QPID-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398554#comment-16398554 ] ASF subversion and git services commented on QPID-7873: --- Commit e8efe5624d5459a45bd10a887dfaa97ee55f9069 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=e8efe56 ] QPID-7873: [Broker-J] Further tighten the onDelete contract by consistently ensuring that the message store is closed. Also fixed a defect that meant that the messages belonging to a deleted Provided BDB Store would remain on disk. > [Broker-J] Delete store notion confused > --- > > Key: QPID-7873 > URL: https://issues.apache.org/jira/browse/QPID-7873 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > org.apache.qpid.server.store.MessageStore#onDelete > org.apache.qpid.server.store.DurableConfigurationStore#onDelete > org.apache.qpid.server.protocol.v1_0.store.LinkStore#delete > The Java Broker's delete store notion conflates the removal of the structures > from the store (e.g. the removal of a table from a RDBMS, for instance) with > the destruction of the store itself (e.g. removal of Derby or BDB files). We > are also unclear about whether we expect a store to be in an open state when > the store is deleted. > This problem does not currently cause a functional defect. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8113) [Broker-J] Incorrect symbolic descriptor used for (JMS) selector
[ https://issues.apache.org/jira/browse/QPID-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8113: - Fix Version/s: qpid-java-broker-7.0.3 > [Broker-J] Incorrect symbolic descriptor used for (JMS) selector > > > Key: QPID-8113 > URL: https://issues.apache.org/jira/browse/QPID-8113 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, > qpid-java-broker-7.0.1 >Reporter: Rob Godfrey >Assignee: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.0.3 > > > As per > [this|http://mail-archives.apache.org/mod_mbox/qpid-users/201802.mbox/%3CCACsaS95BJjm8e09xZGEPkp_Wsq801sdLd0fVnR9Tqy-JwJWnhg%40mail.gmail.com%3E] > message, the symbolic descriptor for JMS-style selector parsing is > incorrectly defined within Broker-J -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8123) [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP 0-x
[ https://issues.apache.org/jira/browse/QPID-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398427#comment-16398427 ] ASF subversion and git services commented on QPID-8123: --- Commit de9988cb5ca412545b15c079aff8df54cd78a5fe in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=de9988c ] QPID-8123: [Broker-J] [System Tests] Add extra logging MultiNodeTest#testLossOfQuorumCausesClientDisconnection to understand occasional failure on CI environment with the old client > [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP > 0-x > > > Key: QPID-8123 > URL: https://issues.apache.org/jira/browse/QPID-8123 > Project: Qpid > Issue Type: Test > Components: Broker-J, Java Tests >Reporter: Keith Wall >Priority: Major > > Remove compile time dependency on Qpid JMS Client AMQP 0-x and enable the BDB > HA tests for the AMQP 1.0 profile. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8123) [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP 0-x
[ https://issues.apache.org/jira/browse/QPID-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398428#comment-16398428 ] ASF subversion and git services commented on QPID-8123: --- Commit 36f1dd9f4154581fdf84bc154b6c22ead537a4bd in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=36f1dd9 ] QPID-8123: [Broker-J] [System Tests] Add JIRA references related to Qpid JMS AMQP 1.0 test exclusions > [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP > 0-x > > > Key: QPID-8123 > URL: https://issues.apache.org/jira/browse/QPID-8123 > Project: Qpid > Issue Type: Test > Components: Broker-J, Java Tests >Reporter: Keith Wall >Priority: Major > > Remove compile time dependency on Qpid JMS Client AMQP 0-x and enable the BDB > HA tests for the AMQP 1.0 profile. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8123) [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP 0-x
[ https://issues.apache.org/jira/browse/QPID-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398409#comment-16398409 ] ASF subversion and git services commented on QPID-8123: --- Commit 291bccbc54e04bd199f2897977caabc4cff3e080 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=291bccb ] QPID-8123: [Broker-J] [System Tests] Fix regression in BDBUpgradeTest > [Broker-J] [BDB Test] Remove compile time dependency on Qpid JMS Client AMQP > 0-x > > > Key: QPID-8123 > URL: https://issues.apache.org/jira/browse/QPID-8123 > Project: Qpid > Issue Type: Test > Components: Broker-J, Java Tests >Reporter: Keith Wall >Priority: Major > > Remove compile time dependency on Qpid JMS Client AMQP 0-x and enable the BDB > HA tests for the AMQP 1.0 profile. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
