[jira] [Commented] (QPID-4233) Windows C++ client does not reconnect when port is block then re-opened (e.g by firewall)

["Richard Sheath (JIRA)" <ji...@apache.org>]

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

Richard Sheath commented on QPID-4233:
--------------------------------------

Further to the above issue. When we unblock the firewall port, Qpid is unable to re-establish the connection. This may be related to settings on the server that we are connecting to but it would be interesting to know if this is relevant. The below are printed in the qpid log:

debug Exception constructed: Session detached by peer
error session-busy: Session detached by peer
                
> Windows C++ client does not reconnect when port is block then re-opened (e.g by firewall) 
> ------------------------------------------------------------------------------------------
>
>                 Key: QPID-4233
>                 URL: https://issues.apache.org/jira/browse/QPID-4233
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Client
>    Affects Versions: 0.14, 0.16, Future
>         Environment: Windows 7 64bit
>            Reporter: Richard Sheath
>
> Looking at the qpid client code it doesn't seem to handle reconnection if the tcp port is blocked and then unblocked.
> We are using the Windows client with SSL and SASL having applied this patch to the 0.14 codebase: https://issues.apache.org/jira/browse/QPID-3914
> I then noticed this JIRA which sounded like the same issue that I was experiencing https://issues.apache.org/jira/browse/QPID-3759 and applied the patch but I am still getting the same issue. 
> This is a sample of how we are creating the connection:
> m_pConnection = new qpid::messaging::Connection::Connection("amqp:ssl:<IP1>:<port1>,<IP2>:<port2>", ""); //(IP1:port1 and IP2:port2 are the same as we currently only have one server to connect to.
> m_pConnection->setOption("transport","ssl");
> m_pConnection->setOption("sasl_mechanisms", "EXTERNAL");
> m_pConnection->setOption("ssl-cert-filename", m_strSslCertFileName.c_str());
> m_pConnection->setOption("ssl-cert-filenamepass",m_strSslCertFileNamePassword.c_str());
> m_pConnection->setOption("host-cert-filename",m_strHostCertFileName.c_str());
> m_pConnection->setOption("heartbeat",30); //30 seconds, defaults to 0 which is no heartbeats
> m_pConnection->setOption("reconnect",true); //defaults to false
> m_pConnection->setOption("reconnect-interval",30); //30 seconds, default is 60 seconds
> m_pConnection->open();
> We then create 3 Sessions from the connection e.g.:
> m_SessionResponse = m_pConnection->createSession("Response");
> Using one of these sessions we create both a receiver and a sender.
> And we create a receiver for each of the other 2 sessions.
> I am expecting these receivers and sender to remain active for the lifetime of the program. We call receiver.fetch(Duration::SECOND * 10); in a loop on its own thread for each receiver.
> We start the application and it connects and runs ok. Then we block the port using windows firewall to simulate a network issue. At this point the .fetch(Duration::SECOND * 10); never returns from the call. And if you call the qpid::messaging::Sender::send function this returns with no exceptions thrown.
> I am not sure what exactly should happen in this scenario these are my thoughts please advise/correct:
> 1) At worst the fetch should throw an exception so the calling application knows there is a problem.
> 2) Possibly the send should also throw an exception, again so the calling application knows there is a problem.
> 3) If "reconnect" is enabled then we should try to reconnect (to the same IP:port).
> 4) If multiple IPs are specified we should failover to the next IP on reconnect.
> I can see in the qpid log that the heartbeats are timing out with this message "Traffic timeout". This could possibly be used to trigger the reconnect.
> Also I noticed when debugging that void TCPConnector::eof(AsynchIO&) is called much before the heartbeat timeout and maybe this could be used instead.
> I am new to this codebase so any help would be appreciated. It could even be that I am just using the qpid library in the wrong way or have missing a required config setting or setOption.
> Thanks
> Richard

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org