[jira] [Commented] (QPID-8106) [Broker-J] [Alternate Binding] On virtualhost recovery, message "Gave up waiting for Queue 'xxxx' to attain state" written to the log and startup delayed
[
https://issues.apache.org/jira/browse/QPID-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372699#comment-16372699
]
Alex Rudyy commented on QPID-8106:
--
The changes implemented in commit
[1dbdd321351400b466b1a23cb5efb8df55e1ab00|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=1dbdd321351400b466b1a23cb5efb8df55e1ab00]
look reasonable to me. I am going to port them into 7.0.x branch
> [Broker-J] [Alternate Binding] On virtualhost recovery, message "Gave up
> waiting for Queue '' to attain state" written to the log and startup
> delayed
> --
>
> Key: QPID-8106
> URL: https://issues.apache.org/jira/browse/QPID-8106
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.2
>
>
> http://mail-archives.apache.org/mod_mbox/qpid-users/201802.mbox/%3c1518095068895-0.p...@n2.nabble.com%3e
> If as an operator I create a queue or exchange with an alternate binding to
> another queue or exchange, on restart of the virtualhost the following
> message will be seen in the log:
> {noformat}
> 2018-02-21 10:43:52,707 WARN [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Gave up waiting for Queue 'queue2' to
> attain state. Check object's state via Management.
> {noformat}
> The startup of the virtualhost is delayed (5 seconds per queue or exchange
> with an alternate binding), but there is otherwise no other functional
> impact. 'Dead lettering' with still operate normally.
--
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-8106) [Broker-J] [Alternate Binding] On virtualhost recovery, message "Gave up waiting for Queue 'xxxx' to attain state" written to the log and startup delayed
[
https://issues.apache.org/jira/browse/QPID-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8106.
--
Resolution: Fixed
Fix Version/s: qpid-java-broker-7.1.0
Resolving JIRA after reviewing the code and merging changes into 7.0.x branch.
The changes are merged into 7.0.x in commit
[de8098430974db2cb1fd31c4044dec25eb6fd108|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=de8098430974db2cb1fd31c4044dec25eb6fd108]
> [Broker-J] [Alternate Binding] On virtualhost recovery, message "Gave up
> waiting for Queue '' to attain state" written to the log and startup
> delayed
> --
>
> Key: QPID-8106
> URL: https://issues.apache.org/jira/browse/QPID-8106
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0
>
>
> http://mail-archives.apache.org/mod_mbox/qpid-users/201802.mbox/%3c1518095068895-0.p...@n2.nabble.com%3e
> If as an operator I create a queue or exchange with an alternate binding to
> another queue or exchange, on restart of the virtualhost the following
> message will be seen in the log:
> {noformat}
> 2018-02-21 10:43:52,707 WARN [VirtualHostNode-default-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Gave up waiting for Queue 'queue2' to
> attain state. Check object's state via Management.
> {noformat}
> The startup of the virtualhost is delayed (5 seconds per queue or exchange
> with an alternate binding), but there is otherwise no other functional
> impact. 'Dead lettering' with still operate normally.
--
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] (DISPATCH-893) Compile fails using libwebsockets 7
[ https://issues.apache.org/jira/browse/DISPATCH-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated DISPATCH-893: Fix Version/s: 1.1.0 > Compile fails using libwebsockets 7 > --- > > Key: DISPATCH-893 > URL: https://issues.apache.org/jira/browse/DISPATCH-893 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.0.0 > Environment: Ubuntu 16.04 LTS > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 >Reporter: AWETTT >Assignee: Alan Conway >Priority: Minor > Fix For: 1.1.0 > > > andreas:/home/andreas/brokers/qpid-dispatch-1.0.0/build >cmake .. > -- The C compiler identification is GNU 5.4.0 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Found PythonInterp: /usr/bin/python (found version "2.7.12") > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version > "2.7.12") > -- Found LIBWEBSOCKETS: /usr/lib/x86_64-linux-gnu/libwebsockets.so > -- Found VALGRIND: /usr/bin/valgrind > -- Performing Test HAS_PEDANTIC_FLAG > -- Performing Test HAS_PEDANTIC_FLAG - Success > -- Configuring done > -- Generating done > -- Build files have been written to: > /home/andreas/brokers/qpid-dispatch-1.0.0/build > - > andreas:/home/andreas/brokers/qpid-dispatch-1.0.0/build >make all > [ 1%] Generating schema_enum.h, schema_enum.c > Scanning dependencies of target qpid-dispatch > [ 2%] Building C object src/CMakeFiles/qpid-dispatch.dir/amqp.c.o > [ 4%] Building C object src/CMakeFiles/qpid-dispatch.dir/bitmask.c.o > [ 5%] Building C object src/CMakeFiles/qpid-dispatch.dir/buffer.c.o > [ 6%] Building C object src/CMakeFiles/qpid-dispatch.dir/error.c.o > [ 8%] Building C object src/CMakeFiles/qpid-dispatch.dir/compose.c.o > [ 9%] Building C object > src/CMakeFiles/qpid-dispatch.dir/connection_manager.c.o > [ 10%] Building C object src/CMakeFiles/qpid-dispatch.dir/container.c.o > [ 12%] Building C object src/CMakeFiles/qpid-dispatch.dir/dispatch.c.o > [ 13%] Building C object src/CMakeFiles/qpid-dispatch.dir/entity.c.o > [ 14%] Building C object src/CMakeFiles/qpid-dispatch.dir/entity_cache.c.o > [ 16%] Building C object src/CMakeFiles/qpid-dispatch.dir/failoverlist.c.o > [ 17%] Building C object src/CMakeFiles/qpid-dispatch.dir/hash.c.o > [ 18%] Building C object src/CMakeFiles/qpid-dispatch.dir/iovec.c.o > [ 20%] Building C object src/CMakeFiles/qpid-dispatch.dir/iterator.c.o > [ 21%] Building C object src/CMakeFiles/qpid-dispatch.dir/log.c.o > [ 22%] Building C object src/CMakeFiles/qpid-dispatch.dir/message.c.o > [ 24%] Building C object src/CMakeFiles/qpid-dispatch.dir/parse.c.o > [ 25%] Building C object src/CMakeFiles/qpid-dispatch.dir/parse_tree.c.o > [ 27%] Building C object src/CMakeFiles/qpid-dispatch.dir/policy.c.o > [ 28%] Building C object src/CMakeFiles/qpid-dispatch.dir/remote_sasl.c.o > [ 29%] Building C object src/CMakeFiles/qpid-dispatch.dir/posix/threading.c.o > [ 31%] Building C object src/CMakeFiles/qpid-dispatch.dir/python_embedded.c.o > [ 32%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_agent.c.o > [ 33%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_config.c.o > [ 35%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent.c.o > [ 36%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_address.c.o > [ 37%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_address.c.o > [ 39%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_auto_link.c.o > [ 40%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_connection.c.o > [ 41%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_link_route.c.o > [ 43%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_link.c.o > [ 44%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_router.c.o > [ 45%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/connections.c.o > [ 47%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/error.c.o > [ 48%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/forwarder.c.o > [ 50%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/route_control.c.o > [ 51%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/router_core.c.o > [ 52%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/router_core_thread.c.o > [ 54%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core
[jira] [Updated] (DISPATCH-893) Compile fails using libwebsockets 7
[ https://issues.apache.org/jira/browse/DISPATCH-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated DISPATCH-893: Affects Version/s: 1.0.1 > Compile fails using libwebsockets 7 > --- > > Key: DISPATCH-893 > URL: https://issues.apache.org/jira/browse/DISPATCH-893 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.0.0, 1.0.1 > Environment: Ubuntu 16.04 LTS > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 >Reporter: AWETTT >Assignee: Alan Conway >Priority: Minor > Fix For: 1.1.0 > > > andreas:/home/andreas/brokers/qpid-dispatch-1.0.0/build >cmake .. > -- The C compiler identification is GNU 5.4.0 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Found PythonInterp: /usr/bin/python (found version "2.7.12") > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version > "2.7.12") > -- Found LIBWEBSOCKETS: /usr/lib/x86_64-linux-gnu/libwebsockets.so > -- Found VALGRIND: /usr/bin/valgrind > -- Performing Test HAS_PEDANTIC_FLAG > -- Performing Test HAS_PEDANTIC_FLAG - Success > -- Configuring done > -- Generating done > -- Build files have been written to: > /home/andreas/brokers/qpid-dispatch-1.0.0/build > - > andreas:/home/andreas/brokers/qpid-dispatch-1.0.0/build >make all > [ 1%] Generating schema_enum.h, schema_enum.c > Scanning dependencies of target qpid-dispatch > [ 2%] Building C object src/CMakeFiles/qpid-dispatch.dir/amqp.c.o > [ 4%] Building C object src/CMakeFiles/qpid-dispatch.dir/bitmask.c.o > [ 5%] Building C object src/CMakeFiles/qpid-dispatch.dir/buffer.c.o > [ 6%] Building C object src/CMakeFiles/qpid-dispatch.dir/error.c.o > [ 8%] Building C object src/CMakeFiles/qpid-dispatch.dir/compose.c.o > [ 9%] Building C object > src/CMakeFiles/qpid-dispatch.dir/connection_manager.c.o > [ 10%] Building C object src/CMakeFiles/qpid-dispatch.dir/container.c.o > [ 12%] Building C object src/CMakeFiles/qpid-dispatch.dir/dispatch.c.o > [ 13%] Building C object src/CMakeFiles/qpid-dispatch.dir/entity.c.o > [ 14%] Building C object src/CMakeFiles/qpid-dispatch.dir/entity_cache.c.o > [ 16%] Building C object src/CMakeFiles/qpid-dispatch.dir/failoverlist.c.o > [ 17%] Building C object src/CMakeFiles/qpid-dispatch.dir/hash.c.o > [ 18%] Building C object src/CMakeFiles/qpid-dispatch.dir/iovec.c.o > [ 20%] Building C object src/CMakeFiles/qpid-dispatch.dir/iterator.c.o > [ 21%] Building C object src/CMakeFiles/qpid-dispatch.dir/log.c.o > [ 22%] Building C object src/CMakeFiles/qpid-dispatch.dir/message.c.o > [ 24%] Building C object src/CMakeFiles/qpid-dispatch.dir/parse.c.o > [ 25%] Building C object src/CMakeFiles/qpid-dispatch.dir/parse_tree.c.o > [ 27%] Building C object src/CMakeFiles/qpid-dispatch.dir/policy.c.o > [ 28%] Building C object src/CMakeFiles/qpid-dispatch.dir/remote_sasl.c.o > [ 29%] Building C object src/CMakeFiles/qpid-dispatch.dir/posix/threading.c.o > [ 31%] Building C object src/CMakeFiles/qpid-dispatch.dir/python_embedded.c.o > [ 32%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_agent.c.o > [ 33%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_config.c.o > [ 35%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent.c.o > [ 36%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_address.c.o > [ 37%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_address.c.o > [ 39%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_auto_link.c.o > [ 40%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_connection.c.o > [ 41%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_link_route.c.o > [ 43%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_link.c.o > [ 44%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_router.c.o > [ 45%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/connections.c.o > [ 47%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/error.c.o > [ 48%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/forwarder.c.o > [ 50%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/route_control.c.o > [ 51%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/router_core.c.o > [ 52%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/router_core_thread.c.o > [ 54%] Building C object > src/CMakeFiles/qpid-dispatch.dir/
[jira] [Updated] (PROTON-1515) Python sender client doesn't check actual link state and continues to send messages even if link is down
[ https://issues.apache.org/jira/browse/PROTON-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Daněk updated PROTON-1515: --- Description: Steps to reproduce: 1. Start broker 2. Create queue 3. Start sending e.g. 10 messages with python sender 4. Kill broker 5. Notice that client continues send messages and raises exception only after all 10 messages were sent. Actual behavior: Python sender client ignores link failure until all messages were sent and only then raises an exception/ begins re-connection attempts. Expected behavior: Client should stop sending messages and raise exception or try to begin re-connection attempts if reconnect option is set. Please, see sender.log. Global handler was added for event logging purposes. It just prints event/handler name. was: Steps to reproduce: 1. Start broker 2. Create queue 3. Start sending e.g. 10 messages with python sender 4. Kill broker 5. Notice that client continues send messages and raises exception only after all 10 messages were sent. Actual behavior: Python sender client ignores link failure until all messages were sent and only then raises an exception/ begins re-connection attempmts. Expected behavior: Client should stop sending messages and raise exception or try to begin re-connection attempts if reconnect option is set. Please, see sender.log. Global handler was added for event logging purposes. It just prints event/handler name. > Python sender client doesn't check actual link state and continues to send > messages even if link is down > > > Key: PROTON-1515 > URL: https://issues.apache.org/jira/browse/PROTON-1515 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding > Environment: RHEL7.3 > Jboss AMQ 7 > python-qpid-proton.x86_64-0.14.0-1.el7 >Reporter: Dmitrii Puzikov >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.21.0 > > Attachments: sender.log > > > Steps to reproduce: > 1. Start broker > 2. Create queue > 3. Start sending e.g. 10 messages with python sender > 4. Kill broker > 5. Notice that client continues send messages and raises exception only after > all 10 messages were sent. > Actual behavior: Python sender client ignores link failure until all messages > were sent and only then raises an exception/ begins re-connection attempts. > Expected behavior: Client should stop sending messages and raise exception or > try to begin re-connection attempts if reconnect option is set. > Please, see sender.log. Global handler was added for event logging purposes. > It just prints event/handler name. -- 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-8101) [Broker-J] [Web Management Console] Add ability to close more than one connection at once
[
https://issues.apache.org/jira/browse/QPID-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372730#comment-16372730
]
Alex Rudyy commented on QPID-8101:
--
The changes implemented as part of commit
[fbca8f16e36d84fc0fc3291ca9937b31ed8a73a4|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=fbca8f16e36d84fc0fc3291ca9937b31ed8a73a4]
look reasonable to me. I am going to port them into 7.0.x
> [Broker-J] [Web Management Console] Add ability to close more than one
> connection at once
> -
>
> Key: QPID-8101
> URL: https://issues.apache.org/jira/browse/QPID-8101
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
>
> Within the WMC it is already possible to close a single messaging connection
> by clicking through to the connection's tab and pressing the {{Close}}
> button. This is operational useful ability - it allows intervention say in
> case where a consuming application has stuck without having to resort to
> bouncing applications.
> However as many applications maintain a pool of connections to the Broker,
> currently it is tedious to have to click through to every connection. A
> useful small improvement would be the ability to close many connections at
> once, by ticking them from the virtualhost tab and clicking a {{Close}}
> button.
--
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-8101) [Broker-J] [Web Management Console] Add ability to close more than one connection at once
[
https://issues.apache.org/jira/browse/QPID-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372733#comment-16372733
]
ASF subversion and git services commented on QPID-8101:
---
Commit 969f7a3c64556a5adbdf74b6564358a51ebe3009 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=969f7a3 ]
QPID-8101: [Broker-J] [WMC] Add ability to close more than one connection at
once
(cherry picked from commit fbca8f16e36d84fc0fc3291ca9937b31ed8a73a4)
> [Broker-J] [Web Management Console] Add ability to close more than one
> connection at once
> -
>
> Key: QPID-8101
> URL: https://issues.apache.org/jira/browse/QPID-8101
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
>
> Within the WMC it is already possible to close a single messaging connection
> by clicking through to the connection's tab and pressing the {{Close}}
> button. This is operational useful ability - it allows intervention say in
> case where a consuming application has stuck without having to resort to
> bouncing applications.
> However as many applications maintain a pool of connections to the Broker,
> currently it is tedious to have to click through to every connection. A
> useful small improvement would be the ability to close many connections at
> once, by ticking them from the virtualhost tab and clicking a {{Close}}
> button.
--
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-2) [IGNORE ME] Subversion & Git to JIRA integration test
[ https://issues.apache.org/jira/browse/QPIDJMS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372734#comment-16372734 ] ASF subversion and git services commented on QPIDJMS-2: --- Commit 50c0111360fc4cdfa7b42cbd3c11239c4157c0cc in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=50c0111 ] QPIDJMS-2: testing bot, ignore > [IGNORE ME] Subversion & Git to JIRA integration test > -- > > Key: QPIDJMS-2 > URL: https://issues.apache.org/jira/browse/QPIDJMS-2 > Project: Qpid JMS > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > > JIRA for testing gitsvn2jira integration, as with QPID-4891 and PROTON-321 -- 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] (QPID-8101) [Broker-J] [Web Management Console] Add ability to close more than one connection at once
[
https://issues.apache.org/jira/browse/QPID-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy closed QPID-8101.
Resolution: Fixed
Fix Version/s: qpid-java-broker-7.1.0
qpid-java-broker-7.0.2
Resolving the JIRA after reviewing and merging the changes into 7.0.x branch as
part of commit
[969f7a3c64556a5adbdf74b6564358a51ebe3009|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=969f7a3c64556a5adbdf74b6564358a51ebe3009
]
> [Broker-J] [Web Management Console] Add ability to close more than one
> connection at once
> -
>
> Key: QPID-8101
> URL: https://issues.apache.org/jira/browse/QPID-8101
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0
>
>
> Within the WMC it is already possible to close a single messaging connection
> by clicking through to the connection's tab and pressing the {{Close}}
> button. This is operational useful ability - it allows intervention say in
> case where a consuming application has stuck without having to resort to
> bouncing applications.
> However as many applications maintain a pool of connections to the Broker,
> currently it is tedious to have to click through to every connection. A
> useful small improvement would be the ability to close many connections at
> once, by ticking them from the virtualhost tab and clicking a {{Close}}
> button.
--
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-8108) [Broker-J] [HTTP] NPE from SaslServlet if request arrives before Broker has activated
[
https://issues.apache.org/jira/browse/QPID-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8108:
-
Priority: Minor (was: Major)
> [Broker-J] [HTTP] NPE from SaslServlet if request arrives before Broker has
> activated
> -
>
> Key: QPID-8108
> URL: https://issues.apache.org/jira/browse/QPID-8108
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1
>Reporter: Keith Wall
>Priority: Minor
>
> If HttpPort#absoluteSessionTimeout has a non-zero value, if a request arrives
> whilst the Broker is still starting the following stack trace may result.
> The stack trace is harmless. Once the Broker becomes ready the problem no
> longer occurs.
> {noformat}
> 2018-02-22 18:39:42,929 ERROR [qtp1248732436-35]
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
> '/service/sasl':
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.model.AbstractContainer.scheduleTask(AbstractContainer.java:490)
> at
> org.apache.qpid.server.management.plugin.HttpManagementUtil.scheduleAbsoluteSessionTimeout(HttpManagementUtil.java:179)
> at
> org.apache.qpid.server.management.plugin.HttpManagementUtil.saveAuthorisedSubject(HttpManagementUtil.java:171)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.evaluateSaslResponse(SaslServlet.java:255)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.doPost(SaslServlet.java:179)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doPost(AbstractServlet.java:140)
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> 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
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:262)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
> at
> org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.doFilter(ExceptionHandlingFilter.java:59)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:541)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1593)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1239)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:481)
> at
> org.eclipse.jetty.server.session
[jira] [Updated] (QPID-8108) [Broker-J] [HTTP] NPE from SaslServlet if request arrives before Broker has activated
[
https://issues.apache.org/jira/browse/QPID-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8108:
-
Description:
If {{HttpPort#absoluteSessionTimeout}} has a non-zero value, if a request
arrives whilst the Broker is still starting the following stack trace may
result. The stack trace is harmless. Once the Broker becomes ready the
problem no longer occurs.
{noformat}
2018-02-22 18:39:42,929 ERROR [qtp1248732436-35]
(o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
'/service/sasl':
java.lang.NullPointerException: null
at
org.apache.qpid.server.model.AbstractContainer.scheduleTask(AbstractContainer.java:490)
at
org.apache.qpid.server.management.plugin.HttpManagementUtil.scheduleAbsoluteSessionTimeout(HttpManagementUtil.java:179)
at
org.apache.qpid.server.management.plugin.HttpManagementUtil.saveAuthorisedSubject(HttpManagementUtil.java:171)
at
org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.evaluateSaslResponse(SaslServlet.java:255)
at
org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.doPost(SaslServlet.java:179)
at
org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doPost(AbstractServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
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
org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:262)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.doFilter(ExceptionHandlingFilter.java:59)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:541)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1593)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1239)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:481)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1141)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:564)
at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at
org.eclipse.jetty.server.HttpConnecti
[jira] [Created] (QPID-8108) [Broker-J] [HTTP] NPE from SaslServlet if request arrives before Broker has activated
Keith Wall created QPID-8108:
Summary: [Broker-J] [HTTP] NPE from SaslServlet if request arrives
before Broker has activated
Key: QPID-8108
URL: https://issues.apache.org/jira/browse/QPID-8108
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-7.0.1, qpid-java-broker-7.0.0
Reporter: Keith Wall
If HttpPort#absoluteSessionTimeout has a non-zero value, if a request arrives
whilst the Broker is still starting the following stack trace may result. The
stack trace is harmless. Once the Broker becomes ready the problem no longer
occurs.
{noformat}
2018-02-22 18:39:42,929 ERROR [qtp1248732436-35]
(o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
'/service/sasl':
java.lang.NullPointerException: null
at
org.apache.qpid.server.model.AbstractContainer.scheduleTask(AbstractContainer.java:490)
at
org.apache.qpid.server.management.plugin.HttpManagementUtil.scheduleAbsoluteSessionTimeout(HttpManagementUtil.java:179)
at
org.apache.qpid.server.management.plugin.HttpManagementUtil.saveAuthorisedSubject(HttpManagementUtil.java:171)
at
org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.evaluateSaslResponse(SaslServlet.java:255)
at
org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.doPost(SaslServlet.java:179)
at
org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doPost(AbstractServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
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
org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:262)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.doFilter(ExceptionHandlingFilter.java:59)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:541)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1593)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1239)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:481)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1141)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.HandlerWrap
[jira] [Updated] (QPID-8108) [Broker-J] [HTTP] NPE from SaslServlet if request arrives before Broker has activated
[
https://issues.apache.org/jira/browse/QPID-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8108:
-
Description:
If {{HttpPort#absoluteSessionTimeout}} has a non-zero value, if a request
arrives whilst the Broker is still starting the following stack trace may
result. The stack trace is harmless. Once the Broker becomes ready the
problem no longer occurs.
{noformat}
2018-02-22 18:39:42,929 ERROR [qtp1248732436-35]
(o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
'/service/sasl':
java.lang.NullPointerException: null
at
org.apache.qpid.server.model.AbstractContainer.scheduleTask(AbstractContainer.java:490)
at
org.apache.qpid.server.management.plugin.HttpManagementUtil.scheduleAbsoluteSessionTimeout(HttpManagementUtil.java:179)
at
org.apache.qpid.server.management.plugin.HttpManagementUtil.saveAuthorisedSubject(HttpManagementUtil.java:171)
at
org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.evaluateSaslResponse(SaslServlet.java:255)
at
org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.doPost(SaslServlet.java:179)
at
org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doPost(AbstractServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
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
org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:262)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.doFilter(ExceptionHandlingFilter.java:59)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:541)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1593)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1239)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:481)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1141)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:564)
at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at
org.eclipse.jetty.server.HttpConnecti
[jira] [Commented] (QPID-8108) [Broker-J] [HTTP] NPE from SaslServlet if request arrives before Broker has activated
[
https://issues.apache.org/jira/browse/QPID-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372775#comment-16372775
]
Keith Wall commented on QPID-8108:
--
The Broker does not yet have a well developed idea about when a child may start
using the resources held by its parent. There are probably other places where
the Broker is susceptible to this kind of problem.
> [Broker-J] [HTTP] NPE from SaslServlet if request arrives before Broker has
> activated
> -
>
> Key: QPID-8108
> URL: https://issues.apache.org/jira/browse/QPID-8108
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1
>Reporter: Keith Wall
>Priority: Minor
>
> If {{HttpPort#absoluteSessionTimeout}} has a non-zero value, if a request
> arrives whilst the Broker is still starting the following stack trace may
> result. The stack trace is harmless. Once the Broker becomes ready the
> problem no longer occurs.
> {noformat}
> 2018-02-22 18:39:42,929 ERROR [qtp1248732436-35]
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
> '/service/sasl':
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.model.AbstractContainer.scheduleTask(AbstractContainer.java:490)
> at
> org.apache.qpid.server.management.plugin.HttpManagementUtil.scheduleAbsoluteSessionTimeout(HttpManagementUtil.java:179)
> at
> org.apache.qpid.server.management.plugin.HttpManagementUtil.saveAuthorisedSubject(HttpManagementUtil.java:171)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.evaluateSaslResponse(SaslServlet.java:255)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.doPost(SaslServlet.java:179)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doPost(AbstractServlet.java:140)
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> 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
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:262)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
> at
> org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.doFilter(ExceptionHandlingFilter.java:59)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:541)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1593)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1239)
> at
[jira] [Updated] (QPID-8103) [Broker-J] [WMC] [Query UI] Add ability to download of results as CSV
[
https://issues.apache.org/jira/browse/QPID-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8103:
-
Fix Version/s: qpid-java-broker-7.0.2
> [Broker-J] [WMC] [Query UI] Add ability to download of results as CSV
> -
>
> Key: QPID-8103
> URL: https://issues.apache.org/jira/browse/QPID-8103
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.2
>
>
> The usefulness of the Query UI is currently hampered by the fact that it is
> impossible to download the results of the query. A useful improvement would
> be a button allowing the results of the query to be downloaded, say as a CSV.
> The {{QueryServlet}} would need to accept an optional format that allowed the
> desired format to be specified.
> Also the results table does not permit the copy gesture. There is no good
> reason for this restriction.
--
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-8103) [Broker-J] [WMC] [Query UI] Add ability to download of results as CSV
[
https://issues.apache.org/jira/browse/QPID-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372795#comment-16372795
]
Keith Wall commented on QPID-8103:
--
Tentatively adding for 7.0.2.
> [Broker-J] [WMC] [Query UI] Add ability to download of results as CSV
> -
>
> Key: QPID-8103
> URL: https://issues.apache.org/jira/browse/QPID-8103
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.2
>
>
> The usefulness of the Query UI is currently hampered by the fact that it is
> impossible to download the results of the query. A useful improvement would
> be a button allowing the results of the query to be downloaded, say as a CSV.
> The {{QueryServlet}} would need to accept an optional format that allowed the
> desired format to be specified.
> Also the results table does not permit the copy gesture. There is no good
> reason for this restriction.
--
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-8103) [Broker-J] [WMC] [Query UI] Add ability to download of results as CSV
[
https://issues.apache.org/jira/browse/QPID-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8103:
-
Priority: Minor (was: Major)
> [Broker-J] [WMC] [Query UI] Add ability to download of results as CSV
> -
>
> Key: QPID-8103
> URL: https://issues.apache.org/jira/browse/QPID-8103
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.2
>
>
> The usefulness of the Query UI is currently hampered by the fact that it is
> impossible to download the results of the query. A useful improvement would
> be a button allowing the results of the query to be downloaded, say as a CSV.
> The {{QueryServlet}} would need to accept an optional format that allowed the
> desired format to be specified.
> Also the results table does not permit the copy gesture. There is no good
> reason for this restriction.
--
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-8103) [Broker-J] [WMC] [Query UI] Add ability to download results as CSV
[
https://issues.apache.org/jira/browse/QPID-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8103:
-
Summary: [Broker-J] [WMC] [Query UI] Add ability to download results as CSV
(was: [Broker-J] [WMC] [Query UI] Add ability to download of results as CSV)
> [Broker-J] [WMC] [Query UI] Add ability to download results as CSV
> --
>
> Key: QPID-8103
> URL: https://issues.apache.org/jira/browse/QPID-8103
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.2
>
>
> The usefulness of the Query UI is currently hampered by the fact that it is
> impossible to download the results of the query. A useful improvement would
> be a button allowing the results of the query to be downloaded, say as a CSV.
> The {{QueryServlet}} would need to accept an optional format that allowed the
> desired format to be specified.
> Also the results table does not permit the copy gesture. There is no good
> reason for this restriction.
--
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-8102) [Broker-j][Web Management Console] Add UI for virtual host node auto-creation policies
[ https://issues.apache.org/jira/browse/QPID-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8102: - Fix Version/s: qpid-java-broker-7.0.2 > [Broker-j][Web Management Console] Add UI for virtual host node auto-creation > policies > -- > > Key: QPID-8102 > URL: https://issues.apache.org/jira/browse/QPID-8102 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8102-Broker-J-Add-UI-for-virtual-host-node-auto.patch > > > Add UI to view/create/delete/modify virtual host node auto-creation policies -- 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-8104) [Broker-J] [Query] [WMC] Ordering connections tables by port column fails with '422 - The orderBy expression at position '0' is unsupported'
[
https://issues.apache.org/jira/browse/QPID-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8104:
-
Fix Version/s: qpid-java-broker-7.0.2
> [Broker-J] [Query] [WMC] Ordering connections tables by port column fails
> with '422 - The orderBy expression at position '0' is unsupported'
>
>
> Key: QPID-8104
> URL: https://issues.apache.org/jira/browse/QPID-8104
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.2
>
>
> Ordering the connections table on the virtualhost tab by port ends with error
> {{422 - The orderBy expression at position '0' is unsupported}}.
> The select clause in question uses an alias {{port.name AS port}}. In
> general the ability to express an the order by in terms of column aliases is
> supported however, the issue here seems to be that {{port}} is ambiguous and
> could refer to the {{Collection#port}} attribute or the alias.
> The user of the query API can workaround by using a column number, or specify
> the column's expression rather than alias.
> I have not looked into this further.
--
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-1752) 0.21.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372806#comment-16372806 ] ASF subversion and git services commented on PROTON-1752: - Commit bbc83aaf03521db9c4d3da896ca5be7810264643 in qpid-proton's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bbc83aa ] PROTON-1752: Update library versions after ABI review > 0.21.0 release tasks > > > Key: PROTON-1752 > URL: https://issues.apache.org/jira/browse/PROTON-1752 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: proton-c-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] (QPID-8102) [Broker-j][Web Management Console] Add UI for virtual host node auto-creation policies
[ https://issues.apache.org/jira/browse/QPID-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372842#comment-16372842 ] ASF subversion and git services commented on QPID-8102: --- Commit 056da53cac94f8c2e312baf8f19be39b91ef901b 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=056da53 ] QPID-8102: [Broker-J] Add UI for virtual host node auto-creation policies > [Broker-j][Web Management Console] Add UI for virtual host node auto-creation > policies > -- > > Key: QPID-8102 > URL: https://issues.apache.org/jira/browse/QPID-8102 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8102-Broker-J-Add-UI-for-virtual-host-node-auto.patch > > > Add UI to view/create/delete/modify virtual host node auto-creation policies -- 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-8102) [Broker-j][Web Management Console] Add UI for virtual host node auto-creation policies
[ https://issues.apache.org/jira/browse/QPID-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8102: - Status: Reviewable (was: In Progress) > [Broker-j][Web Management Console] Add UI for virtual host node auto-creation > policies > -- > > Key: QPID-8102 > URL: https://issues.apache.org/jira/browse/QPID-8102 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8102-Broker-J-Add-UI-for-virtual-host-node-auto.patch > > > Add UI to view/create/delete/modify virtual host node auto-creation policies -- 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] (QPID-8102) [Broker-j][Web Management Console] Add UI for virtual host node auto-creation policies
[ https://issues.apache.org/jira/browse/QPID-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8102: Assignee: Alex Rudyy > [Broker-j][Web Management Console] Add UI for virtual host node auto-creation > policies > -- > > Key: QPID-8102 > URL: https://issues.apache.org/jira/browse/QPID-8102 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8102-Broker-J-Add-UI-for-virtual-host-node-auto.patch > > > Add UI to view/create/delete/modify virtual host node auto-creation policies -- 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] (QPID-8102) [Broker-j][Web Management Console] Add UI for virtual host node auto-creation policies
[ https://issues.apache.org/jira/browse/QPID-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8102: Assignee: Keith Wall (was: Alex Rudyy) > [Broker-j][Web Management Console] Add UI for virtual host node auto-creation > policies > -- > > Key: QPID-8102 > URL: https://issues.apache.org/jira/browse/QPID-8102 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8102-Broker-J-Add-UI-for-virtual-host-node-auto.patch > > > Add UI to view/create/delete/modify virtual host node auto-creation policies -- 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-8109) [Broker-J][WMC] Virtual Host Edit Dialog can set VH name to null
Alex Rudyy created QPID-8109:
Summary: [Broker-J][WMC] Virtual Host Edit Dialog can set VH name
to null
Key: QPID-8109
URL: https://issues.apache.org/jira/browse/QPID-8109
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-7.0.1
Reporter: Alex Rudyy
Fix For: qpid-java-broker-7.0.2
If Virtual Host Edit Dialog is used to edit several Virtual Hosts, the editing
of the second Virtual Host fails as UI name widget is initialized with null
value. As result, saving of the VH fails with error:
{quote}
422 - Attribute 'name' instance of
org.apache.qpid.server.virtualhost.berkeleydb.BDBVirtualHostImplWithAccessChecking
named 'another' cannot be null, as it is mandatory
{quote}
The issue can be worked around by refreshing the Web Management Console before
editing the Virtual Host
--
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-8102) [Broker-j][Web Management Console] Add UI for virtual host node auto-creation policies
[ https://issues.apache.org/jira/browse/QPID-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372884#comment-16372884 ] ASF subversion and git services commented on QPID-8102: --- Commit 0fe98f847484367256fda8df65deb85317cec128 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=0fe98f8 ] QPID-8102: [Broker-J][WMC] Do not reset Virtual Host Edit dialog on show > [Broker-j][Web Management Console] Add UI for virtual host node auto-creation > policies > -- > > Key: QPID-8102 > URL: https://issues.apache.org/jira/browse/QPID-8102 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8102-Broker-J-Add-UI-for-virtual-host-node-auto.patch > > > Add UI to view/create/delete/modify virtual host node auto-creation policies -- 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] (QPID-8109) [Broker-J][WMC] Virtual Host Edit Dialog can set VH name to null
[
https://issues.apache.org/jira/browse/QPID-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy closed QPID-8109.
Resolution: Invalid
Fix Version/s: (was: qpid-java-broker-7.0.2)
The issue does not affect 7.0. It was introduced as part of changes for
QPID-8102. Closing this JIRA as invalid as the fix is committed against
original JIRA ([
https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0fe98f8 ])
> [Broker-J][WMC] Virtual Host Edit Dialog can set VH name to null
>
>
> Key: QPID-8109
> URL: https://issues.apache.org/jira/browse/QPID-8109
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Priority: Major
>
> If Virtual Host Edit Dialog is used to edit several Virtual Hosts, the
> editing of the second Virtual Host fails as UI name widget is initialized
> with null value. As result, saving of the VH fails with error:
> {quote}
> 422 - Attribute 'name' instance of
> org.apache.qpid.server.virtualhost.berkeleydb.BDBVirtualHostImplWithAccessChecking
> named 'another' cannot be null, as it is mandatory
> {quote}
> The issue can be worked around by refreshing the Web Management Console
> before editing the Virtual Host
--
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-broker-j issue #4: QPID-7972: [Broker-J] Put VirtualHostNode in ERRORed...
Github user k-wall commented on the issue: https://github.com/apache/qpid-broker-j/pull/4 Hello Olivier Thanks for the contribution. It is much appreciated. I am not too uncomfortable with the idea of special casing of the state behaviour for this one type of VirtualHostNode. I think in the long term, in general parent objects should have some way to react to the state of the their child, but I think this would want to be done within the common mechanics of AbstractConfiguredObject rather than applied piecemeal. It would be useful to be able to apply different rules - for instance a virtualhost might be considered critical whereas a BrokerSyslogLogger not. This would be a larger piece of work. I am looking for another way to solve your problem. Looking at `BrokerImpl#performActivation`, it currently checks the immediate decedents of the Broker if `broker.failStartupWithErroredChild` is set. We could alter this code so it can either check immediate descendants or the state of the entire tree. If the code had that ability would your use case by answered? --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7972) Virtual Host Node should be in error state if the underlying Virtual Host is in error state
[ https://issues.apache.org/jira/browse/QPID-7972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372900#comment-16372900 ] ASF GitHub Bot commented on QPID-7972: -- Github user k-wall commented on the issue: https://github.com/apache/qpid-broker-j/pull/4 Hello Olivier Thanks for the contribution. It is much appreciated. I am not too uncomfortable with the idea of special casing of the state behaviour for this one type of VirtualHostNode. I think in the long term, in general parent objects should have some way to react to the state of the their child, but I think this would want to be done within the common mechanics of AbstractConfiguredObject rather than applied piecemeal. It would be useful to be able to apply different rules - for instance a virtualhost might be considered critical whereas a BrokerSyslogLogger not. This would be a larger piece of work. I am looking for another way to solve your problem. Looking at `BrokerImpl#performActivation`, it currently checks the immediate decedents of the Broker if `broker.failStartupWithErroredChild` is set. We could alter this code so it can either check immediate descendants or the state of the entire tree. If the code had that ability would your use case by answered? > Virtual Host Node should be in error state if the underlying Virtual Host is > in error state > --- > > Key: QPID-7972 > URL: https://issues.apache.org/jira/browse/QPID-7972 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-6.1.4 >Reporter: Adel Boutros >Priority: Major > > All details can be found here: > http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-6-1-4-Broker-is-ready-even-if-an-error-is-occuring-on-startup-and-failStartupWithEre-tp7668029.html -- 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-931) Syntax error and missing dependencies in docker files
Ken Giusti created DISPATCH-931: --- Summary: Syntax error and missing dependencies in docker files Key: DISPATCH-931 URL: https://issues.apache.org/jira/browse/DISPATCH-931 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 1.0.0, 1.0.1 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 1.1.0 Need to add unittest2 dependency and fix a syntax error -- 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-dispatch pull request #260: DISPATCH-931: update dockerfiles with new d...
GitHub user kgiusti opened a pull request: https://github.com/apache/qpid-dispatch/pull/260 DISPATCH-931: update dockerfiles with new dependency and fix syntax e⦠â¦rror You can merge this pull request into a Git repository by running: $ git pull https://github.com/kgiusti/dispatch DISPATCH-931 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/260.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #260 commit 8957fa87705e71a067fd2308d9403fe13801da34 Author: Kenneth Giusti Date: 2018-02-22T15:34:04Z DISPATCH-931: update dockerfiles with new dependency and fix syntax error --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-931) Syntax error and missing dependencies in docker files
[ https://issues.apache.org/jira/browse/DISPATCH-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372959#comment-16372959 ] ASF GitHub Bot commented on DISPATCH-931: - GitHub user kgiusti opened a pull request: https://github.com/apache/qpid-dispatch/pull/260 DISPATCH-931: update dockerfiles with new dependency and fix syntax e… …rror You can merge this pull request into a Git repository by running: $ git pull https://github.com/kgiusti/dispatch DISPATCH-931 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/260.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #260 commit 8957fa87705e71a067fd2308d9403fe13801da34 Author: Kenneth Giusti Date: 2018-02-22T15:34:04Z DISPATCH-931: update dockerfiles with new dependency and fix syntax error > Syntax error and missing dependencies in docker files > - > > Key: DISPATCH-931 > URL: https://issues.apache.org/jira/browse/DISPATCH-931 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0, 1.0.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.1.0 > > > Need to add unittest2 dependency and fix a syntax error -- 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-1767) [proton-j] Allow the Transport to expose an output buffer that is not read-only
[ https://issues.apache.org/jira/browse/PROTON-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373067#comment-16373067 ] ASF subversion and git services commented on PROTON-1767: - Commit ca492f66ab9653afcdd1d0904b359e27a362859d in qpid-proton-j's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=ca492f6 ] PROTON-1767 Allow for the sasl buffer to use a duplicate Adds support in the SaslImpl for also exposing a duplicate buffer instead of a read-only variant. > [proton-j] Allow the Transport to expose an output buffer that is not > read-only > --- > > Key: PROTON-1767 > URL: https://issues.apache.org/jira/browse/PROTON-1767 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.25.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: proton-j-0.26.0 > > > In some cases the read-only output buffer exposed by TransportImpl by calling > head() or getOutputBuffer() can lead to extra intermediate copies of the > buffer based on the IO framework being used to transmit the bytes (such as > current Netty releases). This is due to the fact that the read-only buffer > reports that it doesn't have a backing array so the frameworks try to work > around this to optimize the transfer of bytes. For uses who are aware of > this and can ensure they never tamper with the buffer contents that aren't > consumed we should let them choose to expose a writable duplicate of the > output buffer. -- 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] (PROTON-1770) CLONE - [cpp] win_iocp fix for seg fault in reconnect test
Alan Conway created PROTON-1770:
---
Summary: CLONE - [cpp] win_iocp fix for seg fault in reconnect test
Key: PROTON-1770
URL: https://issues.apache.org/jira/browse/PROTON-1770
Project: Qpid Proton
Issue Type: Improvement
Components: cpp-binding, proton-c
Affects Versions: proton-c-0.20.0
Reporter: Alan Conway
Assignee: Alan Conway
Fix For: proton-c-0.21.0
See [https://issues.jboss.org/browse/ENTMQCL-600] for details and reproducer
code, summary:
Using the to be attached reproducer and broker configuration:
Running amqsender
./amqsender
e.g.
./amqsender testbox111:5672 testbox111:5673 anon anon Q1 1
You can reproduce the coredump with just one broker
1. keep slave down
2. start master broker
3. run amqsender with a very low frequency
4. kill master broker
This should reproduce the coredump.
The reproducer has events implemented for on_transport_close yet we see:
{code}
.
.
.
[0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
[0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
[0x7fffec0169b0]:(PN_CONNECTION_WAKE, pn_connection<0x7fffec000b90>)
AMQSender::on_connection_wake pn_connection<0x7fffec000b90>
[0x7fffec0169b0]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x7fffec0169b0>)
[0x7fffec0169b0]:(PN_TRANSPORT_ERROR, pn_transport<0x7fffec0169b0>)
[0x7fffec0169b0]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x7fffec0169b0>)
[0x7fffec0169b0]:(PN_TRANSPORT_CLOSED, pn_transport<0x7fffec0169b0>)
[0x7fffec0169b0]:(PN_CONNECTION_INIT, pn_connection<0x7fffec000b90>)
Thread 1 "amqsender" received signal SIGSEGV, Segmentation fault.
0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
Missing separate debuginfos, use: dnf debuginfo-install
cyrus-sasl-gssapi-2.1.26-26.2.fc24.x86_64
cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 cyrus-sasl-md5-2.1.26-26.2.fc24.x86_64
cyrus-sasl-plain-2.1.26-26.2.fc24.x86_64
cyrus-sasl-scram-2.1.26-26.2.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
krb5-libs-1.14.4-7.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64
libcrypt-nss-2.24-4.fc25.x86_64 libdb-5.3.28-16.fc25.x86_64
libgcc-6.3.1-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
libstdc++-6.3.1-1.fc25.x86_64 nss-softokn-freebl-3.28.3-1.1.fc25.x86_64
openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.40-5.fc25.x86_64
zlib-1.2.8-10.fc24.x86_64
(gdb) bt
#0 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1 0x776dc4fa in lock (m=0x1a0) at
/home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:112
#2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
/home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
#3 0x776def0e in pn_connection_wake (c=0x7fffec000b90) at
/home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:1302
#4 0x77b81b82 in proton::container::impl::connection_work_queue::add
(this=0x7fffec001d30, f=...) at
/home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:118
#5 0x77bacde5 in proton::work_queue::add (this=0x7fffec001cd8, f=...)
at
/home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/work_queue.cpp:43
#6 0x0040536f in AMQSender::send (this=this@entry=0x7fffd960,
strMsg="7578") at ../attachments/AMQSender.cpp:42
#7 0x0040328f in main (argc=, argv=0x7fffdbd8) at
../attachments/amqsend.cpp:20
(gdb) frame 2
#2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
/home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
436 lock(&p->eventfd_mutex);
(gdb) print p
$3 = (pn_proactor_t *) 0x0
(gdb)
{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] [Comment Edited] (QPID-8102) [Broker-j][Web Management Console] Add UI for virtual host node auto-creation policies
[ https://issues.apache.org/jira/browse/QPID-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373108#comment-16373108 ] Keith Wall edited comment on QPID-8102 at 2/22/18 5:26 PM: --- Alex - here are my review comments: # In the new Node Auto Creation Policy table on the virtualhost tab, the rendering of attributes does not escape the content, so I am able to inject markup/script into the browser. # Node Auto Creation Policy dialogue ## When editing an existing policy it is possible to create a new one by changing its name. Perhaps we should make the name immutable? ## Pattern field - missing promptMessage. We should explain that new nodes with names matching this pattern will be created automatically. ## Pattern field - the placeholder text is misleading ## Node type field - missing promptMessage. ## Attributes - nothing explains to the user what these attributes are used for (or what attributes would be understood) ## The select all checkbox does not work was (Author: k-wall): # In the new Node Auto Creation Policy table on the virtualhost tab, the rendering of attributes does not escape the content, so I am able to inject markup/script into the browser. # Node Auto Creation Policy dialogue ## When editing an existing policy it is possible to create a new one by changing its name. Perhaps we should make the name immutable? ## Pattern field - missing promptMessage. We should explain that new nodes with names matching this pattern will be created automatically. ## Pattern field - the placeholder text is misleading ## Node type field - missing promptMessage. ## Attributes - nothing explains to the user what these attributes are used for (or what attributes would be understood) ## The select all checkbox does not work > [Broker-j][Web Management Console] Add UI for virtual host node auto-creation > policies > -- > > Key: QPID-8102 > URL: https://issues.apache.org/jira/browse/QPID-8102 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8102-Broker-J-Add-UI-for-virtual-host-node-auto.patch > > > Add UI to view/create/delete/modify virtual host node auto-creation policies -- 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-8102) [Broker-j][Web Management Console] Add UI for virtual host node auto-creation policies
[ https://issues.apache.org/jira/browse/QPID-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373108#comment-16373108 ] Keith Wall commented on QPID-8102: -- # In the new Node Auto Creation Policy table on the virtualhost tab, the rendering of attributes does not escape the content, so I am able to inject markup/script into the browser. # Node Auto Creation Policy dialogue ## When editing an existing policy it is possible to create a new one by changing its name. Perhaps we should make the name immutable? ## Pattern field - missing promptMessage. We should explain that new nodes with names matching this pattern will be created automatically. ## Pattern field - the placeholder text is misleading ## Node type field - missing promptMessage. ## Attributes - nothing explains to the user what these attributes are used for (or what attributes would be understood) ## The select all checkbox does not work > [Broker-j][Web Management Console] Add UI for virtual host node auto-creation > policies > -- > > Key: QPID-8102 > URL: https://issues.apache.org/jira/browse/QPID-8102 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8102-Broker-J-Add-UI-for-virtual-host-node-auto.patch > > > Add UI to view/create/delete/modify virtual host node auto-creation policies -- 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-1770) CLONE - [cpp] win_iocp fix for seg fault in reconnect test
[
https://issues.apache.org/jira/browse/PROTON-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned PROTON-1770:
---
Assignee: Cliff Jansen (was: Alan Conway)
> CLONE - [cpp] win_iocp fix for seg fault in reconnect test
> --
>
> Key: PROTON-1770
> URL: https://issues.apache.org/jira/browse/PROTON-1770
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Cliff Jansen
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> See [https://issues.jboss.org/browse/ENTMQCL-600] for details and reproducer
> code, summary:
>
> Using the to be attached reproducer and broker configuration:
> Running amqsender
> ./amqsender microseconds>
> e.g.
> ./amqsender testbox111:5672 testbox111:5673 anon anon Q1 1
> You can reproduce the coredump with just one broker
> 1. keep slave down
> 2. start master broker
> 3. run amqsender with a very low frequency
> 4. kill master broker
> This should reproduce the coredump.
> The reproducer has events implemented for on_transport_close yet we see:
> {code}
> .
> .
> .
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_WAKE, pn_connection<0x7fffec000b90>)
> AMQSender::on_connection_wake pn_connection<0x7fffec000b90>
> [0x7fffec0169b0]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_ERROR, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_INIT, pn_connection<0x7fffec000b90>)
> Thread 1 "amqsender" received signal SIGSEGV, Segmentation fault.
> 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 cyrus-sasl-md5-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-plain-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-scram-2.1.26-26.2.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
> krb5-libs-1.14.4-7.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64
> libcrypt-nss-2.24-4.fc25.x86_64 libdb-5.3.28-16.fc25.x86_64
> libgcc-6.3.1-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
> libstdc++-6.3.1-1.fc25.x86_64 nss-softokn-freebl-3.28.3-1.1.fc25.x86_64
> openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.40-5.fc25.x86_64
> zlib-1.2.8-10.fc24.x86_64
> (gdb) bt
> #0 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x776dc4fa in lock (m=0x1a0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:112
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> #3 0x776def0e in pn_connection_wake (c=0x7fffec000b90) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:1302
> #4 0x77b81b82 in proton::container::impl::connection_work_queue::add
> (this=0x7fffec001d30, f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:118
> #5 0x77bacde5 in proton::work_queue::add (this=0x7fffec001cd8,
> f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/work_queue.cpp:43
> #6 0x0040536f in AMQSender::send (this=this@entry=0x7fffd960,
> strMsg="7578") at ../attachments/AMQSender.cpp:42
> #7 0x0040328f in main (argc=, argv=0x7fffdbd8) at
> ../attachments/amqsend.cpp:20
> (gdb) frame 2
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> 436 lock(&p->eventfd_mutex);
> (gdb) print p
> $3 = (pn_proactor_t *) 0x0
> (gdb)
> {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-1770) CLONE - [cpp] win_iocp fix for seg fault in reconnect test
[
https://issues.apache.org/jira/browse/PROTON-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved PROTON-1770.
-
Resolution: Fixed
> CLONE - [cpp] win_iocp fix for seg fault in reconnect test
> --
>
> Key: PROTON-1770
> URL: https://issues.apache.org/jira/browse/PROTON-1770
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Cliff Jansen
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> See [https://issues.jboss.org/browse/ENTMQCL-600] for details and reproducer
> code, summary:
>
> Using the to be attached reproducer and broker configuration:
> Running amqsender
> ./amqsender microseconds>
> e.g.
> ./amqsender testbox111:5672 testbox111:5673 anon anon Q1 1
> You can reproduce the coredump with just one broker
> 1. keep slave down
> 2. start master broker
> 3. run amqsender with a very low frequency
> 4. kill master broker
> This should reproduce the coredump.
> The reproducer has events implemented for on_transport_close yet we see:
> {code}
> .
> .
> .
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_WAKE, pn_connection<0x7fffec000b90>)
> AMQSender::on_connection_wake pn_connection<0x7fffec000b90>
> [0x7fffec0169b0]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_ERROR, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_INIT, pn_connection<0x7fffec000b90>)
> Thread 1 "amqsender" received signal SIGSEGV, Segmentation fault.
> 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 cyrus-sasl-md5-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-plain-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-scram-2.1.26-26.2.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
> krb5-libs-1.14.4-7.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64
> libcrypt-nss-2.24-4.fc25.x86_64 libdb-5.3.28-16.fc25.x86_64
> libgcc-6.3.1-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
> libstdc++-6.3.1-1.fc25.x86_64 nss-softokn-freebl-3.28.3-1.1.fc25.x86_64
> openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.40-5.fc25.x86_64
> zlib-1.2.8-10.fc24.x86_64
> (gdb) bt
> #0 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x776dc4fa in lock (m=0x1a0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:112
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> #3 0x776def0e in pn_connection_wake (c=0x7fffec000b90) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:1302
> #4 0x77b81b82 in proton::container::impl::connection_work_queue::add
> (this=0x7fffec001d30, f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:118
> #5 0x77bacde5 in proton::work_queue::add (this=0x7fffec001cd8,
> f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/work_queue.cpp:43
> #6 0x0040536f in AMQSender::send (this=this@entry=0x7fffd960,
> strMsg="7578") at ../attachments/AMQSender.cpp:42
> #7 0x0040328f in main (argc=, argv=0x7fffdbd8) at
> ../attachments/amqsend.cpp:20
> (gdb) frame 2
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> 436 lock(&p->eventfd_mutex);
> (gdb) print p
> $3 = (pn_proactor_t *) 0x0
> (gdb)
> {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-1770) CLONE - [cpp] win_iocp fix for seg fault in reconnect test
[
https://issues.apache.org/jira/browse/PROTON-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373111#comment-16373111
]
Alan Conway commented on PROTON-1770:
-
Fixed for epoll and libuv, see commits for PROTON-1766.
Equivalent fix needed for windows. Summary of changes:
No longer use pn_connection_attachments to find the back-pointer from
pn_connection_t to the proactors data structure.
Instead use pn_conection_driver_ptr to get a pointer to the driver and
offsetof() to find the start of the complete proactor data structure that it is
embedded in.
Since pn_connection_driver_ptr is only called by the proactor, all uses can be
locked. Epoll and libuv currently use a global mutex, but an atomic load/store
with acquire/release memory barriers would do. Not done immediately for lack of
portable C atomics, but dispatch has some we can steal in future. I think
windows already has these.
For epoll I made one other change - we no longer use pn_refcounts to manage the
pconnection lifecycle. The original reason was to leave the pconnection in
place even after the connection was no longer owned by the proactor, so
pn_connection_wake would not crash. Thats no longer required since this change
fixes the pn_connection_wake race even if we disassociate a connection from its
proactor state.
> CLONE - [cpp] win_iocp fix for seg fault in reconnect test
> --
>
> Key: PROTON-1770
> URL: https://issues.apache.org/jira/browse/PROTON-1770
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Cliff Jansen
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> See [https://issues.jboss.org/browse/ENTMQCL-600] for details and reproducer
> code, summary:
>
> Using the to be attached reproducer and broker configuration:
> Running amqsender
> ./amqsender microseconds>
> e.g.
> ./amqsender testbox111:5672 testbox111:5673 anon anon Q1 1
> You can reproduce the coredump with just one broker
> 1. keep slave down
> 2. start master broker
> 3. run amqsender with a very low frequency
> 4. kill master broker
> This should reproduce the coredump.
> The reproducer has events implemented for on_transport_close yet we see:
> {code}
> .
> .
> .
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_WAKE, pn_connection<0x7fffec000b90>)
> AMQSender::on_connection_wake pn_connection<0x7fffec000b90>
> [0x7fffec0169b0]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_ERROR, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_INIT, pn_connection<0x7fffec000b90>)
> Thread 1 "amqsender" received signal SIGSEGV, Segmentation fault.
> 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 cyrus-sasl-md5-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-plain-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-scram-2.1.26-26.2.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
> krb5-libs-1.14.4-7.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64
> libcrypt-nss-2.24-4.fc25.x86_64 libdb-5.3.28-16.fc25.x86_64
> libgcc-6.3.1-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
> libstdc++-6.3.1-1.fc25.x86_64 nss-softokn-freebl-3.28.3-1.1.fc25.x86_64
> openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.40-5.fc25.x86_64
> zlib-1.2.8-10.fc24.x86_64
> (gdb) bt
> #0 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x776dc4fa in lock (m=0x1a0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:112
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> #3 0x776def0e in pn_connection_wake (c=0x7fffec000b90) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:1302
> #4 0x77b81b82 in proton::container::impl::connection_work_queue::add
> (this=0x7fffec001d30, f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:118
> #5 0x77bacde5 in proton::work_queue::add (this=0x7fffec001cd8,
> f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/work_queue.cpp:43
> #6 0x0040536f in AMQSender::send (this=this@entry=0x7fffd960,
> strMsg="7578") at ../attachmen
[jira] [Reopened] (PROTON-1770) CLONE - [cpp] win_iocp fix for seg fault in reconnect test
[
https://issues.apache.org/jira/browse/PROTON-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reopened PROTON-1770:
-
Closed by mistake
> CLONE - [cpp] win_iocp fix for seg fault in reconnect test
> --
>
> Key: PROTON-1770
> URL: https://issues.apache.org/jira/browse/PROTON-1770
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Cliff Jansen
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> See [https://issues.jboss.org/browse/ENTMQCL-600] for details and reproducer
> code, summary:
>
> Using the to be attached reproducer and broker configuration:
> Running amqsender
> ./amqsender microseconds>
> e.g.
> ./amqsender testbox111:5672 testbox111:5673 anon anon Q1 1
> You can reproduce the coredump with just one broker
> 1. keep slave down
> 2. start master broker
> 3. run amqsender with a very low frequency
> 4. kill master broker
> This should reproduce the coredump.
> The reproducer has events implemented for on_transport_close yet we see:
> {code}
> .
> .
> .
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_WAKE, pn_connection<0x7fffec000b90>)
> AMQSender::on_connection_wake pn_connection<0x7fffec000b90>
> [0x7fffec0169b0]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_ERROR, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_INIT, pn_connection<0x7fffec000b90>)
> Thread 1 "amqsender" received signal SIGSEGV, Segmentation fault.
> 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 cyrus-sasl-md5-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-plain-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-scram-2.1.26-26.2.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
> krb5-libs-1.14.4-7.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64
> libcrypt-nss-2.24-4.fc25.x86_64 libdb-5.3.28-16.fc25.x86_64
> libgcc-6.3.1-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
> libstdc++-6.3.1-1.fc25.x86_64 nss-softokn-freebl-3.28.3-1.1.fc25.x86_64
> openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.40-5.fc25.x86_64
> zlib-1.2.8-10.fc24.x86_64
> (gdb) bt
> #0 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x776dc4fa in lock (m=0x1a0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:112
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> #3 0x776def0e in pn_connection_wake (c=0x7fffec000b90) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:1302
> #4 0x77b81b82 in proton::container::impl::connection_work_queue::add
> (this=0x7fffec001d30, f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:118
> #5 0x77bacde5 in proton::work_queue::add (this=0x7fffec001cd8,
> f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/work_queue.cpp:43
> #6 0x0040536f in AMQSender::send (this=this@entry=0x7fffd960,
> strMsg="7578") at ../attachments/AMQSender.cpp:42
> #7 0x0040328f in main (argc=, argv=0x7fffdbd8) at
> ../attachments/amqsend.cpp:20
> (gdb) frame 2
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> 436 lock(&p->eventfd_mutex);
> (gdb) print p
> $3 = (pn_proactor_t *) 0x0
> (gdb)
> {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-8104) [Broker-J] [Query] [WMC] Ordering connections tables by port column fails with '422 - The orderBy expression at position '0' is unsupported'
[
https://issues.apache.org/jira/browse/QPID-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373114#comment-16373114
]
ASF subversion and git services commented on QPID-8104:
---
Commit 9704e609db36102d40d074a866799d0fe3930ffa 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=9704e60 ]
QPID-8104: [Broker-J] [Query] Support the use of aliases in order by clauses
> [Broker-J] [Query] [WMC] Ordering connections tables by port column fails
> with '422 - The orderBy expression at position '0' is unsupported'
>
>
> Key: QPID-8104
> URL: https://issues.apache.org/jira/browse/QPID-8104
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.2
>
>
> Ordering the connections table on the virtualhost tab by port ends with error
> {{422 - The orderBy expression at position '0' is unsupported}}.
> The select clause in question uses an alias {{port.name AS port}}. In
> general the ability to express an the order by in terms of column aliases is
> supported however, the issue here seems to be that {{port}} is ambiguous and
> could refer to the {{Collection#port}} attribute or the alias.
> The user of the query API can workaround by using a column number, or specify
> the column's expression rather than alias.
> I have not looked into this further.
--
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-1766) [cpp] seg fault in reconnect test
[
https://issues.apache.org/jira/browse/PROTON-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved PROTON-1766.
-
Resolution: Fixed
> [cpp] seg fault in reconnect test
> -
>
> Key: PROTON-1766
> URL: https://issues.apache.org/jira/browse/PROTON-1766
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> See [https://issues.jboss.org/browse/ENTMQCL-600] for details and reproducer
> code, summary:
>
> Using the to be attached reproducer and broker configuration:
> Running amqsender
> ./amqsender microseconds>
> e.g.
> ./amqsender testbox111:5672 testbox111:5673 anon anon Q1 1
> You can reproduce the coredump with just one broker
> 1. keep slave down
> 2. start master broker
> 3. run amqsender with a very low frequency
> 4. kill master broker
> This should reproduce the coredump.
> The reproducer has events implemented for on_transport_close yet we see:
> {code}
> .
> .
> .
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_WAKE, pn_connection<0x7fffec000b90>)
> AMQSender::on_connection_wake pn_connection<0x7fffec000b90>
> [0x7fffec0169b0]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_ERROR, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_INIT, pn_connection<0x7fffec000b90>)
> Thread 1 "amqsender" received signal SIGSEGV, Segmentation fault.
> 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 cyrus-sasl-md5-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-plain-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-scram-2.1.26-26.2.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
> krb5-libs-1.14.4-7.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64
> libcrypt-nss-2.24-4.fc25.x86_64 libdb-5.3.28-16.fc25.x86_64
> libgcc-6.3.1-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
> libstdc++-6.3.1-1.fc25.x86_64 nss-softokn-freebl-3.28.3-1.1.fc25.x86_64
> openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.40-5.fc25.x86_64
> zlib-1.2.8-10.fc24.x86_64
> (gdb) bt
> #0 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x776dc4fa in lock (m=0x1a0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:112
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> #3 0x776def0e in pn_connection_wake (c=0x7fffec000b90) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:1302
> #4 0x77b81b82 in proton::container::impl::connection_work_queue::add
> (this=0x7fffec001d30, f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:118
> #5 0x77bacde5 in proton::work_queue::add (this=0x7fffec001cd8,
> f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/work_queue.cpp:43
> #6 0x0040536f in AMQSender::send (this=this@entry=0x7fffd960,
> strMsg="7578") at ../attachments/AMQSender.cpp:42
> #7 0x0040328f in main (argc=, argv=0x7fffdbd8) at
> ../attachments/amqsend.cpp:20
> (gdb) frame 2
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> 436 lock(&p->eventfd_mutex);
> (gdb) print p
> $3 = (pn_proactor_t *) 0x0
> (gdb)
> {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-1766) [cpp] seg fault in reconnect test
[
https://issues.apache.org/jira/browse/PROTON-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373134#comment-16373134
]
Alan Conway commented on PROTON-1766:
-
Fixed on epoll and libuv. NOT fixed for windows IOCP. New issue PROTON-1770 to
track the windows fix.
> [cpp] seg fault in reconnect test
> -
>
> Key: PROTON-1766
> URL: https://issues.apache.org/jira/browse/PROTON-1766
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> See [https://issues.jboss.org/browse/ENTMQCL-600] for details and reproducer
> code, summary:
>
> Using the to be attached reproducer and broker configuration:
> Running amqsender
> ./amqsender microseconds>
> e.g.
> ./amqsender testbox111:5672 testbox111:5673 anon anon Q1 1
> You can reproduce the coredump with just one broker
> 1. keep slave down
> 2. start master broker
> 3. run amqsender with a very low frequency
> 4. kill master broker
> This should reproduce the coredump.
> The reproducer has events implemented for on_transport_close yet we see:
> {code}
> .
> .
> .
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_WAKE, pn_connection<0x7fffec000b90>)
> AMQSender::on_connection_wake pn_connection<0x7fffec000b90>
> [0x7fffec0169b0]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_ERROR, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_INIT, pn_connection<0x7fffec000b90>)
> Thread 1 "amqsender" received signal SIGSEGV, Segmentation fault.
> 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 cyrus-sasl-md5-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-plain-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-scram-2.1.26-26.2.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
> krb5-libs-1.14.4-7.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64
> libcrypt-nss-2.24-4.fc25.x86_64 libdb-5.3.28-16.fc25.x86_64
> libgcc-6.3.1-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
> libstdc++-6.3.1-1.fc25.x86_64 nss-softokn-freebl-3.28.3-1.1.fc25.x86_64
> openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.40-5.fc25.x86_64
> zlib-1.2.8-10.fc24.x86_64
> (gdb) bt
> #0 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x776dc4fa in lock (m=0x1a0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:112
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> #3 0x776def0e in pn_connection_wake (c=0x7fffec000b90) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:1302
> #4 0x77b81b82 in proton::container::impl::connection_work_queue::add
> (this=0x7fffec001d30, f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:118
> #5 0x77bacde5 in proton::work_queue::add (this=0x7fffec001cd8,
> f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/work_queue.cpp:43
> #6 0x0040536f in AMQSender::send (this=this@entry=0x7fffd960,
> strMsg="7578") at ../attachments/AMQSender.cpp:42
> #7 0x0040328f in main (argc=, argv=0x7fffdbd8) at
> ../attachments/amqsend.cpp:20
> (gdb) frame 2
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> 436 lock(&p->eventfd_mutex);
> (gdb) print p
> $3 = (pn_proactor_t *) 0x0
> (gdb)
> {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
[GitHub] qpid-dispatch pull request #260: DISPATCH-931: update dockerfiles with new d...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/260 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-931) Syntax error and missing dependencies in docker files
[ https://issues.apache.org/jira/browse/DISPATCH-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373207#comment-16373207 ] ASF GitHub Bot commented on DISPATCH-931: - Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/260 > Syntax error and missing dependencies in docker files > - > > Key: DISPATCH-931 > URL: https://issues.apache.org/jira/browse/DISPATCH-931 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0, 1.0.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.1.0 > > > Need to add unittest2 dependency and fix a syntax error -- 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-931) Syntax error and missing dependencies in docker files
[ https://issues.apache.org/jira/browse/DISPATCH-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373206#comment-16373206 ] ASF subversion and git services commented on DISPATCH-931: -- Commit f0b2e52eafeb8a46397acf8fb5bc2f48342b88ba in qpid-dispatch's branch refs/heads/master from Kenneth Giusti [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f0b2e52 ] DISPATCH-931: update dockerfiles with new dependency and fix syntax error. This closes #260 > Syntax error and missing dependencies in docker files > - > > Key: DISPATCH-931 > URL: https://issues.apache.org/jira/browse/DISPATCH-931 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0, 1.0.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.1.0 > > > Need to add unittest2 dependency and fix a syntax error -- 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-1734) [cpp] container.stop() doesn't work when called from non-proactor thread.
[
https://issues.apache.org/jira/browse/PROTON-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373364#comment-16373364
]
ASF subversion and git services commented on PROTON-1734:
-
Commit 093355f604d0b3503f6627cb2f28022af0ef851b in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=093355f ]
PROTON-1734: Doc changes only
> [cpp] container.stop() doesn't work when called from non-proactor thread.
> -
>
> Key: PROTON-1734
> URL: https://issues.apache.org/jira/browse/PROTON-1734
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> Using the below code
> {code}
> #include
> #include
> #include
> int main( int, char** )
> {
> try
> {
> proton::container c;
> c.auto_stop( false );
> auto containerThread = std::thread([&]() { std::cout << "CONTAINER IS
> RUNNING" << std::endl;
>
> c.run(); std::cout << "CONTAINER IS DONE" << std::endl; });
> std::this_thread::sleep_for( std::chrono::seconds( 2 ));
> std::cout << "STOPPING CONTAINER" << std::endl;
> c.stop();
> std::cout << "WAITING FOR CONTAINER" << std::endl;
> containerThread.join();
> return 0;
> }
> catch( std::exception& e )
> {
> std::cerr << e.what() << std::endl;
> }
> return 1;
> }
> {code}
> via
> {code}
> [rkieley@i7t450s build]$ g++ -g -Wall -Wextra -Wpointer-arith -Wconversion
> -Wformat -Wformat-security -Wformat-y2k -Wsign-promo -Wcast-qual -g3 -ggdb3
> -Wunused-variable -fno-eliminate-unused-debug-types -O3 -DNDEBUG -fPIC
> -DPN_CPP_HAS_LAMBDAS=0 -std=gnu++11 ../attachments/test.cpp
> -lqpid-proton-cpp -lqpid-proton-core -lqpid-proton-proactor -lrt -lpthread -o
> test
> {code}
> With both PROACTOR epoll and libuv I see the following when run:
> {quote}
> [New Thread 0x73c95700 (LWP 20312)]
> CONTAINER IS RUNNING
> STOPPING CONTAINER
> WAITING FOR CONTAINER
> ^C
> Thread 1 "test" received signal SIGINT, Interrupt.
> {quote}
> When I use CTRL-C to stop waiting after running via gdb and waiting 2 minutes.
--
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-1734) [cpp] container.stop() doesn't work when called from non-proactor thread.
[
https://issues.apache.org/jira/browse/PROTON-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373368#comment-16373368
]
ASF subversion and git services commented on PROTON-1734:
-
Commit 2b51dcf56334f68603a3c47538fc45e7e534acc8 in qpid-proton's branch
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2b51dcf ]
PROTON-1734: Fix Win32 iocp implementation
> [cpp] container.stop() doesn't work when called from non-proactor thread.
> -
>
> Key: PROTON-1734
> URL: https://issues.apache.org/jira/browse/PROTON-1734
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> Using the below code
> {code}
> #include
> #include
> #include
> int main( int, char** )
> {
> try
> {
> proton::container c;
> c.auto_stop( false );
> auto containerThread = std::thread([&]() { std::cout << "CONTAINER IS
> RUNNING" << std::endl;
>
> c.run(); std::cout << "CONTAINER IS DONE" << std::endl; });
> std::this_thread::sleep_for( std::chrono::seconds( 2 ));
> std::cout << "STOPPING CONTAINER" << std::endl;
> c.stop();
> std::cout << "WAITING FOR CONTAINER" << std::endl;
> containerThread.join();
> return 0;
> }
> catch( std::exception& e )
> {
> std::cerr << e.what() << std::endl;
> }
> return 1;
> }
> {code}
> via
> {code}
> [rkieley@i7t450s build]$ g++ -g -Wall -Wextra -Wpointer-arith -Wconversion
> -Wformat -Wformat-security -Wformat-y2k -Wsign-promo -Wcast-qual -g3 -ggdb3
> -Wunused-variable -fno-eliminate-unused-debug-types -O3 -DNDEBUG -fPIC
> -DPN_CPP_HAS_LAMBDAS=0 -std=gnu++11 ../attachments/test.cpp
> -lqpid-proton-cpp -lqpid-proton-core -lqpid-proton-proactor -lrt -lpthread -o
> test
> {code}
> With both PROACTOR epoll and libuv I see the following when run:
> {quote}
> [New Thread 0x73c95700 (LWP 20312)]
> CONTAINER IS RUNNING
> STOPPING CONTAINER
> WAITING FOR CONTAINER
> ^C
> Thread 1 "test" received signal SIGINT, Interrupt.
> {quote}
> When I use CTRL-C to stop waiting after running via gdb and waiting 2 minutes.
--
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-1734) [cpp] container.stop() doesn't work when called from non-proactor thread.
[
https://issues.apache.org/jira/browse/PROTON-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373365#comment-16373365
]
ASF subversion and git services commented on PROTON-1734:
-
Commit 5d47e615a8ba322a65fd41735c0c6adb36828bed in qpid-proton's branch
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5d47e61 ]
PROTON-1734: Fix the semantics of pn_proactor_disconnect()
- Make sure that an PN_PROACTOR_INACTIVE event is always generated
even if the proactor was inactive before. This ensures that we
can use disconnect effectively even before making connections
> [cpp] container.stop() doesn't work when called from non-proactor thread.
> -
>
> Key: PROTON-1734
> URL: https://issues.apache.org/jira/browse/PROTON-1734
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> Using the below code
> {code}
> #include
> #include
> #include
> int main( int, char** )
> {
> try
> {
> proton::container c;
> c.auto_stop( false );
> auto containerThread = std::thread([&]() { std::cout << "CONTAINER IS
> RUNNING" << std::endl;
>
> c.run(); std::cout << "CONTAINER IS DONE" << std::endl; });
> std::this_thread::sleep_for( std::chrono::seconds( 2 ));
> std::cout << "STOPPING CONTAINER" << std::endl;
> c.stop();
> std::cout << "WAITING FOR CONTAINER" << std::endl;
> containerThread.join();
> return 0;
> }
> catch( std::exception& e )
> {
> std::cerr << e.what() << std::endl;
> }
> return 1;
> }
> {code}
> via
> {code}
> [rkieley@i7t450s build]$ g++ -g -Wall -Wextra -Wpointer-arith -Wconversion
> -Wformat -Wformat-security -Wformat-y2k -Wsign-promo -Wcast-qual -g3 -ggdb3
> -Wunused-variable -fno-eliminate-unused-debug-types -O3 -DNDEBUG -fPIC
> -DPN_CPP_HAS_LAMBDAS=0 -std=gnu++11 ../attachments/test.cpp
> -lqpid-proton-cpp -lqpid-proton-core -lqpid-proton-proactor -lrt -lpthread -o
> test
> {code}
> With both PROACTOR epoll and libuv I see the following when run:
> {quote}
> [New Thread 0x73c95700 (LWP 20312)]
> CONTAINER IS RUNNING
> STOPPING CONTAINER
> WAITING FOR CONTAINER
> ^C
> Thread 1 "test" received signal SIGINT, Interrupt.
> {quote}
> When I use CTRL-C to stop waiting after running via gdb and waiting 2 minutes.
--
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-1734) [cpp] container.stop() doesn't work when called from non-proactor thread.
[
https://issues.apache.org/jira/browse/PROTON-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373366#comment-16373366
]
ASF subversion and git services commented on PROTON-1734:
-
Commit 0df65cc3ced56e46044981b09e7bf25a84de69ee in qpid-proton's branch
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0df65cc ]
PROTON-1734: [C++ binding] Extra tests to check that you can stop container
- This tests that pn_proactor_disconnect() can always be used even when
the container/proactor is inactive.
> [cpp] container.stop() doesn't work when called from non-proactor thread.
> -
>
> Key: PROTON-1734
> URL: https://issues.apache.org/jira/browse/PROTON-1734
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> Using the below code
> {code}
> #include
> #include
> #include
> int main( int, char** )
> {
> try
> {
> proton::container c;
> c.auto_stop( false );
> auto containerThread = std::thread([&]() { std::cout << "CONTAINER IS
> RUNNING" << std::endl;
>
> c.run(); std::cout << "CONTAINER IS DONE" << std::endl; });
> std::this_thread::sleep_for( std::chrono::seconds( 2 ));
> std::cout << "STOPPING CONTAINER" << std::endl;
> c.stop();
> std::cout << "WAITING FOR CONTAINER" << std::endl;
> containerThread.join();
> return 0;
> }
> catch( std::exception& e )
> {
> std::cerr << e.what() << std::endl;
> }
> return 1;
> }
> {code}
> via
> {code}
> [rkieley@i7t450s build]$ g++ -g -Wall -Wextra -Wpointer-arith -Wconversion
> -Wformat -Wformat-security -Wformat-y2k -Wsign-promo -Wcast-qual -g3 -ggdb3
> -Wunused-variable -fno-eliminate-unused-debug-types -O3 -DNDEBUG -fPIC
> -DPN_CPP_HAS_LAMBDAS=0 -std=gnu++11 ../attachments/test.cpp
> -lqpid-proton-cpp -lqpid-proton-core -lqpid-proton-proactor -lrt -lpthread -o
> test
> {code}
> With both PROACTOR epoll and libuv I see the following when run:
> {quote}
> [New Thread 0x73c95700 (LWP 20312)]
> CONTAINER IS RUNNING
> STOPPING CONTAINER
> WAITING FOR CONTAINER
> ^C
> Thread 1 "test" received signal SIGINT, Interrupt.
> {quote}
> When I use CTRL-C to stop waiting after running via gdb and waiting 2 minutes.
--
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-1734) [cpp] container.stop() doesn't work when called from non-proactor thread.
[
https://issues.apache.org/jira/browse/PROTON-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-1734.
-
Resolution: Fixed
> [cpp] container.stop() doesn't work when called from non-proactor thread.
> -
>
> Key: PROTON-1734
> URL: https://issues.apache.org/jira/browse/PROTON-1734
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.21.0
>
>
> Using the below code
> {code}
> #include
> #include
> #include
> int main( int, char** )
> {
> try
> {
> proton::container c;
> c.auto_stop( false );
> auto containerThread = std::thread([&]() { std::cout << "CONTAINER IS
> RUNNING" << std::endl;
>
> c.run(); std::cout << "CONTAINER IS DONE" << std::endl; });
> std::this_thread::sleep_for( std::chrono::seconds( 2 ));
> std::cout << "STOPPING CONTAINER" << std::endl;
> c.stop();
> std::cout << "WAITING FOR CONTAINER" << std::endl;
> containerThread.join();
> return 0;
> }
> catch( std::exception& e )
> {
> std::cerr << e.what() << std::endl;
> }
> return 1;
> }
> {code}
> via
> {code}
> [rkieley@i7t450s build]$ g++ -g -Wall -Wextra -Wpointer-arith -Wconversion
> -Wformat -Wformat-security -Wformat-y2k -Wsign-promo -Wcast-qual -g3 -ggdb3
> -Wunused-variable -fno-eliminate-unused-debug-types -O3 -DNDEBUG -fPIC
> -DPN_CPP_HAS_LAMBDAS=0 -std=gnu++11 ../attachments/test.cpp
> -lqpid-proton-cpp -lqpid-proton-core -lqpid-proton-proactor -lrt -lpthread -o
> test
> {code}
> With both PROACTOR epoll and libuv I see the following when run:
> {quote}
> [New Thread 0x73c95700 (LWP 20312)]
> CONTAINER IS RUNNING
> STOPPING CONTAINER
> WAITING FOR CONTAINER
> ^C
> Thread 1 "test" received signal SIGINT, Interrupt.
> {quote}
> When I use CTRL-C to stop waiting after running via gdb and waiting 2 minutes.
--
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] (DISPATCH-927) detach not echoed back on multi-hop link route
[ https://issues.apache.org/jira/browse/DISPATCH-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-927: Attachment: DISPATCH-927.patch > detach not echoed back on multi-hop link route > -- > > Key: DISPATCH-927 > URL: https://issues.apache.org/jira/browse/DISPATCH-927 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Ganesh Murthy >Priority: Major > Attachments: DISPATCH-927.patch, broker.xml, simple-topic-a.conf, > simple-topic-b.conf, simple_recv_modified.py > > > In a two router network, router-a and router-b, a link route is defined in > both directions on both routers. There is also an associated connector to a > broker on router-b. The address is configured to be a topic on the broker. > If two receivers attach on this address to router-a, and then detach at the > same time having received the defined number of messages, frequently (but not > always), one of the receivers will not get a detach echoed back to it. > On inspection of protocol traces, it appears that router-b, though it gets > the detach echoed back from the broker, does not forward this back to the > client (via router-a). -- 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] (DISPATCH-927) detach not echoed back on multi-hop link route
[ https://issues.apache.org/jira/browse/DISPATCH-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-927: -- Affects Version/s: 1.0.0 > detach not echoed back on multi-hop link route > -- > > Key: DISPATCH-927 > URL: https://issues.apache.org/jira/browse/DISPATCH-927 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0 >Reporter: Gordon Sim >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: DISPATCH-927.patch, broker.xml, simple-topic-a.conf, > simple-topic-b.conf, simple_recv_modified.py > > > In a two router network, router-a and router-b, a link route is defined in > both directions on both routers. There is also an associated connector to a > broker on router-b. The address is configured to be a topic on the broker. > If two receivers attach on this address to router-a, and then detach at the > same time having received the defined number of messages, frequently (but not > always), one of the receivers will not get a detach echoed back to it. > On inspection of protocol traces, it appears that router-b, though it gets > the detach echoed back from the broker, does not forward this back to the > client (via router-a). -- 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] (DISPATCH-927) detach not echoed back on multi-hop link route
[ https://issues.apache.org/jira/browse/DISPATCH-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-927: -- Fix Version/s: 1.1.0 > detach not echoed back on multi-hop link route > -- > > Key: DISPATCH-927 > URL: https://issues.apache.org/jira/browse/DISPATCH-927 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0 >Reporter: Gordon Sim >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: DISPATCH-927.patch, broker.xml, simple-topic-a.conf, > simple-topic-b.conf, simple_recv_modified.py > > > In a two router network, router-a and router-b, a link route is defined in > both directions on both routers. There is also an associated connector to a > broker on router-b. The address is configured to be a topic on the broker. > If two receivers attach on this address to router-a, and then detach at the > same time having received the defined number of messages, frequently (but not > always), one of the receivers will not get a detach echoed back to it. > On inspection of protocol traces, it appears that router-b, though it gets > the detach echoed back from the broker, does not forward this back to the > client (via router-a). -- 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] (DISPATCH-927) detach not echoed back on multi-hop link route
[ https://issues.apache.org/jira/browse/DISPATCH-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-927: -- Component/s: Container > detach not echoed back on multi-hop link route > -- > > Key: DISPATCH-927 > URL: https://issues.apache.org/jira/browse/DISPATCH-927 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0 >Reporter: Gordon Sim >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: DISPATCH-927.patch, broker.xml, simple-topic-a.conf, > simple-topic-b.conf, simple_recv_modified.py > > > In a two router network, router-a and router-b, a link route is defined in > both directions on both routers. There is also an associated connector to a > broker on router-b. The address is configured to be a topic on the broker. > If two receivers attach on this address to router-a, and then detach at the > same time having received the defined number of messages, frequently (but not > always), one of the receivers will not get a detach echoed back to it. > On inspection of protocol traces, it appears that router-b, though it gets > the detach echoed back from the broker, does not forward this back to the > client (via router-a). -- 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] (DISPATCH-928) calling map_destination for 'undefined' address causes segfault
[
https://issues.apache.org/jira/browse/DISPATCH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-928:
--
Affects Version/s: 1.0.0
> calling map_destination for 'undefined' address causes segfault
> ---
>
> Key: DISPATCH-928
> URL: https://issues.apache.org/jira/browse/DISPATCH-928
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> If qdr_map_destination_CT is called for an address that has not been defined
> on a router that has the default distribution set to 'undefined',
> qdr_address_CT (line 578 at present) returns null. However there is no check
> for this and the address is used to get a hash_handle which causes a segfault.
> Under valgrind you see:
> {noformat}
> ==10232== Invalid write of size 8
> ==10232==at 0x4E67501: qd_hash_internal_insert (hash.c:156)
> ==10232==by 0x4E6756B: qd_hash_insert (hash.c:168)
> ==10232==by 0x4E91644: qdr_map_destination_CT (route_tables.c:579)
> ==10232==by 0x4E8F80D: router_core_thread (router_core_thread.c:83)
> ==10232==by 0x550F739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==10232==by 0x607AE7E: clone (in /usr/lib64/libc-2.24.so)
> ==10232== Address 0x98 is not stack'd, malloc'd or (recently) free'd
> {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] [Updated] (DISPATCH-928) calling map_destination for 'undefined' address causes segfault
[
https://issues.apache.org/jira/browse/DISPATCH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-928:
--
Fix Version/s: 1.1.0
> calling map_destination for 'undefined' address causes segfault
> ---
>
> Key: DISPATCH-928
> URL: https://issues.apache.org/jira/browse/DISPATCH-928
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> If qdr_map_destination_CT is called for an address that has not been defined
> on a router that has the default distribution set to 'undefined',
> qdr_address_CT (line 578 at present) returns null. However there is no check
> for this and the address is used to get a hash_handle which causes a segfault.
> Under valgrind you see:
> {noformat}
> ==10232== Invalid write of size 8
> ==10232==at 0x4E67501: qd_hash_internal_insert (hash.c:156)
> ==10232==by 0x4E6756B: qd_hash_insert (hash.c:168)
> ==10232==by 0x4E91644: qdr_map_destination_CT (route_tables.c:579)
> ==10232==by 0x4E8F80D: router_core_thread (router_core_thread.c:83)
> ==10232==by 0x550F739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==10232==by 0x607AE7E: clone (in /usr/lib64/libc-2.24.so)
> ==10232== Address 0x98 is not stack'd, malloc'd or (recently) free'd
> {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-927) detach not echoed back on multi-hop link route
[ https://issues.apache.org/jira/browse/DISPATCH-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373448#comment-16373448 ] ASF subversion and git services commented on DISPATCH-927: -- Commit db5af96cae3e57d377cb75a9311589c7f98f7f0a in qpid-dispatch's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=db5af96 ] DISPATCH-927: only disassociate link on the closed session > detach not echoed back on multi-hop link route > -- > > Key: DISPATCH-927 > URL: https://issues.apache.org/jira/browse/DISPATCH-927 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.0 >Reporter: Gordon Sim >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: DISPATCH-927.patch, broker.xml, simple-topic-a.conf, > simple-topic-b.conf, simple_recv_modified.py > > > In a two router network, router-a and router-b, a link route is defined in > both directions on both routers. There is also an associated connector to a > broker on router-b. The address is configured to be a topic on the broker. > If two receivers attach on this address to router-a, and then detach at the > same time having received the defined number of messages, frequently (but not > always), one of the receivers will not get a detach echoed back to it. > On inspection of protocol traces, it appears that router-b, though it gets > the detach echoed back from the broker, does not forward this back to the > client (via router-a). -- 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] (DISPATCH-466) Orderly Quiescence of Links
[ https://issues.apache.org/jira/browse/DISPATCH-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-466: -- Fix Version/s: (was: 1.1.0) > Orderly Quiescence of Links > --- > > Key: DISPATCH-466 > URL: https://issues.apache.org/jira/browse/DISPATCH-466 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > > This features provides an "adminStatus" field for links which is "enabled" or > "disabled". When a link is set to disabled, its operStatus transitions from > UP to IDLE in an orderly fashion, such that message deliveries are not > dropped if an idle link is closed. > For incoming links, this means draining remaining credit and waiting for > unsettled deliveries to be settled. > For outgoing links, stop routing new deliveries to the link and wait for > unsettled deliveries to be settled. > Note that this feature is neither meaningful nor supported for routed links. -- 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] (DISPATCH-781) Tie end-to-end flow control of message-routed deliveries to outgoing capacity
[ https://issues.apache.org/jira/browse/DISPATCH-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-781: -- Fix Version/s: (was: 1.1.0) > Tie end-to-end flow control of message-routed deliveries to outgoing capacity > - > > Key: DISPATCH-781 > URL: https://issues.apache.org/jira/browse/DISPATCH-781 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node, Routing Engine >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > > This feature reverses the management of incoming credit for message-routed > deliveries. > The current mechanism is based on the the capacity of the incoming > (sender-client) links. Each attached sender is given credit equal to the > configured link capacity regardless of the capacity of outgoing > (receiver-client) links for the same address. This means that even under > congestion, a newly attached sender will get full capacity credit to send. > The proposed mechanism is based not on incoming capacity but on outgoing > capacity. In this case, the senders are provided a share of the total > outgoing capacity for an address. As the number of incoming links (senders) > for an address changes and the total capacity for outgoing links changes, the > credit window of the senders shall be adjusted. > The proposal is a heuristic approach. It does not revoke credit from senders > (but will limit the number of credits that are replenished). It will also > not deny credit if there are more incoming links than outgoing capacity. -- 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-928) calling map_destination for 'undefined' address causes segfault
[
https://issues.apache.org/jira/browse/DISPATCH-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373503#comment-16373503
]
Gordon Sim commented on DISPATCH-928:
-
More complete patch posted for review: https://reviews.apache.org/r/65760/
> calling map_destination for 'undefined' address causes segfault
> ---
>
> Key: DISPATCH-928
> URL: https://issues.apache.org/jira/browse/DISPATCH-928
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> If qdr_map_destination_CT is called for an address that has not been defined
> on a router that has the default distribution set to 'undefined',
> qdr_address_CT (line 578 at present) returns null. However there is no check
> for this and the address is used to get a hash_handle which causes a segfault.
> Under valgrind you see:
> {noformat}
> ==10232== Invalid write of size 8
> ==10232==at 0x4E67501: qd_hash_internal_insert (hash.c:156)
> ==10232==by 0x4E6756B: qd_hash_insert (hash.c:168)
> ==10232==by 0x4E91644: qdr_map_destination_CT (route_tables.c:579)
> ==10232==by 0x4E8F80D: router_core_thread (router_core_thread.c:83)
> ==10232==by 0x550F739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==10232==by 0x607AE7E: clone (in /usr/lib64/libc-2.24.so)
> ==10232== Address 0x98 is not stack'd, malloc'd or (recently) free'd
> {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
