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 "Frank Huebbers (JIRA)" <ji...@apache.org> on 2008/02/20 20:23:43 UTC
[jira] Created: (AXIS2C-1001) Axis2/C Stress tests fail
Axis2/C Stress tests fail
-------------------------
Key: AXIS2C-1001
URL: https://issues.apache.org/jira/browse/AXIS2C-1001
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
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):
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-1001) Axis2/C Stress tests fail
Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608311#action_12608311 ]
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.
Regards,
Senaka
> Axis2/C Stress tests fail
> -------------------------
>
> Key: AXIS2C-1001
> URL: https://issues.apache.org/jira/browse/AXIS2C-1001
> 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 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):
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Assigned: (AXIS2C-1001) Axis2/C Stress tests fail
Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Senaka Fernando reassigned AXIS2C-1001:
---------------------------------------
Assignee: Senaka Fernando
> Axis2/C Stress tests fail
> -------------------------
>
> Key: AXIS2C-1001
> URL: https://issues.apache.org/jira/browse/AXIS2C-1001
> 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: Senaka Fernando
>
> 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):
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-1001) Axis2/C Stress tests fail
Posted by "Frank Huebbers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574011#action_12574011 ]
Frank Huebbers commented on AXIS2C-1001:
----------------------------------------
Hi Senaka,
I'm glad to hear to that Axis2/c now supports a timeout interval. I do not believe, however, that this will solve my issue due to the following observation:
1. The problem I am seeing seems to stem from a race condition between cleanup after a service call and making the next service call.
2. The timeout (and correct me if I'm wrong), handles the case of not receiving a response within a specified period of time.
Thoughts?
Frank
> Axis2/C Stress tests fail
> -------------------------
>
> Key: AXIS2C-1001
> URL: https://issues.apache.org/jira/browse/AXIS2C-1001
> 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: Senaka Fernando
>
> 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):
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Updated: (AXIS2C-1001) Axis2/C Stress tests fail
Posted by "S.Uthaiyashankar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
S.Uthaiyashankar updated AXIS2C-1001:
-------------------------------------
Component/s: tests
> Axis2/C Stress tests fail
> -------------------------
>
> Key: AXIS2C-1001
> URL: https://issues.apache.org/jira/browse/AXIS2C-1001
> Project: Axis2-C
> Issue Type: Bug
> Components: tests
> 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 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):
> 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.
[jira] Commented: (AXIS2C-1001) Axis2/C Stress tests fail
Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570809#action_12570809 ]
Senaka Fernando commented on AXIS2C-1001:
-----------------------------------------
Hi Frank,
No. 1, will fail of course as one service client can only handle one async call at a time. No. 2, should not fail unless otherwise there was a delay in cleaning up resources, which did not free the socket bound to the port on time. But, this should eventually catch up. You can setup a timeout in milli seconds, and run, so that failures would be minimal. Please note that there are a few bugs in this timeout in milli seconds option which we are looking forward to fix before the end of this week.
No, I believe you can't cleanup the stub inside the callback but inside the thread that created the stub by waiting inside a loop as in the echo_non_blocking samples.
I strongly believe that you need not create a stub per call. And, that is guranteed not to fail once the timeout in milli seconds option will be fully functional, hopefully.
I believe that the ability to send multiple async requests from the same service client needs some discussion on the dev list.
Regards,
Senaka
> Axis2/C Stress tests fail
> -------------------------
>
> Key: AXIS2C-1001
> URL: https://issues.apache.org/jira/browse/AXIS2C-1001
> 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
>
> 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):
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Assigned: (AXIS2C-1001) Axis2/C Stress tests fail
Posted by "Milinda Lakmal Pathirage (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Milinda Lakmal Pathirage reassigned AXIS2C-1001:
------------------------------------------------
Assignee: Milinda Lakmal Pathirage (was: Senaka Fernando)
> Axis2/C Stress tests fail
> -------------------------
>
> Key: AXIS2C-1001
> URL: https://issues.apache.org/jira/browse/AXIS2C-1001
> 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 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):
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
[jira] Commented: (AXIS2C-1001) Axis2/C Stress tests fail
Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2C-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571758#action_12571758 ]
Senaka Fernando commented on AXIS2C-1001:
-----------------------------------------
Hi Frank,
Now you are capable of setting the timeout for which the service client should wait until it receives a response. Please try your stress tests for blocking calls with the option, axis2_options_set_timeout_in_milli_seconds().
Regards,
Senaka
> Axis2/C Stress tests fail
> -------------------------
>
> Key: AXIS2C-1001
> URL: https://issues.apache.org/jira/browse/AXIS2C-1001
> 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: Senaka Fernando
>
> 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):
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org