[jira] [Commented] (DISPATCH-1110) Intermittent router hang while running QIT's AMQP large content test
[
https://issues.apache.org/jira/browse/DISPATCH-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640371#comment-16640371
]
Chuck Rolke commented on DISPATCH-1110:
---
Thanks Robbie. That looks very similar.
I have observed that the QIT send test sends eight messages and then closes the
connection. I used PN_TRACE_EVT on both the QIT Sender and the router and see
the same pattern: the Sender client closes the connection immediately after
sending and after only 2, 3, or 4 accept dispositions have been received. A
typical Sender trace (with some extra application printf commentary) is
appended.
In the QIT test I don't see how to make the sender wait around for all the
messages to be accepted before closing the connection.
> PN_TRACE_EVT=1
> /opt/local/libexec/qpid_interop_test/shims/qpid-proton-cpp/amqp_large_content_test/Sender
> [::1]:5672 qit.amqp_large_content_test.map.ProtonCpp.ProtonCpp map '[[1, [1,
> 16, 256, 4096]], [10, [1, 16, 256, 4096]]]'
[0x22f3560]:(PN_CONNECTION_INIT, pn_connection<0x22ee070>)
[0x22f3560]:(PN_SESSION_INIT, pn_session<0x22ef600>)
[0x22f3560]:(PN_LINK_INIT, pn_link<0x22f0a70>)
[0x22f3560]:(PN_CONNECTION_BOUND, pn_connection<0x22ee070>)
[0x22f3560]:(PN_CONNECTION_REMOTE_OPEN, pn_connection<0x22ee070>)
[0x22f3560]:(PN_TRANSPORT, pn_transport<0x22f3560>)
[0x22f3560]:(PN_SESSION_REMOTE_OPEN, pn_session<0x22ef600>)
[0x22f3560]:(PN_LINK_REMOTE_OPEN, pn_link<0x22f0a70>)
[0x22f3560]:(PN_LINK_FLOW, pn_link<0x22f0a70>)
on_sendable: sent 8 messages
[0x22f3560]:(PN_TRANSPORT, pn_transport<0x22f3560>)
[0x22f3560]:(PN_LINK_FLOW, pn_link<0x22f0a70>)
on_sendable: doing nothing. Already sent 8 messages
[0x22f3560]:(PN_LINK_FLOW, pn_link<0x22f0a70>)
on_sendable: doing nothing. Already sent 8 messages
[0x22f3560]:(PN_DELIVERY, pn_delivery<0x2304440>{sending,
tag=b"\x01\x00\x00\x00\x00\x00\x00\x00", local=unknown, remote=accepted})
on_tracker_accept: msgsConfirmed 1
[0x22f3560]:(PN_TRANSPORT, pn_transport<0x22f3560>)
[0x22f3560]:(PN_LINK_FLOW, pn_link<0x22f0a70>)
on_sendable: doing nothing. Already sent 8 messages
[0x22f3560]:(PN_DELIVERY, pn_delivery<0x2325490>{sending,
tag=b"\x02\x00\x00\x00\x00\x00\x00\x00", local=unknown, remote=accepted})
on_tracker_accept: msgsConfirmed 2
[0x22f3560]:(PN_CONNECTION_LOCAL_CLOSE, pn_connection<0x22ee070>) <-- QIT
Sender closes connection
[0x22f3560]:(PN_TRANSPORT, pn_transport<0x22f3560>)
[0x22f3560]:(PN_LINK_FLOW, pn_link<0x22f0a70>)
on_sendable: doing nothing. Already sent 8 messages
[0x22f3560]:(PN_DELIVERY, pn_delivery<0x2301e70>{sending,
tag=b"\x03\x00\x00\x00\x00\x00\x00\x00", local=unknown, remote=accepted})
on_tracker_accept: msgsConfirmed 3
[0x22f3560]:(PN_TRANSPORT, pn_transport<0x22f3560>)
[0x22f3560]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x22f3560>)
[0x22f3560]:(PN_LINK_FLOW, pn_link<0x22f0a70>)
on_sendable: doing nothing. Already sent 8 messages
[0x22f3560]:(PN_DELIVERY, pn_delivery<0x252aa60>{sending,
tag=b"\x04\x00\x00\x00\x00\x00\x00\x00", local=unknown, remote=accepted})
on_tracker_accept: msgsConfirmed 4
[0x22f3560]:(PN_TRANSPORT, pn_transport<0x22f3560>)
[0x22f3560]:(PN_CONNECTION_REMOTE_CLOSE, pn_connection<0x22ee070>)
[0x22f3560]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x22f3560>)
[0x22f3560]:(PN_TRANSPORT_CLOSED, pn_transport<0x22f3560>)
on_transport_close sent: 8 , confirmed: 4
on_container_stop: msgsConfirmed 4
amqp_large_content_test Sender container.run() exited
> Intermittent router hang while running QIT's AMQP large content test
>
>
> Key: DISPATCH-1110
> URL: https://issues.apache.org/jira/browse/DISPATCH-1110
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Standard QIT environment.
> Once QIT is built and installed, the environment is set using the config.sh
> file. See QUICKSTART for details.
>Reporter: Kim van der Riet
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdrouterd.conf
>
>
> When running the Qpid Interop Test's AMQP large content test, a stand-alone
> router will intermittently hang and cause the test to time out.
> The failure appears to be limited to either the AMQP list or map types, and
> usually with the C++ client as the message sender. The C++, Python2 and
> Python3 as receiver clients have all seen this failure, but the Python2
> receiver client seems to reproduce more readily on my hardware.
> In all cases, the test fails when the router sends what I suppose is the
> final transfer of a large message (I have not added up/counted the bytes of
> the many preceding transfers) to the consumer. The consumer then sends a
> disposition, but the router does not respond again until the test times out.
> The consumer can be seen to send heartbeats to the router, but the router
> does not send any of its
[jira] [Created] (DISPATCH-1140) tests for message priority
michael goulish created DISPATCH-1140: - Summary: tests for message priority Key: DISPATCH-1140 URL: https://issues.apache.org/jira/browse/DISPATCH-1140 Project: Qpid Dispatch Issue Type: New Feature Reporter: michael goulish Assignee: michael goulish The message priority code recently checked in ( in DISPATCH-1096 ) should have at least the following two tests: # Make a two-router network, A and B. Send messages from A to B, confirm that they arrive, then kill and restart B and send and confirm more messages. Do this test once with B connecting to A, and once with A connecting to B. # Two-router network again. Send some messages from A to B (i.e. sender attached to A, rcvr to B) – sending at least one message of each priority. ( 0 - 9, inclusive ). Send management commands to A to see how many outgoing inter-router links had message traffic go over them. The number should be 10. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1096) support AMQP prioritized messages
[ https://issues.apache.org/jira/browse/DISPATCH-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael goulish resolved DISPATCH-1096. --- Resolution: Implemented I will open a separate Jira for tests that this code needs. > support AMQP prioritized messages > - > > Key: DISPATCH-1096 > URL: https://issues.apache.org/jira/browse/DISPATCH-1096 > Project: Qpid Dispatch > Issue Type: New Feature >Reporter: michael goulish >Assignee: michael goulish >Priority: Major > Fix For: 1.4.0 > > > Detect priority info from message header in the router code. > Create separate inter-router links for the various priorities. > Per connection (i.e. not globally across the router) service high-priority > inter-router links before low priority 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] [Created] (QPID-8246) File leak in heartbeat algorithm
Lucas Guilherme Hübner created QPID-8246:
Summary: File leak in heartbeat algorithm
Key: QPID-8246
URL: https://issues.apache.org/jira/browse/QPID-8246
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: qpid-cpp-1.38.0
Environment: SO: Debian GNU/Linux 9 (stretch)
Reporter: Lucas Guilherme Hübner
Attachments: client.c, valgrind-output.log
The heartbeat option is causing file leak when the interface is down or the
address is unreachable.
I've programmed a little test client to reproduce the error, this client source
is on the attachments, to check the opened files of the process i've used the
following bash script:
{code:java}
while :; do lsof -u root | grep $(pgrep -f ./client) | wc -l; sleep 1;
done{code}
The client if compiled with the following syntax:
{code:java}
g++ client.c -o client -lqpidmessaging -lqpidtypes -lpthread{code}
Valgrind command was called with the following parameters:
{code:java}
valgrind --tool=memcheck --track-fds=yes --leak-check=full --read-var-info=yes
--show-reachable=yes --track-origins=yes ./client > valgrind-output.log 2>&1
{code}
The valgrind is initialized with the interface up and working, after some time,
the interface is disabled and the leak begin.
If the application runs for long time, this file leak turns into a crash on the
program, due to the linux max open files, even if the connection still comes
back the files continue opened.
Resumed valgrind output for this issue:
*==26937== FILE DESCRIPTORS: 17 open at exit.*
==26937== Open AF_INET socket 16: <-> unbound
==26937== at 0x4C19001: socket (socket.c:32)
==26937== by 0x4EEA04F:
qpid::sys::BSDSocket::createSocket(qpid::sys::SocketAddress const&) const (in
/usr/local/lib/libqpidcommon.so.2.0.0)
==26937== by 0x4EEA521: qpid::sys::BSDSocket::connect(qpid::sys::SocketAddress
const&) const (in /usr/local/lib/libqpidcommon.so.2.0.0)
==26937== by 0x4ECC233:
qpid::sys::posix::AsynchConnector::AsynchConnector(qpid::sys::Socket const&,
std::__cxx11::basic_string, std::allocator >
const&, std::__cxx11::basic_string,
std::allocator > const&, boost::function1, boost::function3, std::allocator >
const&>) (in /usr/local/lib/libqpidcommon.so.2.0.0)
==26937== by 0x4ECC8D7: qpid::sys::AsynchConnector::create(qpid::sys::Socket
const&, std::__cxx11::basic_string,
std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, boost::function1, boost::function3,
std::allocator > const&>) (in /usr/local/lib/libqpidcommon.so.2.0.0)
==26937== by 0x4D7FF74:
qpid::client::TCPConnector::connect(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string, std::allocator >
const&) (in /usr/local/lib/libqpidclient.so.2.0.0)
==26937== by 0x4D37C06: qpid::client::ConnectionImpl::open() (in
/usr/local/lib/libqpidclient.so.2.0.0)
==26937== by 0x4D272CF:
qpid::client::Connection::open(qpid::client::ConnectionSettings const&) (in
/usr/local/lib/libqpidclient.so.2.0.0)
==26937== by 0x4D27DF0: qpid::client::Connection::open(qpid::Url const&,
qpid::client::ConnectionSettings const&) (in
/usr/local/lib/libqpidclient.so.2.0.0)
==26937== by 0x48898F6: qpid::client::amqp0_10::ConnectionImpl::tryConnect()
(in /usr/local/lib/libqpidmessaging.so.2.0.0)
==26937== by 0x488B468:
qpid::client::amqp0_10::ConnectionImpl::connect(qpid::sys::AbsTime const&) (in
/usr/local/lib/libqpidmessaging.so.2.0.0)
==26937== by 0x488D137: qpid::client::amqp0_10::ConnectionImpl::open() (in
/usr/local/lib/libqpidmessaging.so.2.0.0)
==26937==
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1949) no message header if priority == default
[ https://issues.apache.org/jira/browse/PROTON-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael goulish closed PROTON-1949. --- Resolution: Not A Problem We have found a nice workaround for this–probably better, actually--and do not need proton to change anything. > no message header if priority == default > > > Key: PROTON-1949 > URL: https://issues.apache.org/jira/browse/PROTON-1949 > Project: Qpid Proton > Issue Type: Bug >Reporter: michael goulish >Priority: Major > > Proton does not send a message header if there would be nothing in it but the > priority field, and if the priority was set to the default value (4). > At the router level, we are allowing the user to set priorities on addresses. > Those priorities will be given to any message sent to that address if the > message otherwise had no priority set. > So - we need to be able to distinguish between messages that were assigned > the default priority, and messages in which the priority was left undefined. > We would like proton to send the priority field in the message header if the > user sets any priority. Then we will be able to interpret no header, or no > priority field in the header as "no priority was assigned". > -- 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-1949) no message header if priority == default
[ https://issues.apache.org/jira/browse/PROTON-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640115#comment-16640115 ] michael goulish commented on PROTON-1949: - Nolo contendere. We have decided that it is better to give precedence to the address's priority, which means that we do not need an ability in the message to express _no value_. I will close this as not-a-bug. > no message header if priority == default > > > Key: PROTON-1949 > URL: https://issues.apache.org/jira/browse/PROTON-1949 > Project: Qpid Proton > Issue Type: Bug >Reporter: michael goulish >Priority: Major > > Proton does not send a message header if there would be nothing in it but the > priority field, and if the priority was set to the default value (4). > At the router level, we are allowing the user to set priorities on addresses. > Those priorities will be given to any message sent to that address if the > message otherwise had no priority set. > So - we need to be able to distinguish between messages that were assigned > the default priority, and messages in which the priority was left undefined. > We would like proton to send the priority field in the message header if the > user sets any priority. Then we will be able to interpret no header, or no > priority field in the header as "no priority was assigned". > -- 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-1951) [go] Server connection fails to authenticate if Server() is not first
Alan Conway created PROTON-1951: --- Summary: [go] Server connection fails to authenticate if Server() is not first Key: PROTON-1951 URL: https://issues.apache.org/jira/browse/PROTON-1951 Project: Qpid Proton Issue Type: Bug Components: go-binding Affects Versions: proton-c-0.26.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.27.0 If a server connection is created where the Server() option comes after SASL options in the option list, then SASL is not configured correctly and the server hangs during authentication. Server connections created by Connection.Accept() suffer from this problem. -- 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-1950) [proton-c] build intermittently fails to produce good python tox header file
Chuck Rolke created PROTON-1950:
---
Summary: [proton-c] build intermittently fails to produce good
python tox header file
Key: PROTON-1950
URL: https://issues.apache.org/jira/browse/PROTON-1950
Project: Qpid Proton
Issue Type: Bug
Components: build
Affects Versions: proton-c-0.25.0
Reporter: Chuck Rolke
Building from source, not installed, and running tests:
{{ mkdir build
cdbuild
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/opt/local ..
make -j 8
make test
}}
fails python-tox-test. To see what's wrong:
{{ ctest -VV -R python-tox-test
}}
shows:
{{ 33:
/home/chug/tmp/proton-0.26-rc2/qpid-proton-0.26.0/build/python/dist/src/core/message.c:118:24:
error: ‘HEADER_PRIORITY_DEFAULT’ undeclared (first use in this function)
33:if (msg->priority != HEADER_PRIORITY_DEFAULT) {
}}
It looks like the header file that defines HEADER_PRIORITY_DEFAULT has an issue.
By running 'make' again python-tox-test passes. I suspect that there is some
kind of race with doing 'make -j 8' if running make again fixes things.
This error does not always happen. Sometimes I can do clean cmake/build and it
works just fine.
--
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] (DISPATCH-1110) Intermittent router hang while running QIT's AMQP large content test
[
https://issues.apache.org/jira/browse/DISPATCH-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639857#comment-16639857
]
Robbie Gemmell edited comment on DISPATCH-1110 at 10/5/18 1:56 PM:
---
I previously found an issue like this elsewhere which Alan raised upstream as
PROTON-1914. Could be related?
was (Author: gemmellr):
I previously found this https://issues.apache.org/jira/browse/PROTON-1914 issue
elsewhere which Alan raised upstream. Could be related?
> Intermittent router hang while running QIT's AMQP large content test
>
>
> Key: DISPATCH-1110
> URL: https://issues.apache.org/jira/browse/DISPATCH-1110
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Standard QIT environment.
> Once QIT is built and installed, the environment is set using the config.sh
> file. See QUICKSTART for details.
>Reporter: Kim van der Riet
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdrouterd.conf
>
>
> When running the Qpid Interop Test's AMQP large content test, a stand-alone
> router will intermittently hang and cause the test to time out.
> The failure appears to be limited to either the AMQP list or map types, and
> usually with the C++ client as the message sender. The C++, Python2 and
> Python3 as receiver clients have all seen this failure, but the Python2
> receiver client seems to reproduce more readily on my hardware.
> In all cases, the test fails when the router sends what I suppose is the
> final transfer of a large message (I have not added up/counted the bytes of
> the many preceding transfers) to the consumer. The consumer then sends a
> disposition, but the router does not respond again until the test times out.
> The consumer can be seen to send heartbeats to the router, but the router
> does not send any of its own.
> {noformat}
> ... (plenty of 65550-sized frames R->C)
> R->C 5976 3.454766::1 ::1 AMQP65550
> R->C 5977 3.454775::1 ::1 AMQP65550
> R->C 5978 3.454783::1 ::1 AMQP48171
> C->R 5982 3.529881::1 ::1 AMQP115 disposition
> C->R 5984 7.530704::1 ::1 AMQP94 (empty)
> C->R 5986 11.532306 ::1 ::1 AMQP94 (empty)
> ...{noformat}
> There are no errors to be seen in the router logs other than when the
> consuming client is killed owing to the test timeout.
> {noformat}
> ...
> 2018-08-29 12:50:23.191754 -0400 SERVER (info) [14]: Accepted connection to
> ::1:amqp from ::1:37262
> 2018-08-29 12:51:19.562695 -0400 SERVER (info) [14]: Connection from
> ::1:37262 (to ::1:amqp) failed: amqp:connection:framing-error connection
> aborted
> {noformat}
> The reproducer is not very tight on this, and the error occurs about 50% of
> the time on my hardware.
--
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-1110) Intermittent router hang while running QIT's AMQP large content test
[
https://issues.apache.org/jira/browse/DISPATCH-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639857#comment-16639857
]
Robbie Gemmell commented on DISPATCH-1110:
--
I previously found this https://issues.apache.org/jira/browse/PROTON-1914 issue
elsewhere which Alan raised upstream. Could be related?
> Intermittent router hang while running QIT's AMQP large content test
>
>
> Key: DISPATCH-1110
> URL: https://issues.apache.org/jira/browse/DISPATCH-1110
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Standard QIT environment.
> Once QIT is built and installed, the environment is set using the config.sh
> file. See QUICKSTART for details.
>Reporter: Kim van der Riet
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdrouterd.conf
>
>
> When running the Qpid Interop Test's AMQP large content test, a stand-alone
> router will intermittently hang and cause the test to time out.
> The failure appears to be limited to either the AMQP list or map types, and
> usually with the C++ client as the message sender. The C++, Python2 and
> Python3 as receiver clients have all seen this failure, but the Python2
> receiver client seems to reproduce more readily on my hardware.
> In all cases, the test fails when the router sends what I suppose is the
> final transfer of a large message (I have not added up/counted the bytes of
> the many preceding transfers) to the consumer. The consumer then sends a
> disposition, but the router does not respond again until the test times out.
> The consumer can be seen to send heartbeats to the router, but the router
> does not send any of its own.
> {noformat}
> ... (plenty of 65550-sized frames R->C)
> R->C 5976 3.454766::1 ::1 AMQP65550
> R->C 5977 3.454775::1 ::1 AMQP65550
> R->C 5978 3.454783::1 ::1 AMQP48171
> C->R 5982 3.529881::1 ::1 AMQP115 disposition
> C->R 5984 7.530704::1 ::1 AMQP94 (empty)
> C->R 5986 11.532306 ::1 ::1 AMQP94 (empty)
> ...{noformat}
> There are no errors to be seen in the router logs other than when the
> consuming client is killed owing to the test timeout.
> {noformat}
> ...
> 2018-08-29 12:50:23.191754 -0400 SERVER (info) [14]: Accepted connection to
> ::1:amqp from ::1:37262
> 2018-08-29 12:51:19.562695 -0400 SERVER (info) [14]: Connection from
> ::1:37262 (to ::1:amqp) failed: amqp:connection:framing-error connection
> aborted
> {noformat}
> The reproducer is not very tight on this, and the error occurs about 50% of
> the time on my hardware.
--
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-1115) Configure Travis to run Dispatch tests agianst the latest Proton release and Proton master branch
[ https://issues.apache.org/jira/browse/DISPATCH-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-1115: Fix Version/s: (was: 1.4.0) 1.5.0 > Configure Travis to run Dispatch tests agianst the latest Proton release and > Proton master branch > - > > Key: DISPATCH-1115 > URL: https://issues.apache.org/jira/browse/DISPATCH-1115 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tools >Affects Versions: 1.3.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.5.0 > > > Currently, Dispatch tests running on Travis run only against Proton Master. > Make these tests also run against the latest released version of Proton. -- 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-1946) [cpp] connection config file parser mis-handling TLS defaults
[
https://issues.apache.org/jira/browse/PROTON-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639809#comment-16639809
]
Alan Conway commented on PROTON-1946:
-
Fixed by aa85a1fe PROTON-1974: [cpp] modify to work with older jsoncpp (1.7.4)
> [cpp] connection config file parser mis-handling TLS defaults
> -
>
> Key: PROTON-1946
> URL: https://issues.apache.org/jira/browse/PROTON-1946
> Project: Qpid Proton
> Issue Type: Sub-task
> Components: cpp-binding
>Affects Versions: proton-c-0.25.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
>
> The C++ connection configuration parser mis-handles default values in several
> ways:
> * tls is not enabled unless there is a tls: {} section - it should be
> enabled (with default config) if scheme: amqps is present even if there is no
> tls section
> * in several cases an explicit 'field: null' is treated differently (as an
> error) from field being absent (use default value). null and absent should be
> equivalent.
> * Host defaults to "", it should be "localhost"
> * Some exceptions from jsoncpp are leaked, they should be wrapped in
> proton::error
> * Need additional tests to cover all of the above
--
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] (DISPATCH-1138) auto delete link routes do not auto delete on normal or edge connections
[ https://issues.apache.org/jira/browse/DISPATCH-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed DISPATCH-1138. Resolution: Won't Fix Removed fix-versions since it is not actually being done. > auto delete link routes do not auto delete on normal or edge connections > > > Key: DISPATCH-1138 > URL: https://issues.apache.org/jira/browse/DISPATCH-1138 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.3.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > Link routes with "deleteOnClose" set to True will only auto-delete if the > connection's role is "route-container". > They also need to auto delete for connections whose roles are normal and > edge-uplink -- 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] [Reopened] (DISPATCH-1138) auto delete link routes do not auto delete on normal or edge connections
[ https://issues.apache.org/jira/browse/DISPATCH-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened DISPATCH-1138: -- > auto delete link routes do not auto delete on normal or edge connections > > > Key: DISPATCH-1138 > URL: https://issues.apache.org/jira/browse/DISPATCH-1138 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.3.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > Link routes with "deleteOnClose" set to True will only auto-delete if the > connection's role is "route-container". > They also need to auto delete for connections whose roles are normal and > edge-uplink -- 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-1138) auto delete link routes do not auto delete on normal or edge connections
[ https://issues.apache.org/jira/browse/DISPATCH-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated DISPATCH-1138: - Fix Version/s: (was: 1.4.0) (was: 2.0.0) > auto delete link routes do not auto delete on normal or edge connections > > > Key: DISPATCH-1138 > URL: https://issues.apache.org/jira/browse/DISPATCH-1138 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.3.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > Link routes with "deleteOnClose" set to True will only auto-delete if the > connection's role is "route-container". > They also need to auto delete for connections whose roles are normal and > edge-uplink -- 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] (DISPATCH-1100) Allow link routes to auto delete when the corresponding container is removed
[ https://issues.apache.org/jira/browse/DISPATCH-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed DISPATCH-1100. Resolution: Won't Do Removed fix-version since it is no longer being done. > Allow link routes to auto delete when the corresponding container is removed > > > Key: DISPATCH-1100 > URL: https://issues.apache.org/jira/browse/DISPATCH-1100 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Management Agent, Router Node >Affects Versions: 1.2.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > > This would allow a server to create its own link route which is removed when > the server is no longer attached to the router. -- 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] [Reopened] (DISPATCH-1100) Allow link routes to auto delete when the corresponding container is removed
[ https://issues.apache.org/jira/browse/DISPATCH-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened DISPATCH-1100: -- > Allow link routes to auto delete when the corresponding container is removed > > > Key: DISPATCH-1100 > URL: https://issues.apache.org/jira/browse/DISPATCH-1100 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Management Agent, Router Node >Affects Versions: 1.2.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > > This would allow a server to create its own link route which is removed when > the server is no longer attached to the router. -- 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-1100) Allow link routes to auto delete when the corresponding container is removed
[ https://issues.apache.org/jira/browse/DISPATCH-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated DISPATCH-1100: - Fix Version/s: (was: 1.4.0) > Allow link routes to auto delete when the corresponding container is removed > > > Key: DISPATCH-1100 > URL: https://issues.apache.org/jira/browse/DISPATCH-1100 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Management Agent, Router Node >Affects Versions: 1.2.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > > This would allow a server to create its own link route which is removed when > the server is no longer attached to the router. -- 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 #380: DISPATCH-1096 - use default priority if und...
Github user mgoulish closed the pull request at: https://github.com/apache/qpid-dispatch/pull/380 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1096) support AMQP prioritized messages
[ https://issues.apache.org/jira/browse/DISPATCH-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639380#comment-16639380 ] ASF GitHub Bot commented on DISPATCH-1096: -- Github user mgoulish closed the pull request at: https://github.com/apache/qpid-dispatch/pull/380 > support AMQP prioritized messages > - > > Key: DISPATCH-1096 > URL: https://issues.apache.org/jira/browse/DISPATCH-1096 > Project: Qpid Dispatch > Issue Type: New Feature >Reporter: michael goulish >Assignee: michael goulish >Priority: Major > Fix For: 1.4.0 > > > Detect priority info from message header in the router code. > Create separate inter-router links for the various priorities. > Per connection (i.e. not globally across the router) service high-priority > inter-router links before low priority 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] [Commented] (DISPATCH-1096) support AMQP prioritized messages
[ https://issues.apache.org/jira/browse/DISPATCH-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639379#comment-16639379 ] ASF GitHub Bot commented on DISPATCH-1096: -- Github user mgoulish commented on the issue: https://github.com/apache/qpid-dispatch/pull/380 This is superseded by Ted's commit e3e201652ca167e9a6cd3d12ff3106165f3bb89a "DISPATCH-1132 - Cleaned up message header parsing" > support AMQP prioritized messages > - > > Key: DISPATCH-1096 > URL: https://issues.apache.org/jira/browse/DISPATCH-1096 > Project: Qpid Dispatch > Issue Type: New Feature >Reporter: michael goulish >Assignee: michael goulish >Priority: Major > Fix For: 1.4.0 > > > Detect priority info from message header in the router code. > Create separate inter-router links for the various priorities. > Per connection (i.e. not globally across the router) service high-priority > inter-router links before low priority 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
[GitHub] qpid-dispatch issue #380: DISPATCH-1096 - use default priority if undefined
Github user mgoulish commented on the issue: https://github.com/apache/qpid-dispatch/pull/380 This is superseded by Ted's commit e3e201652ca167e9a6cd3d12ff3106165f3bb89a "DISPATCH-1132 - Cleaned up message header parsing" --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #278: No JIRA yet -- example perf test in unit test envi...
Github user mgoulish commented on the issue: https://github.com/apache/qpid-dispatch/pull/278 I don't think the Python testing framework is the right venue for large-scale performance testing. Better technology coming soon. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #278: No JIRA yet -- example perf test in unit te...
Github user mgoulish closed the pull request at: https://github.com/apache/qpid-dispatch/pull/278 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
