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

[Johnny Willemsen]

Hi,

Thanks for using the PRF form. 6.2.0 is already pretty old, can you trie
ACE 6.5.8 which you can download from
http://download.dre.vanderbilt.edu, that is the most recent micro release.

Regards,

Johnny Willemsen
Remedy IT
http://www.remedy.nl

On 4/13/20 11:28 AM, Somisetty, Nagesh wrote:
> 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
> ------------------------------------------------------------------------
>
> _______________________________________________
> ace-bugs mailing list
> ace-bugs at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ace-bugs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/pipermail/ace-bugs/attachments/20200413/ede9e21f/attachment-0001.html>