| Summary: | [RFE] Session invalidated by any exception is too restrictive | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Mike Cressman <mcressma> |
| Component: | qpid-cpp | Assignee: | messaging-bugs <messaging-bugs> |
| Status: | CLOSED NOTABUG | QA Contact: | MRG Quality Engineering <mrgqe-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.3 | CC: | iboverma, jross, mflitter, pmoravec, sauchter, smumford |
| Target Milestone: | 3.2 | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-07-01 12:38:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 698367, 591287, 803771 | ||
Just FYI: this bug is related to AMQP 0-10 implementation _only_. As on 1.0 client, it behaves well.
To test it:
apply patch to drain.cpp:
Index: examples/messaging/drain.cpp
===================================================================
--- examples/messaging/drain.cpp (revision 1605024)
+++ examples/messaging/drain.cpp (working copy)
@@ -83,10 +83,11 @@
Options options;
if (options.parse(argc, argv) && options.checkAddress()) {
Connection connection;
+ Session session;
try {
connection = Connection(options.url, options.connectionOptions);
connection.open();
- Session session = connection.createSession();
+ /*Session*/ session = connection.createSession();
Receiver receiver = session.createReceiver(options.address);
Duration timeout = options.getTimeout();
int count = options.getCount();
@@ -105,6 +106,7 @@
return 0;
} catch(const std::exception& error) {
std::cout << "Error: " << error.what() << std::endl;
+ Receiver rec2 = session.createReceiver("testQ; {create:always}");
connection.close();
}
}
and then run:
service qpidd restart; ./BLD/examples/messaging/drain --connection-options "{protocol:amqp1.0}" "a"; qpid-stat -q testQ
(returns the queue details)
service qpidd restart; ./BLD/examples/messaging/drain "a"; qpid-stat -q testQ
(drain coredumps due to session=null or so and the queue does not exist)
So AMQP 1.0 code can give us (or me in particular) a good advice what exceptions should not close the session.
This behaviour is a limitation of AMQP 0-10 specification. Quoting spec: 3.4.1.3. Exceptions AMQP uses exceptions to handle errors. That is: 1. Any operational error (e.g. message queue not found or insufficient access rights) results in an exception which will destroy session state. .. Immediately after the Execution.Exception has been sent, the sending peer will destroy all session layer state held for this session, issue a session.request-timeout(0), and finally issue a session.detach. So, qpid broker follows AMQP 0-10 specification properly. And hence the bug is to be closed as NOTABUG. Note that AMQP 1.0 handles the use case much better (see #c8 above). So we should rarther convince customers to migrate from 0-10 to 1.0. (the pitty is, it took 3 years to close this BZ with this conclusion, and 2 days of my desperate attempts to fix it until I discovered it is against spec) |
Description of problem: Any time a client session receives an exception, that session, including any senders and receivers, is invalidated. There are some exceptions that are not destructive (for example, if user tries to create a sender or receiver where queue does not exist) and the session should be allowed to continue. Otherwise user must go through painful process of rebuilding session with all senders and receivers. Version-Release number of selected component (if applicable): qpid-cpp-server-0.7.946106-28 (MRG 1.3.x) qpid-cpp-server-0.10 (MRG 2.0.x) How reproducible: Always Steps to Reproduce: 1. Open a session 2. call Session.createReceiver("any-non-existent-name") 3. An exception is returned (queue does not exist) and session is now invalid 4. Any further calls on the session return the same exception Actual results: All senders and receivers on the session become invalid, and must be recreated within client. This can get very complex if you are trying not to lose messages, etc. Expected results: Senders and receivers should be able to continue for certain types of errors Additional info: