[ace-bugs] ACE_Svc_Handler handle_input not called in some scenarios randomly when using ACE_SSL_Sock_Stream and ACE_Acceptor

[Somisetty, Nagesh]

  ACE VERSION: 6.2.0

    HOST MACHINE and OPERATING SYSTEM: RHEL Server 6.8
        If on Windows based OS's, which version of WINSOCK do you
        use?:

    TARGET MACHINE and OPERATING SYSTEM, if different from HOST: RHEL Server 6.8
    COMPILER NAME AND VERSION (AND PATCHLEVEL): g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)

    THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
    specific file, simply state which one]:

    THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you
    use a link to a platform-specific file, simply state which one
    (unless this isn't used in this case, e.g., with Microsoft Visual
    C++)]:

    CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
    (used by MPC when you generate your own makefiles):

    AREA/CLASS/EXAMPLE AFFECTED:
ACE_Svc_Handler handle_input not called (in some cases) when using ACE_SSL_Sock_Stream and ACE_Acceptor

    DOES THE PROBLEM AFFECT:
        COMPILATION?
        LINKING?
            On Unix systems, did you run make realclean first?
        EXECUTION?
        OTHER (please specify)?
Described problem affects the EXECUTION of the application

    SYNOPSIS:
ACE_Svc_Handler handle_input not called in some scenarios when using ACE_Acceptor and ACE_SSL_Sock_Stream

    DESCRIPTION:
1) I have an ACE_Acceptor based server application that works either as a TCP or TLS server.
2) The TCP and TLS services are defined as below,
typedef ACE_Acceptor<TCPServer, ACE_SOCK_ACCEPTOR> TCPService;
typedef ACE_Acceptor<TLSServer, ACE_SSL_SOCK_ACCEPTOR> TLSService;
where TCPServer and TLSServer are derived from ACE_Svc_Handler as below
class TCPServer : public ACE_Svc_Handler<ACE_SOCK_STREAM, ACE_NULL_SYNCH>
class TLSServer : public ACE_Svc_Handler<ACE_SSL_SOCK_STREAM, ACE_NULL_SYNCH>
Both these TCPServer and TLSServer have implemented the handle_input callbacks for handling of incoming events from the socket.
3) Our observation is that while using the TLSServer, we see that the handle_input is not called in a few cases as listed below.
a) When the application attempts to do a peer().recv(buff,len) on receiving a handle_input and the application buffer size remaining is smaller than the number of bytes available on the socket to be read, only the number of bytes that can be read into the buffer are actually read. After this the application expects another handle_input for the remaining bytes that are still on the socket that are yet to be read. In this scenario, we never receive the subsequent handle_input event so that we can do the next peer().recv(buf,len) call to read the remaining bytes from the socket. As a workaround for this, we changed the buffer allocation logic to ensure the application doesn't wait for the next handle_input if there are more bytes than the remaining buffer size. We solved this problem with the workaround, but we encountered the issues described in 3b below.
b) On running load tests with a TLS client which keeps sending https requests continuously, we found that the server randomly freezes after anywhere between 1 and 30 minutes and when we check it looks like we never received a handle_input event at the TLSServer. There is no logic on the client that causes it to stop sending requests. So, it has to be something to do with the handle_input events not being notified to the application.
4) Please note that the issues 3a and 3b are not observed while using TCPServer and TCP clients. The logic in the handle_input for both TCP and TLS is exactly the same.


    REPEAT BY:
[What you did to get the error; include test program or session
transcript if at all possible.  ]

    SAMPLE FIX/WORKAROUND:
No fix available. Looking for a solution or an explanation.
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/pipermail/ace-bugs/attachments/20200413/d6540ecd/attachment.html>