HI Francis,<div><br></div><div>You mean RedHat Enterprise Linux 6.1, don't you? Or the older RedHat<br>6.1? Which arch?
</div><div>[Subrahmanya] It is RedHat Enterprise Linux. Architecture is x86_64.</div><div><br></div><div>Thanks</div><div>Subrahmanya<br><br><div class="gmail_quote">On Wed, Aug 22, 2012 at 6:17 PM, Francis Brosnan Blazquez <span dir="ltr"><<a href="mailto:francis@aspl.es" target="_blank">francis@aspl.es</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Hi<br>
<br>
Hi Subrahmanya,<br>
<div class="im"><br>
> We are developing and testing an application that involves a vortex<br>
> (version 1.1.8) based client and a server which uses Java<br>
> implementation of BEEP. The application has been running fine on<br>
> several platforms including Linux, AIX, HP, Solaris. In one the<br>
> machines which runs RedHat 6.1 we are facing issues.<br>
<br>
</div>You mean RedHat Enterprise Linux 6.1, don't you? Or the older RedHat<br>
6.1? Which arch?<br>
<div><div class="h5"><br>
> The failure happens during connection establishment. The error message<br>
> indicates that socket connect operation is in progress. Following are<br>
> vortex log messages. Please note that the line numbers may not match<br>
> with the vortex 1.1.8 code since I had added a few extra log messages<br>
> in the same file.<br>
><br>
><br>
> (debug) vortex_connection.c:1661 executing connection new in blocking<br>
> mode to localhost:47720 id=1<br>
> (debug) vortex_connection.c:1274 detected connect timeout during 30<br>
> seconds (starting from: 1344323279)<br>
> (debug) vortex_connection.c:1294 __vortex_connection_wait_on (sock=4)<br>
> operation finished, err=1, errno=115 (Operation now in progress),<br>
> wait_for=2 (ellapsed: 0)<br>
> (warning) vortex_connection.c:1310 error level set on waiting socket<br>
> (debug) vortex_connection.c:1321 timeout operation finished, with<br>
> err=-6, errno=115, ellapsed time=0 (seconds)<br>
> (warning) vortex_connection.c:1470 unable to connect to remote host<br>
> (timeout)<br>
> (debug) vortex_connection.c:2373 closing a connection which is not<br>
> opened, unref resources..<br>
><br>
><br>
> I looked at the function "__vortex_connection_wait_on" that sets the<br>
> error to "-6" and logs the first warning message. The function<br>
> "vortex_io_waiting_invoke_wait" which calls "epoll" (epoll is<br>
> available in this OS version) returns the number of writable FDs. If<br>
> the return value is >0 then vortex calls "getsockopt" to get any error<br>
> on the socket. This seems to give value for SO_ERROR as "111", which<br>
> stands for "Connection refused". Since the number of file descriptors<br>
> ready for write is greater than zero I thought calling "getsockopt" is<br>
> not necessary and hence removed the code to call "getsockopt". This<br>
> means if the number of FDs ready for write is >0 then I assume the<br>
> socket is ready and hence break from the loop.<br>
<br>
</div></div>This is not enterily true as you may have a valid working fd that points<br>
to a socket with a failure state...<br>
<div class="im"><br>
> With this change the issue being hit earlier was resolved. This meant<br>
> that "getsockopt" returned wrong error code. I am wondering if that is<br>
> because of calling getsockopt even in success case.<br>
><br>
><br>
> Note that without the above mentioned change the issue was very<br>
> consistent and frequent but with the change the issue was not observed<br>
> at all.<br>
><br>
><br>
> Now I want to know if the above mentioned change is correct. I see a<br>
> comment in "__vortex_connection_wait_on" function which mentions about<br>
> an issue with not calling getsockopt API in older version of Linux. Is<br>
> this still applicable? I checked with a few of colleagues who have a<br>
> few years of experience of using these APIs. They mentioned that it<br>
> would have been required in older versions but not in the current<br>
> versions of operating systems.<br>
><br>
><br>
> So the question is "Is it fine not to call getsockopt API and check<br>
> SO_ERROR when the number of file descriptors ready is greater than<br>
> zero?".<br>
<br>
</div>No, it isn't.<br>
<br>
It is not clear that this API is deprecated or provides different<br>
behavior in older versions. An important consideration that may explain<br>
this problem is a bug in the libc6 used by that linux box or a bug in<br>
the kernel...<br>
<br>
I'll look for a moment to have a look into this issue as there is no<br>
clear or direct answer without investing some time....<br>
<br>
Thanks for reporting anyway, and let us to know if you find the<br>
explanation about this!<br>
[Subrahmanya] Sure will let you know.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers!<br>
<br>
<br>
> Thanks<br>
> Subrahmanya<br>
> _______________________________________________<br>
> Vortex mailing list<br>
> <a href="mailto:Vortex@lists.aspl.es">Vortex@lists.aspl.es</a><br>
> <a href="http://lists.aspl.es/cgi-bin/mailman/listinfo/vortex" target="_blank">http://lists.aspl.es/cgi-bin/mailman/listinfo/vortex</a><br>
<br>
--<br>
Francis Brosnan Blázquez <<a href="mailto:francis.brosnan@aspl.es">francis.brosnan@aspl.es</a>><br>
ASPL<br>
91 134 14 22 - 91 134 14 45 - 91 116 07 57<br>
<br>
AVISO LEGAL<br>
<br>
Este mensaje se dirige exclusivamente a su destinatario. Los datos<br>
incluidos en el presente correo son confidenciales y sometidos a secreto<br>
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si<br>
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo<br>
por cualquier motivo, le rogamos que nos lo comunique por este medio y<br>
proceda a destruirlo o borrarlo.<br>
<br>
En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de<br>
diciembre, de Protección de Datos de Carácter Personal, le informamos de<br>
que sus datos de carácter personal, recogidos de fuentes accesibles al<br>
público o datos que usted nos ha facilitado previamente, proceden de<br>
bases de datos propiedad de Advanced Software Production Line, S.L.<br>
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,<br>
rectificación, cancelación y oposición dispuestos en la mencionada Ley<br>
Orgánica, notificándolo por escrito a:<br>
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de<br>
Henares (Madrid).<br>
<br>
</blockquote></div><br></div>