You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Bill Mitchell (JIRA)" <ji...@apache.org> on 2007/12/12 20:59:45 UTC

[jira] Created: (AXIS2C-830) libcurl interface not multithreaded

libcurl interface not multithreaded
-----------------------------------

                 Key: AXIS2C-830
                 URL: https://issues.apache.org/jira/browse/AXIS2C-830
             Project: Axis2-C
          Issue Type: Bug
    Affects Versions: 1.1.0
         Environment: Windows XP, Visual Studio 2005, build uses libcurl and guththila
            Reporter: Bill Mitchell


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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


[jira] Commented: (AXIS2C-830) libcurl interface not multithreaded

Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AXIS2C-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551467 ] 

Senaka Fernando commented on AXIS2C-830:
----------------------------------------

Hi Bill,

I read through your diff. And, also src/core/transport/http/sender/libcurl/axis2_libcurl.c. It seems that the curl handle is used only within the axis2_libcurl_send() method. ***Am I making a mistake here?*** Thus, instead of being a static definition you simply can make it a local variable inside the method call.

Also, curl_global_init() is not required if you wont call curl_global_cleanup(). curl_easy_init() will do it for you[1]. And, even this could be a leak in terms of a leak-detector; since, curl's global resources need to be persistent throughout the program's life, it would not rather be a leak in reality.

However, the leak inside axis2_libcurl_write_memory_callback() needs a fix (+1) I guess, and I believe you have remedied the issue.

References:
[1]http://curl.rtin.bz/libcurl/c/libcurl.html

Regards,
Senaka

> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


[jira] Resolved: (AXIS2C-830) libcurl interface not multithreaded

Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2C-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Mitchell resolved AXIS2C-830.
----------------------------------

       Resolution: Fixed
    Fix Version/s: Current (Nightly)

This fix to this problem has been incorporated in svn revision 617668.

> 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
>             Fix For: Current (Nightly)
>
>         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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


[jira] Updated: (AXIS2C-830) libcurl interface not multithreaded

Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2C-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Mitchell updated AXIS2C-830:
---------------------------------

    Attachment:     (was: libcurl_diff)

> 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
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


[jira] Updated: (AXIS2C-830) libcurl interface not multithreaded

Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2C-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Mitchell updated AXIS2C-830:
---------------------------------

    Attachment: libcurl_diff

In further testing, I discovered that the first fix I passed on inadvertently introduced a bug in the read path.  The free of the axis2_libcurl structure on each operation was what indirectly reset read back to the start of the buffer.  Making the axis2_libcurl structure persist caused the read buffer to persist but never be reset to the start, so subsequent reads were appended after the contents of the first message read.  I have now fixed this problem.  

In fixing the read path, I discovered that the free of the axis2_libcurl structure in the original code contained a memory leak in that it never freed the read buffer, so a buffer was lost after each message received.  I have now fixed this pre-existing problem, as well as a leak of an array_list structure allocated as part of the axis2_libcurl structure.  

All these fixes are contained in the replacement diff file I have attached.  

> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


[jira] Updated: (AXIS2C-830) libcurl interface not multithreaded

Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2C-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Mitchell updated AXIS2C-830:
---------------------------------

    Component/s: transport/http

> 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
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


[jira] Updated: (AXIS2C-830) libcurl interface not multithreaded

Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2C-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Mitchell updated AXIS2C-830:
---------------------------------

    Attachment: libcurl_diff

The attached diff file contains the changes to axis2_http_transport_sender.c, axis2_http_sender.c & .h, and axis2_libcurl.c & .h to maintain the curl handle in the axis2_libcurl structure and to make the axis2_libcurl structure be owned by the axis2_http_transport_sender structure.  This allows the curl handle to be persistent for the life of the client service.  

While working on this change, I came across a memory leak in the axis2_libcurl_write_memory_callback().  When it expands the size of the buffer by reallocating it, the old instance of the buffer is not freed.  This oversight is remedied in the attached source changes.  

I have verified this change by running multiple, e.g., 4, concurrent client threads each performing SOAP exchanges to a set of SOAP services.  

> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


[jira] Commented: (AXIS2C-830) libcurl interface not multithreaded

Posted by "Bill Mitchell (JIRA)" <ji...@apache.org>.
    [ 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org