Bug 482944
| Summary: | Management messages can get staged - which breaks management | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Carl Trieloff <cctrieloff> |
| Component: | qpid-cpp | Assignee: | Ted Ross <tross> |
| Status: | CLOSED ERRATA | QA Contact: | Frantisek Reznicek <freznice> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.1 | CC: | esammons, gsim |
| Target Milestone: | 1.3 | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
In order to prevent management messages from being accidentally staged, the "--staging-threshold" command line option is no longer supported by the qpidd daemon.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-10-14 16:15:13 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Carl Trieloff
2009-01-28 22:06:01 UTC
I think removing the staging-threshold option is the best short term option. It no longer offers the full functionality it was introduced for anyway as a message is always fully loaded into memory before delivery to a client. Is loaded fully into memory? I am not sure on this point as I worked on this part of teh code in cluster and went to great extent not to load it all into memory. The 'higher layers' do indeed still load and send a frames worth of data at a time. However the threading change added some time ago had the side effect (unnoticed at the time) of having these queued up in the io layer before they are written out to the wire (which is only done once the thread doing the sequential load-and-send completes). Thus all the frames are held in memory before the message can be written and the intended end-to-end handling of large messages is no longer implemented. Probably a nicer way to handle large messages is to use the message fragmentation feature of 0-10 which was not available when this code was first written. The 1.0 draft is slightly different again. fixed svn 793091. with unit test. reproduce manually ./qpidd --auth no --staging-threshold 10 --load-module msgstore.so run qpid-tool if you can schema, it works. if you get no info on schema, it's bust. The issue on thread buffer bringing more into mem has been moved to https://bugzilla.redhat.com/show_bug.cgi?id=510773 The issue is resolved by removal of qpidd --staging-threshold option and schema in qpid-tool works as expected. Tested on RHEL 4.8 / 5.5 i386 / x86_64 on packages: python-qmf-0.7.946106-13.el5 python-qpid-0.7.946106-14.el5 python-saslwrapper-0.1.934605-2.el5 qmf-0.7.946106-16.el5 qmf-devel-0.7.946106-16.el5 qpid-cpp-client-0.7.946106-16.el5 qpid-cpp-client-devel-0.7.946106-16.el5 qpid-cpp-client-devel-docs-0.7.946106-16.el5 qpid-cpp-client-rdma-0.7.946106-16.el5 qpid-cpp-client-ssl-0.7.946106-16.el5 qpid-cpp-mrg-debuginfo-0.7.946106-16.el5 qpid-cpp-server-0.7.946106-16.el5 qpid-cpp-server-cluster-0.7.946106-16.el5 qpid-cpp-server-devel-0.7.946106-16.el5 qpid-cpp-server-rdma-0.7.946106-16.el5 qpid-cpp-server-ssl-0.7.946106-16.el5 qpid-cpp-server-store-0.7.946106-16.el5 qpid-cpp-server-xml-0.7.946106-16.el5 qpid-dotnet-0.4.738274-2.el5 qpid-java-client-0.7.946106-10.el5 qpid-java-common-0.7.946106-10.el5 qpid-tools-0.7.946106-11.el5 ruby-qpid-0.7.946106-2.el5 ruby-saslwrapper-0.1.934605-2.el5 saslwrapper-0.1.934605-2.el5 saslwrapper-devel-0.1.934605-2.el5 -> VERIFIED
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
In order to prevent management messages from being accidentally staged, the "--staging-threshold" command line option is no longer supported by the qpidd daemon.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0773.html |