<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>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
<a class="moz-txt-link-freetext" href="http://download.dre.vanderbilt.edu">http://download.dre.vanderbilt.edu</a>, that is the most recent micro
release.</p>
<p>Regards,<br>
</p>
<pre class="moz-signature" cols="72">Johnny Willemsen
Remedy IT
<a class="moz-txt-link-freetext" href="http://www.remedy.nl">http://www.remedy.nl</a></pre>
<div class="moz-cite-prefix">On 4/13/20 11:28 AM, Somisetty, Nagesh
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BLAPR15MB39408F462E9B428271B73F19ACDD0@BLAPR15MB3940.namprd15.prod.outlook.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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
Server 6.8<br>
COMPILER NAME AND VERSION (AND PATCHLEVEL): g++ (GCC) 4.4.7
20120313 (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
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 ACE_Acceptor and ACE_SSL_Sock_Stream<br>
<br>
DESCRIPTION:<br>
1) I have an ACE_Acceptor based server application that works
either 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,
ACE_NULL_SYNCH><br>
class TLSServer : public ACE_Svc_Handler<ACE_SSL_SOCK_STREAM,
ACE_NULL_SYNCH><br>
Both these TCPServer and TLSServer have implemented the
handle_input callbacks for handling of incoming events from the
socket.<br>
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.<br>
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.<br>
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.<br>
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.<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>
<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" moz-do-not-send="true">http://www.mimecast.com</a>
<hr width="100%"> </span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ace-bugs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ace-bugs@list.isis.vanderbilt.edu">ace-bugs@list.isis.vanderbilt.edu</a>
<a class="moz-txt-link-freetext" href="http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ace-bugs">http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ace-bugs</a></pre>
</blockquote>
</body>
</html>