[jira] [Commented] (QPID-8286) [Broker-J] Add operation into priority queue to change message priority
[ https://issues.apache.org/jira/browse/QPID-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803327#comment-16803327 ] ASF GitHub Bot commented on QPID-8286: -- asfgit commented on pull request #22: QPID-8286: [Broker-J] Add operations into priority queue to change message priority URL: https://github.com/apache/qpid-broker-j/pull/22 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [Broker-J] Add operation into priority queue to change message priority > --- > > Key: QPID-8286 > URL: https://issues.apache.org/jira/browse/QPID-8286 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2 > > > The functionality to change message priority is required for some use case > scenarios involving priority queues. At the moment, in order to change the > priority, the messages need to be consumed (for example, using selector > 'JMSMessageID=ID:XYZ') and re-published with a different priority. I > management operation can be introduced on the priority queue which can simply > dequeue the message and re-enqueue it with a provided priority. -- 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-8286) [Broker-J] Add operation into priority queue to change message priority
[ https://issues.apache.org/jira/browse/QPID-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803326#comment-16803326 ] ASF subversion and git services commented on QPID-8286: --- Commit 159a75361cc584b28d92dec2d0abce6a311480f5 in qpid-broker-j's branch refs/heads/master from Alex Rudyy [ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=159a753 ] QPID-8286: [Broker-J] Add operation into priority queue to change message priority This closes #22 > [Broker-J] Add operation into priority queue to change message priority > --- > > Key: QPID-8286 > URL: https://issues.apache.org/jira/browse/QPID-8286 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2 > > > The functionality to change message priority is required for some use case > scenarios involving priority queues. At the moment, in order to change the > priority, the messages need to be consumed (for example, using selector > 'JMSMessageID=ID:XYZ') and re-published with a different priority. I > management operation can be introduced on the priority queue which can simply > dequeue the message and re-enqueue it with a provided priority. -- 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] asfgit closed pull request #22: QPID-8286: [Broker-J] Add operations into priority queue to change message priority
asfgit closed pull request #22: QPID-8286: [Broker-J] Add operations into priority queue to change message priority URL: https://github.com/apache/qpid-broker-j/pull/22 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1862) idle timeout not working on linux
[
https://issues.apache.org/jira/browse/PROTON-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803208#comment-16803208
]
Andrew Stitcher commented on PROTON-1862:
-
>From looking at the code [~alihadi]'s diagnosis must be wrong.
The {{on_connection_open}}/{{on_session_open}} callbacks are *only* called
after the server has received the open or attach frames: The underlying
Proton-C library generates {{PN_CONNECTION_REMOTE_OPEN}} or
{{PN_SESSION_REMOTE_OPEN}} events in response to receiving the incoming frames
and the C++ library uses these events to generate the callbacks.
What I think is likely happening is that although the connection is open from
client to server (which only establishes the timeout the server uses to timeout
the client) if you don't explicitly open the connection from server to client
in response there is no timeout negotiated in the other direction at all (as
the open frame has not been sent and this contains the timeout).
By sleeping in the {{on_connection_open}} callback you are preventing the open
frame from being sent and hence no timeout gets established at all. Note that
if you override {{on_connection_open}}/{{on_session_open}} then you are
responsible for opening the connection/session in the opposite direction
yourself.
This behaviour may have changed in 0.18. as before the reverse open may have
happened always, but doing that is not the correct thing to do as it does not
allow for failing a connection on a server at the point of opening.
In any event sleeping before the timeout is established by sending the outgoing
open frame cannot work.
Also it may be worth bearing in mind that the event/callback sequence is
different on servers from clients:
* On a client will get the {{on_connection_open}} callback only after the
connection is negotiated in both directions. This because the client itself
initiated the connection and the callback is caused by the *remote* open frame
which in this case happens in response to the open frame already sent by the
client.
* On a server the {{on_connection_open}} callback always happens before the
connection is open from the server to the client as the *remote* open happens
before the server has sent it's own open (which occurs only in response to the
client's open).
I hope this helps you understand what's going on.
> idle timeout not working on linux
> --
>
> Key: PROTON-1862
> URL: https://issues.apache.org/jira/browse/PROTON-1862
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Critical
> Labels: reproducer
> Attachments: proton_1862_tests.txt, test_case.cpp
>
>
> We faced an issue with the idle timeout on linux. On windows, it seems to
> work.
> In our proton feature test suite, we test the idle timeout feature by doing a
> sleep in the method on_session_open.
> This should trigger a connection timeout. It works on windows, and it used to
> work with proton v0.16.0 on windows and linux.
> Removing the sleep from the on_session_open and putting it in
> on_connection_open, yields the same result.
> See attached file to reproduce.
> Machines:
> * Windows machine
> ** OS: Windows 7
> ** Compiler: MSVC 2013 Version 12 Update 5
> * Linux machine
> ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago)
> ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
--
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-1862) idle timeout not working on linux
[ https://issues.apache.org/jira/browse/PROTON-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1862. - Resolution: Not A Bug > idle timeout not working on linux > -- > > Key: PROTON-1862 > URL: https://issues.apache.org/jira/browse/PROTON-1862 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > Attachments: proton_1862_tests.txt, test_case.cpp > > > We faced an issue with the idle timeout on linux. On windows, it seems to > work. > In our proton feature test suite, we test the idle timeout feature by doing a > sleep in the method on_session_open. > This should trigger a connection timeout. It works on windows, and it used to > work with proton v0.16.0 on windows and linux. > Removing the sleep from the on_session_open and putting it in > on_connection_open, yields the same result. > See attached file to reproduce. > Machines: > * Windows machine > ** OS: Windows 7 > ** Compiler: MSVC 2013 Version 12 Update 5 > * Linux machine > ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) > ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1862) idle timeout not working on linux
[ https://issues.apache.org/jira/browse/PROTON-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803083#comment-16803083 ] Rabih Mourad edited comment on PROTON-1862 at 3/27/19 5:14 PM: --- We block the receiver container with a sleep to simulate a hanging on the server side after the connection is established. The client (sender) does not sleep therefore after the idle timeout is expired it should fail and on linux it is not. But as Ali said in his last comments. The issue is that the server (receiver) is calling the on_connection_open and the on_session_open callbacks before the real amqp connection is established. Therefore there is no idle timeout yet. Therefore the fix might be to call those call backs after the real connection is established on the wire. The regression was introduced in the version 0.18.1 was (Author: rabih.promail): We block the receiver container with a sleep to simulate a hanging on the server side after the connection is established. The client (sender) does not sleep therefore after the idle timeout is expired it should fail and on linux it is not. But as Ali said in his last comments. The issue is that the server (receiver) is calling the on_connection_open and the on_session_open callbacks before the real amqp connection is established. Therefore there is no idle timeout yet. Therefore the fix might be to call those call backs after the real connection is established on the wire. > idle timeout not working on linux > -- > > Key: PROTON-1862 > URL: https://issues.apache.org/jira/browse/PROTON-1862 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > Attachments: proton_1862_tests.txt, test_case.cpp > > > We faced an issue with the idle timeout on linux. On windows, it seems to > work. > In our proton feature test suite, we test the idle timeout feature by doing a > sleep in the method on_session_open. > This should trigger a connection timeout. It works on windows, and it used to > work with proton v0.16.0 on windows and linux. > Removing the sleep from the on_session_open and putting it in > on_connection_open, yields the same result. > See attached file to reproduce. > Machines: > * Windows machine > ** OS: Windows 7 > ** Compiler: MSVC 2013 Version 12 Update 5 > * Linux machine > ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) > ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) -- 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-1862) idle timeout not working on linux
[ https://issues.apache.org/jira/browse/PROTON-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803083#comment-16803083 ] Rabih Mourad commented on PROTON-1862: -- We block the receiver container with a sleep to simulate a hanging on the server side after the connection is established. The client (sender) does not sleep therefore after the idle timeout is expired it should fail and on linux it is not. But as Ali said in his last comments. The issue is that the server (receiver) is calling the on_connection_open and the on_session_open callbacks before the real amqp connection is established. Therefore there is no idle timeout yet. Therefore the fix might be to call those call backs after the real connection is established on the wire. > idle timeout not working on linux > -- > > Key: PROTON-1862 > URL: https://issues.apache.org/jira/browse/PROTON-1862 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > Attachments: proton_1862_tests.txt, test_case.cpp > > > We faced an issue with the idle timeout on linux. On windows, it seems to > work. > In our proton feature test suite, we test the idle timeout feature by doing a > sleep in the method on_session_open. > This should trigger a connection timeout. It works on windows, and it used to > work with proton v0.16.0 on windows and linux. > Removing the sleep from the on_session_open and putting it in > on_connection_open, yields the same result. > See attached file to reproduce. > Machines: > * Windows machine > ** OS: Windows 7 > ** Compiler: MSVC 2013 Version 12 Update 5 > * Linux machine > ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) > ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) -- 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-1308) Console access to the force-close a connection feature
Ernest Allen created DISPATCH-1308: -- Summary: Console access to the force-close a connection feature Key: DISPATCH-1308 URL: https://issues.apache.org/jira/browse/DISPATCH-1308 Project: Qpid Dispatch Issue Type: Improvement Components: Console Affects Versions: 1.5.0 Reporter: Ernest Allen Assignee: Ernest Allen Provide the ability to force-close a connection from the console. Sets the adminStatus attribute of a connection to 'deleted'. The connection should then automatically be deleted by 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] [Commented] (PROTON-2022) Python3 reactor listener client fails with 'Bad file descriptor' exception
[ https://issues.apache.org/jira/browse/PROTON-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802843#comment-16802843 ] Andrew Stitcher commented on PROTON-2022: - This issue is caused by the authz test closing the file handle in a signal handler. *This is not a legitimate thing to do* This is also not legitimate in python 2 either. But in this case the Interrupt signal gets through to the code in _io.py which specifically ignores SIGINTR and the event loop does not try to run poll again with an invalid file handle. It fails in python 3 because poll automatically retries the underlying system call when it receives SIGINTR automatically. > Python3 reactor listener client fails with 'Bad file descriptor' exception > -- > > Key: PROTON-2022 > URL: https://issues.apache.org/jira/browse/PROTON-2022 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.0 > Environment: Fedora 29 or 28. Python 3. > qpid-dispatch master @f359aea 1.6.0-rc2 >Reporter: Chuck Rolke >Priority: Major > Attachments: authz.txt > > > Qpid-dispatch self tests run a helper program > qpid-dispatch/tests/authservice.py.in > With Python 2 this test program works normally. > With Python 3 the test fails with an 'OSError Errno 9, Bad file descriptor' > exception. > Control is passed from the application to a MessagingHandler with > Container(handler).run() > The stack trace is posted as an attached file. > To reproduce: from the build directory > ctest -VV -R authz > -- 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-1307) [tools] Scraper process is not tested by self test
Chuck Rolke created DISPATCH-1307: - Summary: [tools] Scraper process is not tested by self test Key: DISPATCH-1307 URL: https://issues.apache.org/jira/browse/DISPATCH-1307 Project: Qpid Dispatch Issue Type: Test Components: Tests, Tools Affects Versions: 1.5.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Scraper could be run in both normal and split modes to verify that the scraper process finishes normally. This would possibly help alert users to changes in log file format or in code syntax errors that the developer didn't catch. Testing that scraper finds and displays what it is supposed to find and display is a harder problem and the subject of another Jira issue. -- 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-472) Default value of authenticatePeer parameter in listener configuration
[
https://issues.apache.org/jira/browse/DISPATCH-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-472:
--
Fix Version/s: (was: 1.6.0)
1.7.0
> Default value of authenticatePeer parameter in listener configuration
> -
>
> Key: DISPATCH-472
> URL: https://issues.apache.org/jira/browse/DISPATCH-472
> Project: Qpid Dispatch
> Issue Type: Improvement
>Reporter: Jakub Scholz
>Priority: Major
> Fix For: 1.7.0
>
>
> The authenticatePeer parameter in listener configuration has currently
> default value "no". I believe this can lead to misunderstandings causing
> security issues. Consider listener configured as this:
> {code}
> listener {
> role: normal
> host: 0.0.0.0
> port: amqp
> saslMechanisms: PLAIN DIGEST-MD5 CRAM-MD5
> }
> {code}
> It has configured SASL authentication using username and password and on a
> first look one might believe that such listener is configured properly.
> However, because of missing "authenticatePeer: yes" parameter, it is still
> possible to connect anonymously without the SASL layer.
> I believe it would be much better to have either set authenticatePeer
> parameter to yes by default all the time or at least when SASL is configured.
> Please have a look at the related discussion from the mailing list:
> http://qpid.2158936.n2.nabble.com/Dispatch-Default-value-of-authenticatePeer-td7648676.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] [Updated] (DISPATCH-1230) System test failing with OpenSSL >= 1.1 - system_tests_ssl
[ https://issues.apache.org/jira/browse/DISPATCH-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1230: --- Fix Version/s: (was: 1.6.0) 1.7.0 > System test failing with OpenSSL >= 1.1 - system_tests_ssl > -- > > Key: DISPATCH-1230 > URL: https://issues.apache.org/jira/browse/DISPATCH-1230 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Reporter: Fernando Giorgetti >Assignee: Fernando Giorgetti >Priority: Major > Fix For: 1.7.0 > > > A system test is failing when OpenSSL >= 1.1 is installed on running system: > system_tests_ssl. -- 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-1265) Delivery_abort test causes inter-router session error
[ https://issues.apache.org/jira/browse/DISPATCH-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1265: --- Fix Version/s: (was: 1.6.0) 1.7.0 > Delivery_abort test causes inter-router session error > - > > Key: DISPATCH-1265 > URL: https://issues.apache.org/jira/browse/DISPATCH-1265 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.5.0 > Environment: Fedora 29, Python 3. > branch DISPATCH-1264#a5aab9 > ctest -VV -R system_tests_delivery_abort >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Critical > Fix For: 1.7.0 > > Attachments: DISPATCH-1265_ctest-log.txt, > DISPATCH-1265_scraped-logs-timeout.html > > > Inter-router connection closes with: > error :"amqp:session:invalid-field" "sequencing error, expected delivery-id > 24, got 23" -- 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-1167) Return a 404 page from an http request for the console if httpRoot is not set
[ https://issues.apache.org/jira/browse/DISPATCH-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1167: --- Fix Version/s: (was: 1.6.0) 1.7.0 > Return a 404 page from an http request for the console if httpRoot is not set > - > > Key: DISPATCH-1167 > URL: https://issues.apache.org/jira/browse/DISPATCH-1167 > Project: Qpid Dispatch > Issue Type: Improvement >Affects Versions: 1.4.1 >Reporter: Ernest Allen >Priority: Major > Fix For: 1.7.0 > > > With the change in DISPATCH-1155, a request for the console make to a > listener that does not have the proper httpRoot setup will result in a 404 > status being send back to the browser. This results in a blank page with the > number 404 displayed. > An static html page explaining the reason for the 404 status should be > returned. > This page should: > * have the proper branding > * explain that the console can't be found > * explain what to change in order for the console to work > * provide a link to any online documentation about setting up the console > listener > -- 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-1079) Setting socketAddressFamily/protocolFamily does not take effect
[
https://issues.apache.org/jira/browse/DISPATCH-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1079:
---
Fix Version/s: (was: 1.6.0)
1.7.0
> Setting socketAddressFamily/protocolFamily does not take effect
> ---
>
> Key: DISPATCH-1079
> URL: https://issues.apache.org/jira/browse/DISPATCH-1079
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.2.0
>Reporter: Ganesh Murthy
>Priority: Major
> Fix For: 1.7.0
>
>
> socketAddressFamily/protocolFamily can be specified on a listener like this
> {noformat}
> listener {
> idleTimeoutSeconds: 120
> saslMechanisms: ANONYMOUS
> host: ::1
> role: normal
> socketAddressFamily: IPv6
> authenticatePeer: no
> port: 29190
> }{noformat}
> In the above examole, socketAddressFamily to IPv6 makes sure that the
> connection be made on the IPv6 interface.
>
> The commit 6f56e289bec0db4a1de257883dc456a502c42fe7 removed all code to
> relating protocol family so the code does not enforce this anymore.
>
> Add back code to enforce 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] (DISPATCH-1214) Valgrind finds invalid reads and many leaks during the unit tests
[ https://issues.apache.org/jira/browse/DISPATCH-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1214: --- Fix Version/s: (was: 1.6.0) 1.7.0 > Valgrind finds invalid reads and many leaks during the unit tests > - > > Key: DISPATCH-1214 > URL: https://issues.apache.org/jira/browse/DISPATCH-1214 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.4.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.7.0 > > Attachments: grinder-12128.txt, grinder-report.txt > > > See the attached grinder report -- 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-1215) several memory leaks in edge-router soak test
[
https://issues.apache.org/jira/browse/DISPATCH-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1215:
---
Fix Version/s: (was: 1.6.0)
1.7.0
> several memory leaks in edge-router soak test
> -
>
> Key: DISPATCH-1215
> URL: https://issues.apache.org/jira/browse/DISPATCH-1215
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: michael goulish
>Priority: Major
> Fix For: 1.7.0
>
>
> Using recent master code trees (dispatch and proton)...
> The test sets up a simple 3-linear router network, A-B-C, and attaches 100
> edge routers to A. It then kills one edge router, replaces it, and repeats
> that kill-and-replace operation 50 times. (At which point I manually killed
> router A.)
> Router A was running under valgrind, and produced the following output:
>
> {color:#ff} {color}
> {color:#ff}[mick@colossus ~]$ /usr/bin/valgrind --leak-check=full
> --show-leak-kinds=definite --trace-children=yes
> --suppressions=/home/mick/latest/qpid-dispatch/tests/valgrind.supp
> /home/mick/latest/install/dispatch/sbin/qdrouterd --config
> /home/mick/mercury/results/test_03/2018_12_06/config/A.conf -I
> /home/mick/latest/install/dispatch/lib/qpid-dispatch/python
> ==9409== Memcheck, a memory error detector
> ==9409== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==9409== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==9409== Command: /home/mick/latest/install/dispatch/sbin/qdrouterd --config
> /home/mick/mercury/results/test_03/2018_12_06/config/A.conf -I
> /home/mick/latest/install/dispatch/lib/qpid-dispatch/python
> ==9409==
> ^C==9409==
> ==9409== Process terminating with default action of signal 2 (SIGINT)
> ==9409== at 0x61C0A37: kill (in
> /usr/lib64/[libc-2.26.so|http://libc-2.26.so/])
> ==9409== by 0x401636: main (main.c:367)
> ==9409==
> ==9409== HEAP SUMMARY:
> ==9409== in use at exit: 6,933,690 bytes in 41,903 blocks
> ==9409== total heap usage: 669,024 allocs, 627,121 frees, 92,449,020 bytes
> allocated
> ==9409==
> ==9409== *8,640 (480 direct, 8,160 indirect) bytes in 20 blocks are
> definitely lost in loss record 4,229 of 4,323*
> ==9409== at 0x4C2CB6B: malloc (vg_replace_malloc.c:299)
> ==9409== by 0x4E7D336: qdr_error_from_pn (error.c:37)
> ==9409== by 0x4E905D7: AMQP_link_detach_handler (router_node.c:822)
> ==9409== by 0x4E60A6C: close_links (container.c:298)
> ==9409== by 0x4E6109F: close_handler (container.c:311)
> ==9409== by 0x4E6109F: qd_container_handle_event (container.c:639)
> ==9409== by 0x4E93971: handle (server.c:985)
> ==9409== by 0x4E944C8: thread_run (server.c:1010)
> ==9409== by 0x4E947CF: qd_server_run (server.c:1284)
> ==9409== by 0x40186E: main_process (main.c:112)
> ==9409== by 0x401636: main (main.c:367)
> ==9409==
> ==9409== *14,256 (792 direct, 13,464 indirect) bytes in 33 blocks are
> definitely lost in loss record 4,261 of 4,323*
> ==9409== at 0x4C2CB6B: malloc (vg_replace_malloc.c:299)
> ==9409== by 0x4E7D336: qdr_error_from_pn (error.c:37)
> ==9409== by 0x4E905D7: AMQP_link_detach_handler (router_node.c:822)
> ==9409== by 0x4E60A6C: close_links (container.c:298)
> ==9409== by 0x4E6109F: close_handler (container.c:311)
> ==9409== by 0x4E6109F: qd_container_handle_event (container.c:639)
> ==9409== by 0x4E93971: handle (server.c:985)
> ==9409== by 0x4E944C8: thread_run (server.c:1010)
> {color}
> {color:#ff}==9409== by 0x550150A: start_thread (in
> /usr/lib64/[libpthread-2.26.so|http://libpthread-2.26.so/]){color}
> {color:#ff}==9409== by 0x628138E: clone (in
> /usr/lib64/[libc-2.26.so|http://libc-2.26.so/])
> ==9409==
> ==9409== *575,713 (24 direct, 575,689 indirect) bytes in 1 blocks are
> definitely lost in loss record 4,321 of 4,323*
> ==9409== at 0x4C2CB6B: malloc (vg_replace_malloc.c:299)
> ==9409== by 0x4E83FCA: qdr_add_link_ref (router_core.c:518)
> ==9409== by 0x4E7A3BF: qdr_link_inbound_first_attach_CT
> (connections.c:1517)
> ==9409== by 0x4E8484B: router_core_thread (router_core_thread.c:116)
> ==9409== by 0x550150A: start_thread (in
> /usr/lib64/[libpthread-2.26.so|http://libpthread-2.26.so/])
> ==9409== by 0x628138E: clone (in
> /usr/lib64/[libc-2.26.so|http://libc-2.26.so/])
> ==9409==
> ==9409== LEAK SUMMARY:
> ==9409== definitely lost: 1,296 bytes in 54 blocks
> ==9409== indirectly lost: 597,313 bytes in 3,096 blocks
> ==9409== possibly lost: 1,473,248 bytes in 6,538 blocks
> ==9409== still reachable: 4,861,833 bytes in 32,215 blocks
> ==9409== suppressed: 0 bytes in 0 blocks
> ==9409== Reachable blocks (those to which a pointer was found) are not shown.
> ==9409== To see them, rerun with: --leak-check=full --show-leak-kinds=all
[jira] [Commented] (PROTON-1998) add headers and SASL frames to protocol trace
[
https://issues.apache.org/jira/browse/PROTON-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802689#comment-16802689
]
ASF subversion and git services commented on PROTON-1998:
-
Commit ee02857944b9fd203d4cb72f2da6821192ed27f4 in qpid-proton-j's branch
refs/heads/master from Robert Gemmell
[ https://gitbox.apache.org/repos/asf?p=qpid-proton-j.git;h=ee02857 ]
PROTON-1998: use a small test payload to minimise size of log output
> add headers and SASL frames to protocol trace
> -
>
> Key: PROTON-1998
> URL: https://issues.apache.org/jira/browse/PROTON-1998
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Reporter: Keith Wall
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: proton-j-0.32.0
>
>
> Unlike Proton, Proton-J does not provide SASL frame trace if environment
> variable PN_TRACE_FRM is set. It would be useful if Proton-J had this
> ability too to help diagnose SASL negotiation problem.
> Proton's SASL frame trace looks like this:
> {code:java}
> [0x7fc112c03a00]: -> SASL
> [0x7fc112c03a00]: <- SASL
> [0x7fc112c03a00]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x7fc112c03a00]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"guest@Oslo.local"]
> [0x7fc112c03a00]:0 <- @sasl-outcome(68) [code=0]
> [0x7fc112c03a00]: -> AMQP
> [0x7fc112c03a00]:0 -> @open(16)
> [container-id="be777c26-af6e-4935-a6be-316cc8bbdb35", hostname="127.0.0.1",
> channel-max=32767]{code}
> The "SASL" and "AMQP" notices to mark send/receive of the associated headers
> are similarly omitted by proton-j and would be useful to add.
--
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
