[jira] [Commented] (QPID-3264) Channel exception: session-busy: Session already attached

["Pavel Moravec (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037825#comment-13037825 ] 

Pavel Moravec commented on QPID-3264:
-------------------------------------

The case seems for me hard to be fully fixed. See below my analysis of what happens (using Linux terminology, but analogue behavior is correct for Widnows as well):

1) When TCP retransmission gives up, kernel sends ETIMEDOUT to userspace and moves
the local socket from ESTABLISHED to CLOSED status - i.e. _no_ RST packet is
sent on the connection. This results in situation where:
  a) the client does not have the TCP connection established
  b) the server _has_ the connection established (in ESTABLISHED state even)
  c) the server has not received any indication that the client has some
transmitting problems. The server can detect the TCP connection being broken
only when sending TCP keepalive probe (based on the default setting of kernel
parameter net.ipv4.tcp_keepalive_time, it will be done after 3 hours)

That seems to follow RFCs (at least, I haven't found any indication that
dropping the TCP connection on client side in the way above is not allowed).

2) The client tries to reconnect to the server using new TCP session but
previously used connection ID. That leads to the AMQP session rejection.

I don't see an easy fix of this - both sides are behaving properly per information and state they have and are in..

I see two workarounds here:

1) Use heartbeats to detect the network problems sooner than TCP and OS do so. I.e. set heartbeats to at most 1/2 of TCP retransmission overall-time (that by default around 15 minutes on Linux and 12 seconds(!) on Windows).
2) Align number of TCP retransmissions so that any (expected) network outage is shorter than the full TCP retransmission round. Then, some retransmission will be successfull and no disconnection would happen.



> 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_ptr<qpid::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-subscribe@qpid.apache.org