axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando (JIRA)" <>
Subject [jira] Commented: (AXIS2C-1001) Axis2/C Stress tests fail
Date Thu, 26 Jun 2008 07:34:45 GMT


Senaka Fernando commented on AXIS2C-1001:

Hi Frank,

Yes, I think the timeout interval will not solve your issue. I'm sorry for misinterpreting
the cause sometime back. Milinda is working on this issue.


> Axis2/C Stress tests fail
> -------------------------
>                 Key: AXIS2C-1001
>                 URL:
>             Project: Axis2-C
>          Issue Type: Bug
>         Environment: Using an Axis2/C snapshot from 7/2/2008 compiled with Guththila
enabled (due to problems with libxml)
>            Reporter: Frank Huebbers
>            Assignee: Milinda Lakmal Pathirage
> I am using Axis2/C in an application which uses asynchronous web service calls heavily.
In this application, it can happen that several web service calls are issued one after another.
In my tests, however, I have noticed that this almost always causes problems with Axis.
> I was able to narrow down the problem to the following test cases:
> 1. Fire several non-blocking web service calls right after each other (without waiting
for a response). 
>    ==> Always causes failure on the second call
> 2. Fire 100 web service calls one after the other (i.e., fire one, wait for response,
fire next)
>   ==> Causes failure randomly
> Now, it's important to note that I am reusing the axis environment and stub for these
> In my next series of tests, I repeated the two set-ups above. Instead of reusing the
stub for each call, however, I created a new stub for each call. In my test, this allowed
me to pass the two tests above. However, in this set of tests I did not clean up the stubs,
 which, of course, creates an unacceptable memory leak.
> So, the next series of tests included cleaning up the stub right at the end of the on_complete/on_failure
callbacks. This, however,  caused crashes in the axutil library. Specifically, the line of
code which caused the crash was (in op_client.c):
> axis2_async_result_free(args_list->op_client->async_result, th_env);
> With further investigation I was able to figure out that this caused an error because
in the deletion of the stub (which in my test above would happen before the async_result_free
above would execute) the op_client variable was freed.
> So, in my final set of tests, I created a stub resource manager which, essentially, frees
the stubs in a time delayed fashion. This would allow the thread to complete the on_complete/on_failure
callback and clean up after itself and then do a freeing of the stub. This seems to work very
reliable for me, but, as I understand it, is not the most efficient way of doing things as
I am required to create a new stub for every web service call.
> So, I was wondering if these scenarios are tested in the Axis2/C regression tests and/or
if I can do something else to get my test cases working.
> Frank

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