[Vortex] Failure to establish connection between client and server in some of machines with RedHat 6.1 operating system

[subrahmanya]

HI Francis,

You mean RedHat Enterprise Linux 6.1, don't you? Or the older RedHat
6.1? Which arch?
[Subrahmanya] It is RedHat Enterprise Linux. Architecture is x86_64.

Thanks
Subrahmanya

On Wed, Aug 22, 2012 at 6:17 PM, Francis Brosnan Blazquez
<francis at aspl.es>wrote:

> > Hi
>
> Hi Subrahmanya,
>
> > We are developing and testing an application that involves a vortex
> > (version 1.1.8) based client and a server which uses Java
> > implementation of BEEP. The application has been running fine on
> > several platforms including Linux, AIX, HP, Solaris. In one the
> > machines which runs RedHat 6.1 we are facing issues.
>
> You mean RedHat Enterprise Linux 6.1, don't you? Or the older RedHat
> 6.1? Which arch?
>
> > The failure happens during connection establishment. The error message
> > indicates that socket connect operation is in progress. Following are
> > vortex log messages. Please note that the line numbers may not match
> > with the vortex 1.1.8 code since I had added a few extra log messages
> > in the same file.
> >
> >
> > (debug) vortex_connection.c:1661 executing connection new in blocking
> > mode to localhost:47720 id=1
> > (debug) vortex_connection.c:1274 detected connect timeout during 30
> > seconds (starting from: 1344323279)
> > (debug) vortex_connection.c:1294 __vortex_connection_wait_on (sock=4)
> > operation finished, err=1, errno=115 (Operation now in progress),
> > wait_for=2 (ellapsed: 0)
> > (warning) vortex_connection.c:1310 error level set on waiting socket
> > (debug) vortex_connection.c:1321 timeout operation finished, with
> > err=-6, errno=115, ellapsed time=0 (seconds)
> > (warning) vortex_connection.c:1470 unable to connect to remote host
> > (timeout)
> > (debug) vortex_connection.c:2373 closing a connection which is not
> > opened, unref resources..
> >
> >
> > I looked at the function "__vortex_connection_wait_on" that sets the
> > error to "-6" and logs the first warning message. The function
> > "vortex_io_waiting_invoke_wait" which calls "epoll" (epoll is
> > available in this OS version) returns the number of writable FDs. If
> > the return value is >0 then vortex calls "getsockopt" to get any error
> > on the socket. This seems to give value for SO_ERROR as "111", which
> > stands for "Connection refused". Since the number of file descriptors
> > ready for write is greater than zero I thought calling "getsockopt" is
> > not necessary and hence removed the code to call "getsockopt". This
> > means if the number of FDs ready for write is >0 then I assume the
> > socket is ready and hence break from the loop.
>
> This is not enterily true as you may have a valid working fd that points
> to a socket with a failure state...
>
> > With this change the issue being hit earlier was resolved. This meant
> > that "getsockopt" returned wrong error code. I am wondering if that is
> > because of calling getsockopt even in success case.
> >
> >
> > Note that without the above mentioned change the issue was very
> > consistent and frequent but with the change the issue was not observed
> > at all.
> >
> >
> > Now I want to know if the above mentioned change is correct. I see a
> > comment in "__vortex_connection_wait_on" function which mentions about
> > an issue with not calling getsockopt API in older version of Linux. Is
> > this still applicable? I checked with a few of colleagues who have a
> > few years of experience of using these APIs. They mentioned that it
> > would have been required in older versions but not in the current
> > versions of operating systems.
> >
> >
> > So the question is "Is it fine not to call getsockopt API and check
> > SO_ERROR when the number of file descriptors ready is greater than
> > zero?".
>
> No, it isn't.
>
> It is not clear that this API is deprecated or provides different
> behavior in older versions. An important consideration that may explain
> this problem is a bug in the libc6 used by that linux box or a bug in
> the kernel...
>
> I'll look for a moment to have a look into this issue as there is no
> clear or direct answer without investing some time....
>
> Thanks for reporting anyway, and let us to know if you find the
> explanation about this!
> [Subrahmanya] Sure will let you know.
>


> Cheers!
>
>
> > Thanks
> > Subrahmanya
> > _______________________________________________
> > Vortex mailing list
> > Vortex at lists.aspl.es
> > http://lists.aspl.es/cgi-bin/mailman/listinfo/vortex
>
> --
> Francis Brosnan Blázquez <francis.brosnan at aspl.es>
> ASPL
> 91 134 14 22 - 91 134 14 45 - 91 116 07 57
>
> AVISO LEGAL
>
> Este mensaje se dirige exclusivamente a su destinatario. Los datos
> incluidos en el presente correo son confidenciales y sometidos a secreto
> profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
> usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
> por cualquier motivo, le rogamos que nos lo comunique por este medio y
> proceda a destruirlo o borrarlo.
>
> En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
> diciembre, de Protección de Datos de Carácter Personal, le informamos de
> que sus datos de carácter personal, recogidos de fuentes accesibles al
> público o datos que usted nos ha facilitado previamente, proceden de
> bases de datos propiedad de Advanced Software Production Line, S.L.
> (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y oposición dispuestos en la mencionada Ley
> Orgánica, notificándolo por escrito a:
> ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
> Henares (Madrid).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.aspl.es/pipermail/vortex/attachments/20120823/a1afabda/attachment.htm>