[jira] [Commented] (QPID-3264) Channel exception: session-busy: Session already attached
[ https://issues.apache.org/jira/browse/QPID-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038425#comment-13038425 ] Pavel Moravec commented on QPID-3264: - Question to Barys: Why It is impossible to setup c++ client to create new session while reconnect failure? - can you please elaborate? You mean when automatic reconnection fails due to the case above, you run some commands attempting to reconnect explicitly but the client fail to be connected? Can you paste relevant part of the source code, please? Channel exception: session-busy: Session already attached - Key: QPID-3264 URL: https://issues.apache.org/jira/browse/QPID-3264 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.8 Environment: Broker on RedHat 5.6 64bit; Client on Windows 7. Reporter: Barys Ilyushonak While client reconnect we got: 2011-05-11 16:15:07 error Channel exception: session-busy: Session already attached: .a7235961-c1f9-4a76-923c-ff06b09ad0c5 (qpid/broker/SessionManager.cpp:55) To reproduce: Start linux broker on default port 5672. Create durable queue and exchange. Start the broker. Start client. Client sent the first message. We sow this message on the broker. After that enable IPTABLES to reject the port. Client still sent messages, but there was no new messages on the broker. After that disable IPTABLES to reject the port. It is important do not restart the client. After that we have got the error in the broker log. On the client: std::auto_ptrqpid::messaging::Connection m_connection m_connection.reset(new Connection(m_url)); m_connection-setOption(reconnect, true); We limit network access on the broker machine. To close the port we use: iptables -A INPUT -p tcp -s 10.30.24.181 --dport 5672 -j REJECT where 10.30.24.181 - windows client IP to enable access we use: iptables -D INPUT -p tcp -s 10.30.24.181 --dport 5672 -j REJECT -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3275) QMF Console asynchronous correlation-id should be scoped to the session, not the specific agent
QMF Console asynchronous correlation-id should be scoped to the session, not the specific agent --- Key: QPID-3275 URL: https://issues.apache.org/jira/browse/QPID-3275 Project: Qpid Issue Type: Improvement Reporter: Ted Ross Assignee: Ted Ross Priority: Minor When using asynchronous operations from the qmf console (qmf::ConsoleSession), the correlation-id returned is scoped to the specific agent. This forces the user to combine the agent identity with the correlation-id to correlate ta response to a request. It would be more efficient if the correlation-id were guaranteed unique across all agents in the session. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3275) QMF Console asynchronous correlation-id should be scoped to the session, not the specific agent
[ https://issues.apache.org/jira/browse/QPID-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated QPID-3275: --- Component/s: Qpid Managment Framework Affects Version/s: 0.10 Fix Version/s: 0.11 QMF Console asynchronous correlation-id should be scoped to the session, not the specific agent --- Key: QPID-3275 URL: https://issues.apache.org/jira/browse/QPID-3275 Project: Qpid Issue Type: Improvement Components: Qpid Managment Framework Affects Versions: 0.10 Reporter: Ted Ross Assignee: Ted Ross Priority: Minor Fix For: 0.11 When using asynchronous operations from the qmf console (qmf::ConsoleSession), the correlation-id returned is scoped to the specific agent. This forces the user to combine the agent identity with the correlation-id to correlate ta response to a request. It would be more efficient if the correlation-id were guaranteed unique across all agents in the session. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
JMS Error handling
Folks, I am trying to tidy up the error handling code in the JMS client and is soliciting ideas and feedback. I also have rough proposal outlined below. Please feel free to make suggestions/improvements for the following solution or any alternative ideas that you might think maybe better. Currently if there is a session error we throw an exception on most JMS methods in addition to notifying via the connection listener. This is causing several issues with less than desirable results. Besides I wonder if we need to notify the same exception in two different ways. 1. There is a deadlock due to this. 2. Even if the client is notified via a direct exception we still throw a connection exception and close the connection (along with all other sessions). I am wondering if the following is a good idea ? 1. If a direct exception can be thrown, then we don't notify via the connection listener. Ex. sending messages, creating a producer/consumer etc... 2. If a direct exception cannot be thrown (ex. Message Listener case) then we notify via the connection listener. In that case we don't care about the rest of the sessions being closed. 3. We mention in the documentation, that if a JMS exception is thrown, they should recreate their session. If a specific type of exception like MessageNotReadableException is thrown, then they are advised to treat it accordingly. Regards, Rajith - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
