#557 select() timeout in tcp_connect()

[markus]

Got following error when using two client proxies in parallel:

SOAP 1.1 fault: SOAP-ENV:Client [no subcode]
"Timeout"
Detail: connect failed in tcp_connect()

Two different client proxies are used within two different threads by a client application.
Each of these threads calls a proxy method cyclically every 4 seconds (triggered by a third thread quasi at the same time).
Approximately every 20 minutes one of the calls fails with the error above.
In that case, the select() in tcp_connect() returns with timeout (connect_timeout set to 3 seconds), because it is waiting on an invalid socket file descriptor.
If the timing is modified lightly (by delaying one of the threads), the error has other appearances, e.g. "bad file descriptor when setting the socket options", or disappears at all.

Version info: gSOAP 2.7.10 (C++) on QNX 6.3

Thanks and Regards
Markus

[Robert van Engelen]

Threads should not share the same soap context. Just create a duplicate soap context (soap environment) using soap_copy(). Otherwise, the threads may manipulate each other's state. If this is not the problem you are referring to, then please be more specific about the issue and send us some code or something more detailed.

[markus]

The two proxies metioned above look roughly like this:
...
namespace ns1 {
class Proxy1
{ public:
/// Runtime engine context allocated in constructor
struct soap *soap;
/// Endpoint URL of service 'Proxy1' (change as needed)
const char *endpoint;
/// Constructor allocates soap engine context, sets default endpoint URL, and sets namespace mapping table
Proxy1() { soap = soap_new(); if (soap) soap->namespaces = ns1_namespaces; endpoint = "http://10.1.1.100/Proxy1"; };
/// Destructor frees deserialized data and soap engine context
virtual ~Proxy1() { if (soap) { soap_destroy(soap); soap_end(soap); soap_free(soap); } };
/// Invoke 'remoteMethod' of service 'Proxy1' and return error code (or SOAP_OK)
virtual int __ns1__remoteMethod(ns1__remoteMethod *ns1__remoteMethod_, ns1__remoteMethodResponse *ns1__remoteMethodResponse_) { return soap ? soap_call___ns1__remoteMethod(soap, endpoint, NULL, ns1__remoteMethod_, ns1__remoteMethodResponse_) : SOAP_EOM; };
};
} // namespace ns1
...
...
namespace ns2 {
class Proxy2
{ public:
/// Runtime engine context allocated in constructor
struct soap *soap;
/// Endpoint URL of service 'Proxy2' (change as needed)
const char *endpoint;
/// Constructor allocates soap engine context, sets default endpoint URL, and sets namespace mapping table
Proxy2() { soap = soap_new(); if (soap) soap->namespaces = ns2_namespaces; endpoint = "http://10.1.1.100/Proxy2"; };
/// Destructor frees deserialized data and soap engine context
virtual ~Proxy2() { if (soap) { soap_destroy(soap); soap_end(soap); soap_free(soap); } };
/// Invoke 'remoteMethod' of service 'Proxy2' and return error code (or SOAP_OK)
virtual int __ns2__remoteMethod(ns2__remoteMethod *ns2__remoteMethod_, ns2__remoteMethodResponse *ns2__remoteMethodResponse_) { return soap ? soap_call___ns2__remoteMethod(soap, endpoint, NULL, ns2__remoteMethod_, ns2__remoteMethodResponse_) : SOAP_EOM; };
};
} // namespace ns2
...
They are used in two separated threads. With every call of a remote method, a Proxy1/Proxy2 object is created and destroyed, e.g. Proxy1:
...
ns1::Proxy1 p1;
ns1::ns1__remoteMethod i1;
ns1::ns1__remoteMethodResponse o1;
if ( p1.__ns1__remoteMethod( &i1, &o1 ) != SOAP_OK )
...
So they do not use the same soap context.
I am afraid, that I can not give you some compilable code to reproduce the problem (yet), because it is very timing dependent and I have not managed to reproduce the problem in another environment.
But maybe, you have a hint for me, where to start searching problems with the socket implementation?

Thank you
Markus

[Robert van Engelen]

Did you try tcpdump to trace the TCP traffic and see what caused it? It maybe caused by the TCP layer, and not in gSOAP.

[SourceForge Robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).