RO client hang in Login

I have a RO client server setup based on IpHttpClientChannel with SSL.
In rare cases (where server exe gets restarted or other) I have a client (thread) which hangs.
It looks like it hangs in the RO Login procedure.
I set the Timeout value to prevent this but this does not work

Is there something I am doing wrong in my code which could cause this

Call stack:

Client code snippets:

        ((RemObjects.SDK.IpHttpClientChannel)this.clientChannel).Timeout = 5 * 60; 

        var binMessage = ((RemObjects.SDK.BinMessage)message);
        binMessage.MaxMessageSize = Int32.MaxValue;
        binMessage.MaxDecompressedMessageSize = Int32.MaxValue;
        binMessage.UseCompression = true;  // FVC: Note: By default true
        binMessage.EnforceMaxMessageSize = false; // FVC: Needs to be done here and on the server side (decompress option) - As suggested by Evgeny on 11/04/2023 cfr.
        if (servicesuffix == NetworkUtil.ctServiceSuffixAES)
          binMessage.Envelopes.Add(new RemObjects.SDK.MessageEnvelopeItem(new AesEncryptionEnvelope(aespassphrase)));
        else if (servicesuffix==NetworkUtil.ctServiceSuffixPassThrough)
          binMessage.Envelopes.Add(new RemObjects.SDK.MessageEnvelopeItem(new PassThroughEnvelope()));
        /* FVC: Alternative is one envelope with all the envelopes (on binenv service suffix) but then we need to select using  binMessage.Envelopes[x].Enabled = false/true;
         * However the receiving end will need to do something similar */          

    public bool connect(out string errormsg, string serverurl = null, string user = null, string pwd = null,ROConnectionConfig coninfo=null, int connecttimeout = 5)
      setCredentials(serverurl, preferredConnection_, user, pwd,coninfo);
      errormsg = null;
      bool bLoginOK = false;
        roCon_ = Officinall.Utility.ROConnectionInfo.createPreferredROConnection(serverurl_, preferredConnection_, connecttimeout,connectionConfig_.aespassphrase_);
        //roCon_ = Officinall.Utility.ROConnectionInfo.createROSuperHttpsConnection(serverurl_, connecttimeout); // FVC 10/2021: super https keeps connection alive but does not support counting the network traffic yet (should also have pushed server->client events)
        //roCon_ = Officinall.Utility.ROConnectionInfo.CreateROHttpsConnection(serverurl_);        // FVC 10/2021: IpHttpClientChannel supports counting network traffic and has simple keepalive but needs to create more connections than superhttp
        if (roCon_.clientChannel is RemObjects.SDK.ClientChannel)
          var cc = (RemObjects.SDK.ClientChannel)roCon_.clientChannel;
          cc.OnLoginNeeded += new System.EventHandler<RemObjects.SDK.LoginNeededEventArgs>(this.ClientChannel_OnLoginNeeded);
        if (roCon_.clientChannel is RemObjects.SDK.IpHttpClientChannel)
          var httpch = (RemObjects.SDK.IpHttpClientChannel)roCon_.clientChannel;
          httpch.BeforeSendStream += ClientChannel_BeforeSendStream;
          httpch.AfterReceiveStream += ClientChannel_AfterReceiveStream;

          if (connectionConfig_.clientcert_!=null)
            httpch.SslOptions.Certificate = connectionConfig_.clientcert_;

        bLoginOK = this.performLogin(false);

protected override bool performLogin(bool bLoginNeeded)
      var itfLogin = OffCloudServer.CoCloudPharmacyLoginService.Create(roCon.message, roCon.clientChannel);
      var loginData = new CloudLoginData(curSessionUser, curPharmacyName_, curSessionPassword, curSessionMachineId_, curClientTags_,
      string jsonLoginData = loginData.saveToJson(null);
      bool bRet=itfLogin.Login(curSessionUser, jsonLoginData);
      return bRet;

FYI:Netstat shows me


I looked at thre threads and callstacks of the server process but I do not see any issues or clues to what this issue is

FYI: TimeoutEnabled=True
Is there some case where the read timeout does not work?

I can do some experiments (e.g. killing the server) but would like to know if i can do some tests now while the problem still can be witnessed


I think, usage of SSL may have some influence.
Can you confirm, that this issue is reproduced with IpHttpClientChannel without SSL, pls?

It’s hard to reproduce in any case. I’ll try to set up some tests when I find some time