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 calls.
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):
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.