<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1930310909;
mso-list-type:hybrid;
mso-list-template-ids:-160764510 1074331663 1074331673 1074331675 1074331663 1074331673 1074331675 1074331663 1074331673 1074331675;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head><body lang="EN-IN" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I wrote a simple server and client example and built it with the latest ACE 6.5.8. I could still recreate the issue that was earlier reported.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Please find attached the tar file containing the server and client example applications written.<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="mso-fareast-language:EN-US">Linux OS version of our development environment: Red Hat Enterprise Linux Server release 6.4<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="mso-fareast-language:EN-US">GCC version: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Steps to run the server and client example applications are as follows.<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><b><span style="mso-fareast-language:EN-US">Server</span></b><span style="mso-fareast-language:EN-US">: tls_server_app <server_ip:port> <debug_level> <path_to_SSL_key_file> <path_to_SSL_certificate_file>
<size_of_client_msg><br>
For example: tls_server_app 172.21.41.55:4443 info server.key server.cert 494<br>
The current client example sends a message of 494 bytes. This needs to be changed accordingly for a different sized client message.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><b><span style="mso-fareast-language:EN-US">Client</span></b><span style="mso-fareast-language:EN-US">: tls_client_app <server_ip> <port> <path_to_SSL_certificate_file><br>
For example: tls_client_app 172.21.41.55 4443 server.pem<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="mso-fareast-language:EN-US">Once we run the server and the client for about 20-30 minutes (or sometimes even earlier), we see that the following log on the server indicating
that there is no handle_input received for the inactivity time duration. <br>
<span style="background:yellow;mso-highlight:yellow">2020-04-21 14:08:54.333208 [19984] TCP Connection will be closed as connection is inactive for long time.</span><o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Nagesh<o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Johnny Willemsen <jwillemsen@remedy.nl>
<br>
<b>Sent:</b> Tuesday, April 14, 2020 2:26 PM<br>
<b>To:</b> Somisetty, Nagesh <NSomisetty@tnsi.com>; ace-bugs@list.isis.vanderbilt.edu<br>
<b>Cc:</b> Zhao, Changchun <czhao@tnsi.com>; Santhappanavara, Sharath <SSanthappanavara@tnsi.com>; Gupta, Ajay <agupta@tnsi.com><br>
<b>Subject:</b> Re: [ace-bugs] ACE_Svc_Handler handle_input not called in some scenarios randomly when using ACE_SSL_Sock_Stream and ACE_Acceptor<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi,<br>
<br>
Maybe also try a newer RHEL release with newer SSL version, maybe it is<br>
an issue in the underlying OS.<br>
<br>
Johnny Willemsen<br>
Remedy IT<br>
<a href="http://www.remedy.nl">http://www.remedy.nl</a><br>
<br>
On 4/14/20 10:52 AM, Johnny Willemsen wrote:<br>
> Hi,<br>
><br>
> 6.5.0 is the latest minor, 6.5.8 is the latest micro but not much has<br>
> very likely changed in this area.<br>
><br>
> Please try to extend/add a unit test under ACE_wrappers/tests to<br>
> reproduce this issue.<br>
><br>
> Regards,<br>
><br>
> Johnny Willemsen<br>
> Remedy IT<br>
> <a href="http://www.remedy.nl">
http://www.remedy.nl</a><br>
><br>
> On 4/13/20 2:59 PM, Somisetty, Nagesh wrote:<br>
>> Thanks Johnny.<br>
>><br>
>> <br>
>><br>
>> I’ve also tried with the ACE 6.5.0, but it did not help. I was still<br>
>> observing the same issues as reported in the PRF.<br>
>><br>
>> <br>
>><br>
>> Regards,<br>
>><br>
>> Nagesh<br>
>><br>
>> <br>
>><br>
>> *From:*Johnny Willemsen <<a href="mailto:jwillemsen@remedy.nl">jwillemsen@remedy.nl</a>><br>
>> *Sent:* Monday, April 13, 2020 6:00 PM<br>
>> *To:* Somisetty, Nagesh <<a href="mailto:NSomisetty@tnsi.com">NSomisetty@tnsi.com</a>>;<br>
>> <a href="mailto:ace-bugs@list.isis.vanderbilt.edu">ace-bugs@list.isis.vanderbilt.edu</a><br>
>> *Cc:* Zhao, Changchun <<a href="mailto:czhao@tnsi.com">czhao@tnsi.com</a>>; Santhappanavara, Sharath<br>
>> <<a href="mailto:SSanthappanavara@tnsi.com">SSanthappanavara@tnsi.com</a>>; Gupta, Ajay <<a href="mailto:agupta@tnsi.com">agupta@tnsi.com</a>><br>
>> *Subject:* Re: [ace-bugs] ACE_Svc_Handler handle_input not called in<br>
>> some scenarios randomly when using ACE_SSL_Sock_Stream and ACE_Acceptor<br>
>><br>
>> <br>
>><br>
>> Hi,<br>
>><br>
>> Thanks for using the PRF form. 6.2.0 is already pretty old, can you trie<br>
>> ACE 6.5.8 which you can download from<br>
>> <a href="http://download.dre.vanderbilt.edu">
http://download.dre.vanderbilt.edu</a>, that is the most recent micro release.<br>
>><br>
>> Regards,<br>
>><br>
>> Johnny Willemsen<br>
>><br>
>> Remedy IT<br>
>><br>
>> <a href="http://www.remedy.nl">
http://www.remedy.nl</a><br>
>><br>
>> On 4/13/20 11:28 AM, Somisetty, Nagesh wrote:<br>
>><br>
>> ACE VERSION: 6.2.0<br>
>><br>
>> HOST MACHINE and OPERATING SYSTEM: RHEL Server 6.8<br>
>> If on Windows based OS's, which version of WINSOCK do you<br>
>> use?:<br>
>><br>
>> TARGET MACHINE and OPERATING SYSTEM, if different from HOST: RHEL<br>
>> Server 6.8<br>
>> COMPILER NAME AND VERSION (AND PATCHLEVEL): g++ (GCC) 4.4.7 20120313<br>
>> (Red Hat 4.4.7-3)<br>
>><br>
>> THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-<br>
>> specific file, simply state which one]:<br>
>><br>
>> THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you<br>
>> use a link to a platform-specific file, simply state which one<br>
>> (unless this isn't used in this case, e.g., with Microsoft Visual<br>
>> C++)]:<br>
>><br>
>> CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features<br>
>> (used by MPC when you generate your own makefiles):<br>
>><br>
>> AREA/CLASS/EXAMPLE AFFECTED:<br>
>> ACE_Svc_Handler handle_input not called (in some cases) when using<br>
>> ACE_SSL_Sock_Stream and ACE_Acceptor<br>
>><br>
>> DOES THE PROBLEM AFFECT:<br>
>> COMPILATION?<br>
>> LINKING?<br>
>> On Unix systems, did you run make realclean first?<br>
>> EXECUTION?<br>
>> OTHER (please specify)?<br>
>> Described problem affects the EXECUTION of the application<br>
>><br>
>> SYNOPSIS:<br>
>> ACE_Svc_Handler handle_input not called in some scenarios when using<br>
>> ACE_Acceptor and ACE_SSL_Sock_Stream<br>
>><br>
>> DESCRIPTION:<br>
>> 1) I have an ACE_Acceptor based server application that works either<br>
>> as a TCP or TLS server.<br>
>> 2) The TCP and TLS services are defined as below,<br>
>> typedef ACE_Acceptor<TCPServer, ACE_SOCK_ACCEPTOR> TCPService;<br>
>> typedef ACE_Acceptor<TLSServer, ACE_SSL_SOCK_ACCEPTOR> TLSService;<br>
>> where TCPServer and TLSServer are derived from ACE_Svc_Handler as below<br>
>> class TCPServer : public ACE_Svc_Handler<ACE_SOCK_STREAM,<br>
>> ACE_NULL_SYNCH><br>
>> class TLSServer : public ACE_Svc_Handler<ACE_SSL_SOCK_STREAM,<br>
>> ACE_NULL_SYNCH><br>
>> Both these TCPServer and TLSServer have implemented the handle_input<br>
>> callbacks for handling of incoming events from the socket.<br>
>> 3) Our observation is that while using the TLSServer, we see that<br>
>> the handle_input is not called in a few cases as listed below.<br>
>> a) When the application attempts to do a peer().recv(buff,len) on<br>
>> receiving a handle_input and the application buffer size remaining<br>
>> is smaller than the number of bytes available on the socket to be<br>
>> read, only the number of bytes that can be read into the buffer are<br>
>> actually read. After this the application expects another<br>
>> handle_input for the remaining bytes that are still on the socket<br>
>> that are yet to be read. In this scenario, we never receive the<br>
>> subsequent handle_input event so that we can do the next<br>
>> peer().recv(buf,len) call to read the remaining bytes from the<br>
>> socket. As a workaround for this, we changed the buffer allocation<br>
>> logic to ensure the application doesn't wait for the next<br>
>> handle_input if there are more bytes than the remaining buffer size.<br>
>> We solved this problem with the workaround, but we encountered the<br>
>> issues described in 3b below.<br>
>> b) On running load tests with a TLS client which keeps sending https<br>
>> requests continuously, we found that the server randomly freezes<br>
>> after anywhere between 1 and 30 minutes and when we check it looks<br>
>> like we never received a handle_input event at the TLSServer. There<br>
>> is no logic on the client that causes it to stop sending requests.<br>
>> So, it has to be something to do with the handle_input events not<br>
>> being notified to the application.<br>
>> 4) Please note that the issues 3a and 3b are not observed while<br>
>> using TCPServer and TCP clients. The logic in the handle_input for<br>
>> both TCP and TLS is exactly the same.<br>
>><br>
>><br>
>> REPEAT BY:<br>
>> [What you did to get the error; include test program or session<br>
>> transcript if at all possible. ]<br>
>><br>
>> SAMPLE FIX/WORKAROUND:<br>
>> No fix available. Looking for a solution or an explanation.<br>
>><br>
>> ------------------------------------------------------------------------<br>
>><br>
>> This email has been scanned for email related threats and delivered<br>
>> safely by Mimecast.<br>
>> For more information please visit <a href="http://www.mimecast.com">
http://www.mimecast.com</a><br>
>><br>
>> ------------------------------------------------------------------------<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>><br>
>> ace-bugs mailing list<br>
>><br>
>> <a href="mailto:ace-bugs@list.isis.vanderbilt.edu">ace-bugs@list.isis.vanderbilt.edu</a> <<a href="mailto:ace-bugs@list.isis.vanderbilt.edu">mailto:ace-bugs@list.isis.vanderbilt.edu</a>><br>
>><br>
>> <a href="http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ace-bugs">
http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ace-bugs</a><br>
>><br>
>><br>
>><br>
>> ------------------------------------------------------------------------<br>
>> This email has been scanned for email related threats and delivered<br>
>> safely by Mimecast.<br>
>> For more information please visit <a href="http://www.mimecast.com">
http://www.mimecast.com</a><br>
>> ------------------------------------------------------------------------<br>
> _______________________________________________<br>
> ace-bugs mailing list<br>
> <a href="mailto:ace-bugs@list.isis.vanderbilt.edu">ace-bugs@list.isis.vanderbilt.edu</a><br>
> <a href="http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ace-bugs">
http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ace-bugs</a><o:p></o:p></p>
</div>
<br><br><span style="font-family:Arial; Font-size:10.0pt"> <hr width="100%"> This email has been scanned for email related threats and delivered safely by Mimecast.<br> For more information please visit <a href="http://www.mimecast.com">http://www.mimecast.com</a> <hr width="100%"> </span></body></html>