[
https://issues.apache.org/jira/browse/AXIS2C-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551533
]
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: https://issues.apache.org/jira/browse/AXIS2C-830
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
