[ace-bugs] ACE_Svc_Handler handle_input not called in some scenarios randomly when using ACE_SSL_Sock_Stream and ACE_Acceptor
Johnny Willemsen
jwillemsen at remedy.nl
Tue Apr 14 03:56:26 CDT 2020
Hi,
Maybe also try a newer RHEL release with newer SSL version, maybe it is
an issue in the underlying OS.
Johnny Willemsen
Remedy IT
http://www.remedy.nl
On 4/14/20 10:52 AM, Johnny Willemsen wrote:
> Hi,
>
> 6.5.0 is the latest minor, 6.5.8 is the latest micro but not much has
> very likely changed in this area.
>
> Please try to extend/add a unit test under ACE_wrappers/tests to
> reproduce this issue.
>
> Regards,
>
> Johnny Willemsen
> Remedy IT
> http://www.remedy.nl
>
> On 4/13/20 2:59 PM, Somisetty, Nagesh wrote:
>> Thanks Johnny.
>>
>>
>>
>> I’ve also tried with the ACE 6.5.0, but it did not help. I was still
>> observing the same issues as reported in the PRF.
>>
>>
>>
>> Regards,
>>
>> Nagesh
>>
>>
>>
>> *From:*Johnny Willemsen <jwillemsen at remedy.nl>
>> *Sent:* Monday, April 13, 2020 6:00 PM
>> *To:* Somisetty, Nagesh <NSomisetty at tnsi.com>;
>> ace-bugs at list.isis.vanderbilt.edu
>> *Cc:* Zhao, Changchun <czhao at tnsi.com>; Santhappanavara, Sharath
>> <SSanthappanavara at tnsi.com>; Gupta, Ajay <agupta at tnsi.com>
>> *Subject:* Re: [ace-bugs] ACE_Svc_Handler handle_input not called in
>> some scenarios randomly when using ACE_SSL_Sock_Stream and ACE_Acceptor
>>
>>
>>
>> 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 <mailto:ace-bugs at list.isis.vanderbilt.edu>
>>
>> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ace-bugs
>>
>>
>>
>> ------------------------------------------------------------------------
>> 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
More information about the ace-bugs
mailing list