axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Mitchell (JIRA)" <>
Subject [jira] Commented: (AXIS2C-830) libcurl interface not multithreaded
Date Thu, 13 Dec 2007 15:18:43 GMT


Bill Mitchell commented on AXIS2C-830:

Good observations, Senaka, and thank you for asking.  I had a second motive in making the
curl structure persist at the level of the http_transport_sender.  For my project, I need
to interoperate with a SOAP service that uses HTTP cookies to maintain the session.  libcurl
already implements cookie support that will persist for the duration of the handle.  So to
make this work for SOAP clients, the handle needs to persist as long as the service client,
thus, at the level of the http_transport_sender.  (I am still working on this change, as it
is easy to enable cookies in axis2_libcurl, and I can see how my client application can invoke
set_manage_sessions on an options structure, but making the enabling of cookies depend on
the manage_sessions options is a trick I've not yet solved.  I would welcome suggestions.)
 Bottom line, it is critical for my project that the handle be owned by the transport_sender.

This is not all bad, as the curl documentation mentions that the handler structure must exist
as long as curl might invoke any of the callbacks, or access the error buffer area.  I was
worried until I saw that the axis2_http_transport_sender already had conditional compilation
for the libcurl case, so this change does not expand the set of modules that contain libcurl
specific information.  

Regarding the global init, the libcurl documentation on the curl_easy_init() function says
that you should not depend on its curl_global_init() call as it is not thread-safe and so
not dependable in a multi-threaded application.  So it seems to me best to make this invocation
explicit at the higher level in Axis2c itself, in the hope that we can find a way for Axis
to invoke this at a level that is thread-safe by design or is made thread-safe under a mutex.

> libcurl interface not multithreaded
> -----------------------------------
>                 Key: AXIS2C-830
>                 URL:
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: transport/http
>    Affects Versions: 1.1.0
>         Environment: Windows XP, Visual Studio 2005, build uses libcurl and guththila
>            Reporter: Bill Mitchell
>         Attachments: libcurl_diff
> Axis2C support of libcurl is not multithreaded, i.e., it cannot be invoked by a multithreaded
client application.  This despite the fact that libcurl is multithreaded and Axis2C is multithreaded.
 The crux of the issue lies in the static global definition of the curl handler in axis2_libcurl.c.
 This prevents multiple client threads from obtaining multiple connections to issue concurrent
SOAP operations.  

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message