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 Clifford THOMPSON <ct...@mdacorporation.com> on 2008/02/18 19:37:07 UTC
FW: Question regarding the adjustment of response timeouts
Hello Dev Team,
I presented this question with regards to using timeouts in the
axis2-c-user forum. Dimuthu is getting similar results under Linux, and
suggested that there may be a bug in timeout behaviour. Please see below
for the details.
Cheers,
Cliff
-----Original Message-----
From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
Sent: February 16, 2008 05:23
To: Apache AXIS C User List
Subject: Re: [AXIS2C] Question regarding the adjustment of response
timeouts
Hi,
I too checked it in Linux and got the same result,
Seems we are not using axis2_options_get_timeout_in_milli_seconds
anywhere.. If this is a bug, should be fixed before the 1.3 release.
Thanks
Dimuthu
On Feb 16, 2008 1:07 AM, Clifford THOMPSON
<cl...@mdacorporation.com> wrote:
>
>
> Hello,
>
> I have a question about adjusting the timeout period for web services.
> Our current software dictates that we can have upwards of a 300 second
> delay before a response is sent (we have a large amount of data that
> needs to be prepared before being sent). Currently, our web service
> component will timeout after roughly 60 sec (I'm not sure if this is
> the Axis API, or from the OS). I have tried using some of the timeout
> functions in the Axis2C API, but they appear to have no effect (if I
> set the timeout 5 secs and the server takes 10 secs to respond, the
> client will wait 10 secs for the response). I am assuming that I am
> using the API incorrectly. We are working under WinXP, and have
generate portions of our code using the WSDL2C tool.
> We have chosen to generate synchronous code using WSDL2C (so the
> eventual call in the generate code will be to
> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
> paraphrase of the code that we have and how I thought the timeout
> function should be
> applied:
>
> env = axutil_env_create_all( "MyServiceLog.log",
> AXIS2_LOG_LEVEL_TRACE);
> assert(NULL != env);
>
> stub = axis2_stub_create_MyService( env,
> AXIS2_GETENV("AXIS2C_HOME"),
>
> "http://myserver.ca:8080/services/MyService");
> assert(NULL != stub);
>
>
> status = axis2_options_set_timeout_in_milli_seconds(
> axis2_stub_get_options( stub,
> env ),
> env,
> 300000);
> assert(AXIS2_SUCCESS == status);
>
> /* */
> /* lots of interleaving non-Axis2C code */
> /* */
>
> responseNode = axis2_stub_op_MyService_MyOperation(
> stub,
> env,
> headerNode1,
> headerNode2,
> bodyNode);
> if(NULL !=)
> {
> /* process the response */
> }
> else
> {
> /* log the response error */
> }
>
> Thank you in advance for the help.
>
> Cheers,
> Cliff
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: FW: Question regarding the adjustment of response timeouts
Posted by Senaka Fernando <se...@wso2.com>.
Hi Cliff,
Well that's not at all an issue. Actually it was Samisa who fixed it.
Yeah, debugging teaches you alot.
Regards,
Senaka
> Hello Senaka,
>
> Thanks for tracking down this bug. Sorry for giving the impression of
> impatience. I was using the debugging as an opportunity to learn more
> about the Axis2C code base ;P
>
> Cheers,
> Cliff
>
> -----Original Message-----
> From: Senaka Fernando [mailto:senaka@wso2.com]
> Sent: February 22, 2008 21:43
> To: Apache AXIS C Developers List
> Subject: RE: FW: Question regarding the adjustment of response timeouts
>
> Hi Cliff,
>
> I did track this code block. Will fix it before the end of the day.
> Sorry to have you waiting for the fix.
>
> Regards,
> Senaka
>
>>
>> Hello,
>>
>> I made a mistake in my last message. Please see my inline comment for
>> the correction
>>
>> Cheers,
>> Cliff
>>
>> -----Original Message-----
>> From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
>> Sent: February 22, 2008 15:08
>> To: Apache AXIS C Developers List
>> Subject: RE: FW: Question regarding the adjustment of response
>> timeouts
>>
>>> Hello Samisa,
>>>
>>> I have been doing some tracing, and hopefully I've found some
>> information that may be useful. I have traced through my blocking
>> service call:
>>>
>>> + axis2_stub_op_MyService_MyOperation
>>> + axis2_svc_client_send_receive_with_op_name
>>> + axis2_op_client_execute
>>> + axis2_op_client_two_way_send
>>>
>>> It appears that the call to "axis2_msg_ctx_get_property" returns
> NULL:
>>>
>>> <code>
>>> AXIS2_EXTERN axis2_msg_ctx_t *AXIS2_CALL
>>> axis2_op_client_two_way_send(
>>> const axutil_env_t * env,
>>> axis2_msg_ctx_t * msg_ctx)
>>> {
>>> axis2_engine_t *engine = NULL;
>>> axis2_status_t status = AXIS2_SUCCESS;
>>> axis2_msg_ctx_t *response = NULL;
>>> axis2_conf_ctx_t *conf_ctx = NULL;
>>> axis2_op_t *op = NULL;
>>> axiom_soap_envelope_t *response_envelope = NULL;
>>> axutil_property_t *property = NULL;
>>> long index = -1;
>>> axis2_bool_t wait_indefinitely = AXIS2_FALSE;
>>>
>>> AXIS2_ENV_CHECK(env, NULL);
>>>
>>> conf_ctx = axis2_msg_ctx_get_conf_ctx(msg_ctx, env);
>>> engine = axis2_engine_create(env, conf_ctx);
>>> if (!engine)
>>> return NULL;
>>> property > axis2_msg_ctx_get_property(msg_ctx,
> env,
>> AXIS2_TIMEOUT_IN_SECONDS); </code>
>>>
>>> And thus the next section of code never picks up the timeout value
>> since we never find the "property" for the timeout:
>>>
>>> <code>
>>> if (property)
>>> {
>>> axis2_char_t *value = axutil_property_get_value(property,
>>> env);
>>> if (value)
>>> index = AXIS2_ATOI(value);
>>> if (index == -1)
>>> {
>>> wait_indefinitely = AXIS2_TRUE;
>>> index = 1;
>>> }
>>> }
>>> </code>
>>>
>>> which is used later in the function:
>>>
>>> <code>
>>> else
>>> {
>>> while (!response_envelope && index > 0)
>>> {
>>> /*wait till the response arrives */
>>> AXIS2_SLEEP(1);
>>> if (!wait_indefinitely)
>>> index--;
>>> response_envelope >
>>> axis2_msg_ctx_get_response_soap_envelope(msg_ctx,
>>> env);
>>> }
>>> </code>
>>>
>>> You guys are much more familiar which the code base, so does the call
>> to "axis2_op_client_get_msg_ctx" copy the timeout information from the
>
>> >
>>> > "options" member of "op_client" into "msg_ctx" (the variable that
>>> > is
>> eventually passed to "axis2_msg_ctx_get_property"):
>>
>> I meant the call to "axis2_msg_ctx_set_options" not
>> "axis2_op_client_get_msg_ctx", please see the additional code in the
>> snippet below:
>>
>>>
>>> <code>
>>> AXIS2_EXTERN axis2_status_t AXIS2_CALL
>>> axis2_op_client_execute(
>>> axis2_op_client_t * op_client,
>>> const axutil_env_t * env,
>>> const axis2_bool_t block)
>>> {
>>> axis2_conf_ctx_t *conf_ctx = NULL;
>>> axis2_msg_ctx_t *msg_ctx = NULL;
>>>
>>> axis2_transport_out_desc_t *transport_out = NULL;
>>> axis2_transport_in_desc_t *transport_in = NULL;
>>>
>>> axis2_status_t status = AXIS2_FAILURE;
>>> axis2_op_t *op = NULL;
>>> axis2_char_t *msg_id = NULL;
>>>
>>> AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
>>>
>>> if (op_client->completed)
>>> {
>>> return AXIS2_FAILURE;
>>> }
>>>
>>> conf_ctx = axis2_svc_ctx_get_conf_ctx(op_client->svc_ctx,
>> env);
>>>
>>> msg_ctx = (axis2_msg_ctx_t *)
>>> axis2_op_client_get_msg_ctx(op_client, env,
>>>
>>> AXIS2_WSDL_MESSAGE_LABEL_OUT);
>>> </code>
>>
>> <code>
>> if (!msg_ctx)
>> {
>> return AXIS2_FAILURE;
>> }
>>
>> axis2_msg_ctx_set_options(msg_ctx, env, op_client->options);
>> </code>
>>
>>>
>>>
>>> When I traced through the call to "axis2_msg_ctx_get_property", all
>>> of
>> the hash tables stored within "msg_ctx" or its children appear to be >
>
>> >
>>> empty. I am not sure if this is correct or not, but I hope this all
>> helps out with the bug tracking.
>>>
>>> Cheers,
>>> Cliff
>>>
>>> -----Original Message-----
>>> From: Samisa Abeysinghe [mailto:samisa@wso2.com]
>>> Sent: February 20, 2008 18:06
>>> To: Apache AXIS C Developers List
>>> Subject: Re: FW: Question regarding the adjustment of response
>> timeouts
>>>
>>> The current problem is that, for the normal non blocking case, the
>> implementation does not pick the user option and set it on the socket.
>>>
>>> I hope the fix is straight forward.
>>>
>>> Regards,
>>> Samisa...
>>>
>>> Clifford THOMPSON wrote:
>>> > I meant 60000ms...
>>> >
>>> > -----Original Message-----
>>> > From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
>>> > Sent: February 20, 2008 13:40
>>> > To: Apache AXIS C Developers List
>>> > Subject: RE: FW: Question regarding the adjustment of response
>>> > timeouts
>>> >
>>> > Hello Senaka,
>>> >
>>> > I took a look at "axis2_http_transport.h" and noticed that the
>>> > constants, AXIS2_HTTP_DEFAULT_SO_TIMEOUT and
>>> > AXIS2_HTTP_DEFAULT_CONNECTION_TIMEOUT, both held values of 6000ms.
>>> > This coincides with the upper timeout limit our team was
>> experiencing,
>>>
>>> > so it may provide a clue to the timeout problem.
>>> >
>>> > Cheers,
>>> > Cliff
>>> >
>>> > -----Original Message-----
>>> > From: Senaka Fernando [mailto:senaka@wso2.com]
>>> > Sent: February 18, 2008 11:35
>>> > To: Apache AXIS C Developers List
>>> > Subject: Re: FW: Question regarding the adjustment of response
>>> > timeouts
>>> >
>>> > Hi Cliff,
>>> >
>>> > We'll look into this before the 1.3.0 release and try to have it
>> fixed
>>>
>>> > before we release.
>>> >
>>> > Regards,
>>> > Senaka
>>> >
>>> >
>>> >> Hello Dev Team,
>>> >>
>>> >> I presented this question with regards to using timeouts in the
>>> >> axis2-c-user forum. Dimuthu is getting similar results under
>>> >> Linux,
>>
>>> >> and suggested that there may be a bug in timeout behaviour. Please
>
>>> >> see
>>> >>
>>> >
>>> >
>>> >> below for the details.
>>> >>
>>> >> Cheers,
>>> >> Cliff
>>> >>
>>> >> -----Original Message-----
>>> >> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
>>> >> Sent: February 16, 2008 05:23
>>> >> To: Apache AXIS C User List
>>> >> Subject: Re: [AXIS2C] Question regarding the adjustment of
>>> >> response
>>
>>> >> timeouts
>>> >>
>>> >> Hi,
>>> >>
>>> >> I too checked it in Linux and got the same result,
>>> >>
>>> >> Seems we are not using axis2_options_get_timeout_in_milli_seconds
>>> >> anywhere.. If this is a bug, should be fixed before the 1.3
>> release.
>>> >>
>>> >> Thanks
>>> >> Dimuthu
>>> >>
>>> >> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
>>> >> <cl...@mdacorporation.com> wrote:
>>> >>
>>> >>> Hello,
>>> >>>
>>> >>> I have a question about adjusting the timeout period for web
>>> >>>
>>> > services.
>>> >
>>> >>> Our current software dictates that we can have upwards of a 300
>>> >>> second
>>> >>>
>>> >>> delay before a response is sent (we have a large amount of data
>> that
>>>
>>> >>> needs to be prepared before being sent). Currently, our web
>> service
>>> >>> component will timeout after roughly 60 sec (I'm not sure if this
>> is
>>>
>>> >>> the Axis API, or from the OS). I have tried using some of the
>>> >>> timeout
>>> >>>
>>> >
>>> >
>>> >>> functions in the Axis2C API, but they appear to have no effect
>>> >>> (if
>> I
>>>
>>> >>> set the timeout 5 secs and the server takes 10 secs to respond,
>> the
>>> >>> client will wait 10 secs for the response). I am assuming that I
>> am
>>> >>> using the API incorrectly. We are working under WinXP, and have
>>> >>>
>>> >> generate portions of our code using the WSDL2C tool.
>>> >>
>>> >>> We have chosen to generate synchronous code using WSDL2C (so the
>>> >>> eventual call in the generate code will be to
>>> >>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>>> >>> paraphrase of the code that we have and how I thought the timeout
>
>>> >>> function should be
>>> >>> applied:
>>> >>>
>>> >>> env = axutil_env_create_all( "MyServiceLog.log",
>>> >>> AXIS2_LOG_LEVEL_TRACE);
>>> >>> assert(NULL != env);
>>> >>>
>>> >>> stub = axis2_stub_create_MyService( env,
>>> >>>
>> AXIS2_GETENV("AXIS2C_HOME"),
>>> >>>
>>> >>> "http://myserver.ca:8080/services/MyService");
>>> >>> assert(NULL != stub);
>>> >>>
>>> >>>
>>> >>> status = axis2_options_set_timeout_in_milli_seconds(
>>> >>> axis2_stub_get_options( stub,
>>> >>> env ),
>>> >>> env,
>>> >>> 300000);
>>> >>> assert(AXIS2_SUCCESS == status);
>>> >>>
>>> >>> /* */
>>> >>> /* lots of interleaving non-Axis2C code */
>>> >>> /* */
>>> >>>
>>> >>> responseNode = axis2_stub_op_MyService_MyOperation(
>>> >>> stub,
>>> >>> env,
>>> >>> headerNode1,
>>> >>> headerNode2,
>>> >>> bodyNode);
>>> >>> if(NULL !=)
>>> >>> {
>>> >>> /* process the response */
>>> >>> }
>>> >>> else
>>> >>> {
>>> >>> /* log the response error */
>>> >>> }
>>> >>>
>>> >>> Thank you in advance for the help.
>>> >>>
>>> >>> Cheers,
>>> >>> Cliff
>>> >>>
>>> >>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: FW: Question regarding the adjustment of response timeouts
Posted by Clifford THOMPSON <ct...@mdacorporation.com>.
Hello Senaka,
Thanks for tracking down this bug. Sorry for giving the impression of
impatience. I was using the debugging as an opportunity to learn more
about the Axis2C code base ;P
Cheers,
Cliff
-----Original Message-----
From: Senaka Fernando [mailto:senaka@wso2.com]
Sent: February 22, 2008 21:43
To: Apache AXIS C Developers List
Subject: RE: FW: Question regarding the adjustment of response timeouts
Hi Cliff,
I did track this code block. Will fix it before the end of the day.
Sorry to have you waiting for the fix.
Regards,
Senaka
>
> Hello,
>
> I made a mistake in my last message. Please see my inline comment for
> the correction
>
> Cheers,
> Cliff
>
> -----Original Message-----
> From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
> Sent: February 22, 2008 15:08
> To: Apache AXIS C Developers List
> Subject: RE: FW: Question regarding the adjustment of response
> timeouts
>
>> Hello Samisa,
>>
>> I have been doing some tracing, and hopefully I've found some
> information that may be useful. I have traced through my blocking
> service call:
>>
>> + axis2_stub_op_MyService_MyOperation
>> + axis2_svc_client_send_receive_with_op_name
>> + axis2_op_client_execute
>> + axis2_op_client_two_way_send
>>
>> It appears that the call to "axis2_msg_ctx_get_property" returns
NULL:
>>
>> <code>
>> AXIS2_EXTERN axis2_msg_ctx_t *AXIS2_CALL
>> axis2_op_client_two_way_send(
>> const axutil_env_t * env,
>> axis2_msg_ctx_t * msg_ctx)
>> {
>> axis2_engine_t *engine = NULL;
>> axis2_status_t status = AXIS2_SUCCESS;
>> axis2_msg_ctx_t *response = NULL;
>> axis2_conf_ctx_t *conf_ctx = NULL;
>> axis2_op_t *op = NULL;
>> axiom_soap_envelope_t *response_envelope = NULL;
>> axutil_property_t *property = NULL;
>> long index = -1;
>> axis2_bool_t wait_indefinitely = AXIS2_FALSE;
>>
>> AXIS2_ENV_CHECK(env, NULL);
>>
>> conf_ctx = axis2_msg_ctx_get_conf_ctx(msg_ctx, env);
>> engine = axis2_engine_create(env, conf_ctx);
>> if (!engine)
>> return NULL;
>> property > axis2_msg_ctx_get_property(msg_ctx,
env,
> AXIS2_TIMEOUT_IN_SECONDS); </code>
>>
>> And thus the next section of code never picks up the timeout value
> since we never find the "property" for the timeout:
>>
>> <code>
>> if (property)
>> {
>> axis2_char_t *value = axutil_property_get_value(property,
>> env);
>> if (value)
>> index = AXIS2_ATOI(value);
>> if (index == -1)
>> {
>> wait_indefinitely = AXIS2_TRUE;
>> index = 1;
>> }
>> }
>> </code>
>>
>> which is used later in the function:
>>
>> <code>
>> else
>> {
>> while (!response_envelope && index > 0)
>> {
>> /*wait till the response arrives */
>> AXIS2_SLEEP(1);
>> if (!wait_indefinitely)
>> index--;
>> response_envelope >
>> axis2_msg_ctx_get_response_soap_envelope(msg_ctx,
>> env);
>> }
>> </code>
>>
>> You guys are much more familiar which the code base, so does the call
> to "axis2_op_client_get_msg_ctx" copy the timeout information from the
> >
>> > "options" member of "op_client" into "msg_ctx" (the variable that
>> > is
> eventually passed to "axis2_msg_ctx_get_property"):
>
> I meant the call to "axis2_msg_ctx_set_options" not
> "axis2_op_client_get_msg_ctx", please see the additional code in the
> snippet below:
>
>>
>> <code>
>> AXIS2_EXTERN axis2_status_t AXIS2_CALL
>> axis2_op_client_execute(
>> axis2_op_client_t * op_client,
>> const axutil_env_t * env,
>> const axis2_bool_t block)
>> {
>> axis2_conf_ctx_t *conf_ctx = NULL;
>> axis2_msg_ctx_t *msg_ctx = NULL;
>>
>> axis2_transport_out_desc_t *transport_out = NULL;
>> axis2_transport_in_desc_t *transport_in = NULL;
>>
>> axis2_status_t status = AXIS2_FAILURE;
>> axis2_op_t *op = NULL;
>> axis2_char_t *msg_id = NULL;
>>
>> AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
>>
>> if (op_client->completed)
>> {
>> return AXIS2_FAILURE;
>> }
>>
>> conf_ctx = axis2_svc_ctx_get_conf_ctx(op_client->svc_ctx,
> env);
>>
>> msg_ctx = (axis2_msg_ctx_t *)
>> axis2_op_client_get_msg_ctx(op_client, env,
>>
>> AXIS2_WSDL_MESSAGE_LABEL_OUT);
>> </code>
>
> <code>
> if (!msg_ctx)
> {
> return AXIS2_FAILURE;
> }
>
> axis2_msg_ctx_set_options(msg_ctx, env, op_client->options);
> </code>
>
>>
>>
>> When I traced through the call to "axis2_msg_ctx_get_property", all
>> of
> the hash tables stored within "msg_ctx" or its children appear to be >
> >
>> empty. I am not sure if this is correct or not, but I hope this all
> helps out with the bug tracking.
>>
>> Cheers,
>> Cliff
>>
>> -----Original Message-----
>> From: Samisa Abeysinghe [mailto:samisa@wso2.com]
>> Sent: February 20, 2008 18:06
>> To: Apache AXIS C Developers List
>> Subject: Re: FW: Question regarding the adjustment of response
> timeouts
>>
>> The current problem is that, for the normal non blocking case, the
> implementation does not pick the user option and set it on the socket.
>>
>> I hope the fix is straight forward.
>>
>> Regards,
>> Samisa...
>>
>> Clifford THOMPSON wrote:
>> > I meant 60000ms...
>> >
>> > -----Original Message-----
>> > From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
>> > Sent: February 20, 2008 13:40
>> > To: Apache AXIS C Developers List
>> > Subject: RE: FW: Question regarding the adjustment of response
>> > timeouts
>> >
>> > Hello Senaka,
>> >
>> > I took a look at "axis2_http_transport.h" and noticed that the
>> > constants, AXIS2_HTTP_DEFAULT_SO_TIMEOUT and
>> > AXIS2_HTTP_DEFAULT_CONNECTION_TIMEOUT, both held values of 6000ms.
>> > This coincides with the upper timeout limit our team was
> experiencing,
>>
>> > so it may provide a clue to the timeout problem.
>> >
>> > Cheers,
>> > Cliff
>> >
>> > -----Original Message-----
>> > From: Senaka Fernando [mailto:senaka@wso2.com]
>> > Sent: February 18, 2008 11:35
>> > To: Apache AXIS C Developers List
>> > Subject: Re: FW: Question regarding the adjustment of response
>> > timeouts
>> >
>> > Hi Cliff,
>> >
>> > We'll look into this before the 1.3.0 release and try to have it
> fixed
>>
>> > before we release.
>> >
>> > Regards,
>> > Senaka
>> >
>> >
>> >> Hello Dev Team,
>> >>
>> >> I presented this question with regards to using timeouts in the
>> >> axis2-c-user forum. Dimuthu is getting similar results under
>> >> Linux,
>
>> >> and suggested that there may be a bug in timeout behaviour. Please
>> >> see
>> >>
>> >
>> >
>> >> below for the details.
>> >>
>> >> Cheers,
>> >> Cliff
>> >>
>> >> -----Original Message-----
>> >> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
>> >> Sent: February 16, 2008 05:23
>> >> To: Apache AXIS C User List
>> >> Subject: Re: [AXIS2C] Question regarding the adjustment of
>> >> response
>
>> >> timeouts
>> >>
>> >> Hi,
>> >>
>> >> I too checked it in Linux and got the same result,
>> >>
>> >> Seems we are not using axis2_options_get_timeout_in_milli_seconds
>> >> anywhere.. If this is a bug, should be fixed before the 1.3
> release.
>> >>
>> >> Thanks
>> >> Dimuthu
>> >>
>> >> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
>> >> <cl...@mdacorporation.com> wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>> I have a question about adjusting the timeout period for web
>> >>>
>> > services.
>> >
>> >>> Our current software dictates that we can have upwards of a 300
>> >>> second
>> >>>
>> >>> delay before a response is sent (we have a large amount of data
> that
>>
>> >>> needs to be prepared before being sent). Currently, our web
> service
>> >>> component will timeout after roughly 60 sec (I'm not sure if this
> is
>>
>> >>> the Axis API, or from the OS). I have tried using some of the
>> >>> timeout
>> >>>
>> >
>> >
>> >>> functions in the Axis2C API, but they appear to have no effect
>> >>> (if
> I
>>
>> >>> set the timeout 5 secs and the server takes 10 secs to respond,
> the
>> >>> client will wait 10 secs for the response). I am assuming that I
> am
>> >>> using the API incorrectly. We are working under WinXP, and have
>> >>>
>> >> generate portions of our code using the WSDL2C tool.
>> >>
>> >>> We have chosen to generate synchronous code using WSDL2C (so the
>> >>> eventual call in the generate code will be to
>> >>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>> >>> paraphrase of the code that we have and how I thought the timeout
>> >>> function should be
>> >>> applied:
>> >>>
>> >>> env = axutil_env_create_all( "MyServiceLog.log",
>> >>> AXIS2_LOG_LEVEL_TRACE);
>> >>> assert(NULL != env);
>> >>>
>> >>> stub = axis2_stub_create_MyService( env,
>> >>>
> AXIS2_GETENV("AXIS2C_HOME"),
>> >>>
>> >>> "http://myserver.ca:8080/services/MyService");
>> >>> assert(NULL != stub);
>> >>>
>> >>>
>> >>> status = axis2_options_set_timeout_in_milli_seconds(
>> >>> axis2_stub_get_options( stub,
>> >>> env ),
>> >>> env,
>> >>> 300000);
>> >>> assert(AXIS2_SUCCESS == status);
>> >>>
>> >>> /* */
>> >>> /* lots of interleaving non-Axis2C code */
>> >>> /* */
>> >>>
>> >>> responseNode = axis2_stub_op_MyService_MyOperation(
>> >>> stub,
>> >>> env,
>> >>> headerNode1,
>> >>> headerNode2,
>> >>> bodyNode);
>> >>> if(NULL !=)
>> >>> {
>> >>> /* process the response */
>> >>> }
>> >>> else
>> >>> {
>> >>> /* log the response error */
>> >>> }
>> >>>
>> >>> Thank you in advance for the help.
>> >>>
>> >>> Cheers,
>> >>> Cliff
>> >>>
>> >>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: FW: Question regarding the adjustment of response timeouts
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Senaka Fernando wrote:
> Hi Cliff,
>
> I did track this code block. Will fix it before the end of the day. Sorry
> to have you waiting for the fix.
>
I have fixed it.
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: FW: Question regarding the adjustment of response timeouts
Posted by Senaka Fernando <se...@wso2.com>.
Hi Cliff,
I did track this code block. Will fix it before the end of the day. Sorry
to have you waiting for the fix.
Regards,
Senaka
>
> Hello,
>
> I made a mistake in my last message. Please see my inline comment for
> the correction
>
> Cheers,
> Cliff
>
> -----Original Message-----
> From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
> Sent: February 22, 2008 15:08
> To: Apache AXIS C Developers List
> Subject: RE: FW: Question regarding the adjustment of response timeouts
>
>> Hello Samisa,
>>
>> I have been doing some tracing, and hopefully I've found some
> information that may be useful. I have traced through my blocking
> service call:
>>
>> + axis2_stub_op_MyService_MyOperation
>> + axis2_svc_client_send_receive_with_op_name
>> + axis2_op_client_execute
>> + axis2_op_client_two_way_send
>>
>> It appears that the call to "axis2_msg_ctx_get_property" returns NULL:
>>
>> <code>
>> AXIS2_EXTERN axis2_msg_ctx_t *AXIS2_CALL
>> axis2_op_client_two_way_send(
>> const axutil_env_t * env,
>> axis2_msg_ctx_t * msg_ctx)
>> {
>> axis2_engine_t *engine = NULL;
>> axis2_status_t status = AXIS2_SUCCESS;
>> axis2_msg_ctx_t *response = NULL;
>> axis2_conf_ctx_t *conf_ctx = NULL;
>> axis2_op_t *op = NULL;
>> axiom_soap_envelope_t *response_envelope = NULL;
>> axutil_property_t *property = NULL;
>> long index = -1;
>> axis2_bool_t wait_indefinitely = AXIS2_FALSE;
>>
>> AXIS2_ENV_CHECK(env, NULL);
>>
>> conf_ctx = axis2_msg_ctx_get_conf_ctx(msg_ctx, env);
>> engine = axis2_engine_create(env, conf_ctx);
>> if (!engine)
>> return NULL;
>> property > axis2_msg_ctx_get_property(msg_ctx, env,
> AXIS2_TIMEOUT_IN_SECONDS); </code>
>>
>> And thus the next section of code never picks up the timeout value
> since we never find the "property" for the timeout:
>>
>> <code>
>> if (property)
>> {
>> axis2_char_t *value = axutil_property_get_value(property,
>> env);
>> if (value)
>> index = AXIS2_ATOI(value);
>> if (index == -1)
>> {
>> wait_indefinitely = AXIS2_TRUE;
>> index = 1;
>> }
>> }
>> </code>
>>
>> which is used later in the function:
>>
>> <code>
>> else
>> {
>> while (!response_envelope && index > 0)
>> {
>> /*wait till the response arrives */
>> AXIS2_SLEEP(1);
>> if (!wait_indefinitely)
>> index--;
>> response_envelope >
>> axis2_msg_ctx_get_response_soap_envelope(msg_ctx,
>> env);
>> }
>> </code>
>>
>> You guys are much more familiar which the code base, so does the call
> to "axis2_op_client_get_msg_ctx" copy the timeout information from the >
>> > "options" member of "op_client" into "msg_ctx" (the variable that is
> eventually passed to "axis2_msg_ctx_get_property"):
>
> I meant the call to "axis2_msg_ctx_set_options" not
> "axis2_op_client_get_msg_ctx", please see the additional code in the
> snippet below:
>
>>
>> <code>
>> AXIS2_EXTERN axis2_status_t AXIS2_CALL
>> axis2_op_client_execute(
>> axis2_op_client_t * op_client,
>> const axutil_env_t * env,
>> const axis2_bool_t block)
>> {
>> axis2_conf_ctx_t *conf_ctx = NULL;
>> axis2_msg_ctx_t *msg_ctx = NULL;
>>
>> axis2_transport_out_desc_t *transport_out = NULL;
>> axis2_transport_in_desc_t *transport_in = NULL;
>>
>> axis2_status_t status = AXIS2_FAILURE;
>> axis2_op_t *op = NULL;
>> axis2_char_t *msg_id = NULL;
>>
>> AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
>>
>> if (op_client->completed)
>> {
>> return AXIS2_FAILURE;
>> }
>>
>> conf_ctx = axis2_svc_ctx_get_conf_ctx(op_client->svc_ctx,
> env);
>>
>> msg_ctx = (axis2_msg_ctx_t *)
>> axis2_op_client_get_msg_ctx(op_client, env,
>>
>> AXIS2_WSDL_MESSAGE_LABEL_OUT);
>> </code>
>
> <code>
> if (!msg_ctx)
> {
> return AXIS2_FAILURE;
> }
>
> axis2_msg_ctx_set_options(msg_ctx, env, op_client->options);
> </code>
>
>>
>>
>> When I traced through the call to "axis2_msg_ctx_get_property", all of
> the hash tables stored within "msg_ctx" or its children appear to be > >
>> empty. I am not sure if this is correct or not, but I hope this all
> helps out with the bug tracking.
>>
>> Cheers,
>> Cliff
>>
>> -----Original Message-----
>> From: Samisa Abeysinghe [mailto:samisa@wso2.com]
>> Sent: February 20, 2008 18:06
>> To: Apache AXIS C Developers List
>> Subject: Re: FW: Question regarding the adjustment of response
> timeouts
>>
>> The current problem is that, for the normal non blocking case, the
> implementation does not pick the user option and set it on the socket.
>>
>> I hope the fix is straight forward.
>>
>> Regards,
>> Samisa...
>>
>> Clifford THOMPSON wrote:
>> > I meant 60000ms...
>> >
>> > -----Original Message-----
>> > From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
>> > Sent: February 20, 2008 13:40
>> > To: Apache AXIS C Developers List
>> > Subject: RE: FW: Question regarding the adjustment of response
>> > timeouts
>> >
>> > Hello Senaka,
>> >
>> > I took a look at "axis2_http_transport.h" and noticed that the
>> > constants, AXIS2_HTTP_DEFAULT_SO_TIMEOUT and
>> > AXIS2_HTTP_DEFAULT_CONNECTION_TIMEOUT, both held values of 6000ms.
>> > This coincides with the upper timeout limit our team was
> experiencing,
>>
>> > so it may provide a clue to the timeout problem.
>> >
>> > Cheers,
>> > Cliff
>> >
>> > -----Original Message-----
>> > From: Senaka Fernando [mailto:senaka@wso2.com]
>> > Sent: February 18, 2008 11:35
>> > To: Apache AXIS C Developers List
>> > Subject: Re: FW: Question regarding the adjustment of response
>> > timeouts
>> >
>> > Hi Cliff,
>> >
>> > We'll look into this before the 1.3.0 release and try to have it
> fixed
>>
>> > before we release.
>> >
>> > Regards,
>> > Senaka
>> >
>> >
>> >> Hello Dev Team,
>> >>
>> >> I presented this question with regards to using timeouts in the
>> >> axis2-c-user forum. Dimuthu is getting similar results under Linux,
>
>> >> and suggested that there may be a bug in timeout behaviour. Please
>> >> see
>> >>
>> >
>> >
>> >> below for the details.
>> >>
>> >> Cheers,
>> >> Cliff
>> >>
>> >> -----Original Message-----
>> >> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
>> >> Sent: February 16, 2008 05:23
>> >> To: Apache AXIS C User List
>> >> Subject: Re: [AXIS2C] Question regarding the adjustment of response
>
>> >> timeouts
>> >>
>> >> Hi,
>> >>
>> >> I too checked it in Linux and got the same result,
>> >>
>> >> Seems we are not using axis2_options_get_timeout_in_milli_seconds
>> >> anywhere.. If this is a bug, should be fixed before the 1.3
> release.
>> >>
>> >> Thanks
>> >> Dimuthu
>> >>
>> >> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
>> >> <cl...@mdacorporation.com> wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>> I have a question about adjusting the timeout period for web
>> >>>
>> > services.
>> >
>> >>> Our current software dictates that we can have upwards of a 300
>> >>> second
>> >>>
>> >>> delay before a response is sent (we have a large amount of data
> that
>>
>> >>> needs to be prepared before being sent). Currently, our web
> service
>> >>> component will timeout after roughly 60 sec (I'm not sure if this
> is
>>
>> >>> the Axis API, or from the OS). I have tried using some of the
>> >>> timeout
>> >>>
>> >
>> >
>> >>> functions in the Axis2C API, but they appear to have no effect (if
> I
>>
>> >>> set the timeout 5 secs and the server takes 10 secs to respond,
> the
>> >>> client will wait 10 secs for the response). I am assuming that I
> am
>> >>> using the API incorrectly. We are working under WinXP, and have
>> >>>
>> >> generate portions of our code using the WSDL2C tool.
>> >>
>> >>> We have chosen to generate synchronous code using WSDL2C (so the
>> >>> eventual call in the generate code will be to
>> >>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>> >>> paraphrase of the code that we have and how I thought the timeout
>> >>> function should be
>> >>> applied:
>> >>>
>> >>> env = axutil_env_create_all( "MyServiceLog.log",
>> >>> AXIS2_LOG_LEVEL_TRACE);
>> >>> assert(NULL != env);
>> >>>
>> >>> stub = axis2_stub_create_MyService( env,
>> >>>
> AXIS2_GETENV("AXIS2C_HOME"),
>> >>>
>> >>> "http://myserver.ca:8080/services/MyService");
>> >>> assert(NULL != stub);
>> >>>
>> >>>
>> >>> status = axis2_options_set_timeout_in_milli_seconds(
>> >>> axis2_stub_get_options( stub,
>> >>> env ),
>> >>> env,
>> >>> 300000);
>> >>> assert(AXIS2_SUCCESS == status);
>> >>>
>> >>> /* */
>> >>> /* lots of interleaving non-Axis2C code */
>> >>> /* */
>> >>>
>> >>> responseNode = axis2_stub_op_MyService_MyOperation(
>> >>> stub,
>> >>> env,
>> >>> headerNode1,
>> >>> headerNode2,
>> >>> bodyNode);
>> >>> if(NULL !=)
>> >>> {
>> >>> /* process the response */
>> >>> }
>> >>> else
>> >>> {
>> >>> /* log the response error */
>> >>> }
>> >>>
>> >>> Thank you in advance for the help.
>> >>>
>> >>> Cheers,
>> >>> Cliff
>> >>>
>> >>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: FW: Question regarding the adjustment of response timeouts
Posted by Senaka Fernando <se...@wso2.com>.
Hi Samisa,
Thanks for the fix. Will check whether anything else needs fixing too in
this regard, within the day.
Thanks,
Senaka
> Hi Cliff,
> Thank you for your help in figuring out the cause of the problem.
> The problem was not exactly in there, but in http sender. But your
> pointers helped to locate that.
>
> I have now fixed this and tested on Windows and commited to svn
> head. 1.3 release should have it.
> Thanks,
> Samisa...
>
> Clifford THOMPSON wrote:
>> Hello,
>>
>> I made a mistake in my last message. Please see my inline comment for
>> the correction
>>
>> Cheers,
>> Cliff
>>
>> -----Original Message-----
>> From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
>> Sent: February 22, 2008 15:08
>> To: Apache AXIS C Developers List
>> Subject: RE: FW: Question regarding the adjustment of response timeouts
>>
>>
>>> Hello Samisa,
>>>
>>> I have been doing some tracing, and hopefully I've found some
>>>
>> information that may be useful. I have traced through my blocking
>> service call:
>>
>>> + axis2_stub_op_MyService_MyOperation
>>> + axis2_svc_client_send_receive_with_op_name
>>> + axis2_op_client_execute
>>> + axis2_op_client_two_way_send
>>>
>>> It appears that the call to "axis2_msg_ctx_get_property" returns NULL:
>>>
>>> <code>
>>> AXIS2_EXTERN axis2_msg_ctx_t *AXIS2_CALL
>>> axis2_op_client_two_way_send(
>>> const axutil_env_t * env,
>>> axis2_msg_ctx_t * msg_ctx)
>>> {
>>> axis2_engine_t *engine = NULL;
>>> axis2_status_t status = AXIS2_SUCCESS;
>>> axis2_msg_ctx_t *response = NULL;
>>> axis2_conf_ctx_t *conf_ctx = NULL;
>>> axis2_op_t *op = NULL;
>>> axiom_soap_envelope_t *response_envelope = NULL;
>>> axutil_property_t *property = NULL;
>>> long index = -1;
>>> axis2_bool_t wait_indefinitely = AXIS2_FALSE;
>>>
>>> AXIS2_ENV_CHECK(env, NULL);
>>>
>>> conf_ctx = axis2_msg_ctx_get_conf_ctx(msg_ctx, env);
>>> engine = axis2_engine_create(env, conf_ctx);
>>> if (!engine)
>>> return NULL;
>>> property =
>>> axis2_msg_ctx_get_property(msg_ctx, env,
>>>
>> AXIS2_TIMEOUT_IN_SECONDS); </code>
>>
>>> And thus the next section of code never picks up the timeout value
>>>
>> since we never find the "property" for the timeout:
>>
>>> <code>
>>> if (property)
>>> {
>>> axis2_char_t *value = axutil_property_get_value(property,
>>> env);
>>> if (value)
>>> index = AXIS2_ATOI(value);
>>> if (index == -1)
>>> {
>>> wait_indefinitely = AXIS2_TRUE;
>>> index = 1;
>>> }
>>> }
>>> </code>
>>>
>>> which is used later in the function:
>>>
>>> <code>
>>> else
>>> {
>>> while (!response_envelope && index > 0)
>>> {
>>> /*wait till the response arrives */
>>> AXIS2_SLEEP(1);
>>> if (!wait_indefinitely)
>>> index--;
>>> response_envelope =
>>> axis2_msg_ctx_get_response_soap_envelope(msg_ctx,
>>> env);
>>> }
>>> </code>
>>>
>>> You guys are much more familiar which the code base, so does the call
>>>
>> to "axis2_op_client_get_msg_ctx" copy the timeout information from the >
>>
>>>> "options" member of "op_client" into "msg_ctx" (the variable that is
>>>>
>> eventually passed to "axis2_msg_ctx_get_property"):
>>
>> I meant the call to "axis2_msg_ctx_set_options" not
>> "axis2_op_client_get_msg_ctx", please see the additional code in the
>> snippet below:
>>
>>
>>> <code>
>>> AXIS2_EXTERN axis2_status_t AXIS2_CALL
>>> axis2_op_client_execute(
>>> axis2_op_client_t * op_client,
>>> const axutil_env_t * env,
>>> const axis2_bool_t block)
>>> {
>>> axis2_conf_ctx_t *conf_ctx = NULL;
>>> axis2_msg_ctx_t *msg_ctx = NULL;
>>>
>>> axis2_transport_out_desc_t *transport_out = NULL;
>>> axis2_transport_in_desc_t *transport_in = NULL;
>>>
>>> axis2_status_t status = AXIS2_FAILURE;
>>> axis2_op_t *op = NULL;
>>> axis2_char_t *msg_id = NULL;
>>>
>>> AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
>>>
>>> if (op_client->completed)
>>> {
>>> return AXIS2_FAILURE;
>>> }
>>>
>>> conf_ctx = axis2_svc_ctx_get_conf_ctx(op_client->svc_ctx,
>>>
>> env);
>>
>>> msg_ctx = (axis2_msg_ctx_t *)
>>> axis2_op_client_get_msg_ctx(op_client, env,
>>>
>>> AXIS2_WSDL_MESSAGE_LABEL_OUT);
>>> </code>
>>>
>>
>> <code>
>> if (!msg_ctx)
>> {
>> return AXIS2_FAILURE;
>> }
>>
>> axis2_msg_ctx_set_options(msg_ctx, env, op_client->options);
>> </code>
>>
>>
>>> When I traced through the call to "axis2_msg_ctx_get_property", all of
>>>
>> the hash tables stored within "msg_ctx" or its children appear to be > >
>>
>>> empty. I am not sure if this is correct or not, but I hope this all
>>>
>> helps out with the bug tracking.
>>
>>> Cheers,
>>> Cliff
>>>
>>> -----Original Message-----
>>> From: Samisa Abeysinghe [mailto:samisa@wso2.com]
>>> Sent: February 20, 2008 18:06
>>> To: Apache AXIS C Developers List
>>> Subject: Re: FW: Question regarding the adjustment of response
>>>
>> timeouts
>>
>>> The current problem is that, for the normal non blocking case, the
>>>
>> implementation does not pick the user option and set it on the socket.
>>
>>> I hope the fix is straight forward.
>>>
>>> Regards,
>>> Samisa...
>>>
>>> Clifford THOMPSON wrote:
>>>
>>>> I meant 60000ms...
>>>>
>>>> -----Original Message-----
>>>> From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
>>>> Sent: February 20, 2008 13:40
>>>> To: Apache AXIS C Developers List
>>>> Subject: RE: FW: Question regarding the adjustment of response
>>>> timeouts
>>>>
>>>> Hello Senaka,
>>>>
>>>> I took a look at "axis2_http_transport.h" and noticed that the
>>>> constants, AXIS2_HTTP_DEFAULT_SO_TIMEOUT and
>>>> AXIS2_HTTP_DEFAULT_CONNECTION_TIMEOUT, both held values of 6000ms.
>>>> This coincides with the upper timeout limit our team was
>>>>
>> experiencing,
>>
>>>> so it may provide a clue to the timeout problem.
>>>>
>>>> Cheers,
>>>> Cliff
>>>>
>>>> -----Original Message-----
>>>> From: Senaka Fernando [mailto:senaka@wso2.com]
>>>> Sent: February 18, 2008 11:35
>>>> To: Apache AXIS C Developers List
>>>> Subject: Re: FW: Question regarding the adjustment of response
>>>> timeouts
>>>>
>>>> Hi Cliff,
>>>>
>>>> We'll look into this before the 1.3.0 release and try to have it
>>>>
>> fixed
>>
>>>> before we release.
>>>>
>>>> Regards,
>>>> Senaka
>>>>
>>>>
>>>>
>>>>> Hello Dev Team,
>>>>>
>>>>> I presented this question with regards to using timeouts in the
>>>>> axis2-c-user forum. Dimuthu is getting similar results under Linux,
>>>>>
>>
>>
>>>>> and suggested that there may be a bug in timeout behaviour. Please
>>>>> see
>>>>>
>>>>>
>>>>
>>>>
>>>>> below for the details.
>>>>>
>>>>> Cheers,
>>>>> Cliff
>>>>>
>>>>> -----Original Message-----
>>>>> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
>>>>> Sent: February 16, 2008 05:23
>>>>> To: Apache AXIS C User List
>>>>> Subject: Re: [AXIS2C] Question regarding the adjustment of response
>>>>>
>>
>>
>>>>> timeouts
>>>>>
>>>>> Hi,
>>>>>
>>>>> I too checked it in Linux and got the same result,
>>>>>
>>>>> Seems we are not using axis2_options_get_timeout_in_milli_seconds
>>>>> anywhere.. If this is a bug, should be fixed before the 1.3
>>>>>
>> release.
>>
>>>>> Thanks
>>>>> Dimuthu
>>>>>
>>>>> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
>>>>> <cl...@mdacorporation.com> wrote:
>>>>>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I have a question about adjusting the timeout period for web
>>>>>>
>>>>>>
>>>> services.
>>>>
>>>>
>>>>>> Our current software dictates that we can have upwards of a 300
>>>>>> second
>>>>>>
>>>>>> delay before a response is sent (we have a large amount of data
>>>>>>
>> that
>>
>>>>>> needs to be prepared before being sent). Currently, our web
>>>>>>
>> service
>>
>>>>>> component will timeout after roughly 60 sec (I'm not sure if this
>>>>>>
>> is
>>
>>>>>> the Axis API, or from the OS). I have tried using some of the
>>>>>> timeout
>>>>>>
>>>>>>
>>>>
>>>>
>>>>>> functions in the Axis2C API, but they appear to have no effect (if
>>>>>>
>> I
>>
>>>>>> set the timeout 5 secs and the server takes 10 secs to respond,
>>>>>>
>> the
>>
>>>>>> client will wait 10 secs for the response). I am assuming that I
>>>>>>
>> am
>>
>>>>>> using the API incorrectly. We are working under WinXP, and have
>>>>>>
>>>>>>
>>>>> generate portions of our code using the WSDL2C tool.
>>>>>
>>>>>
>>>>>> We have chosen to generate synchronous code using WSDL2C (so the
>>>>>> eventual call in the generate code will be to
>>>>>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>>>>>> paraphrase of the code that we have and how I thought the timeout
>>>>>> function should be
>>>>>> applied:
>>>>>>
>>>>>> env = axutil_env_create_all( "MyServiceLog.log",
>>>>>> AXIS2_LOG_LEVEL_TRACE);
>>>>>> assert(NULL != env);
>>>>>>
>>>>>> stub = axis2_stub_create_MyService( env,
>>>>>>
>>>>>>
>> AXIS2_GETENV("AXIS2C_HOME"),
>>
>>>>>> "http://myserver.ca:8080/services/MyService");
>>>>>> assert(NULL != stub);
>>>>>>
>>>>>>
>>>>>> status = axis2_options_set_timeout_in_milli_seconds(
>>>>>> axis2_stub_get_options( stub,
>>>>>> env ),
>>>>>> env,
>>>>>> 300000);
>>>>>> assert(AXIS2_SUCCESS == status);
>>>>>>
>>>>>> /* */
>>>>>> /* lots of interleaving non-Axis2C code */
>>>>>> /* */
>>>>>>
>>>>>> responseNode = axis2_stub_op_MyService_MyOperation(
>>>>>> stub,
>>>>>> env,
>>>>>> headerNode1,
>>>>>> headerNode2,
>>>>>> bodyNode);
>>>>>> if(NULL !=)
>>>>>> {
>>>>>> /* process the response */
>>>>>> }
>>>>>> else
>>>>>> {
>>>>>> /* log the response error */
>>>>>> }
>>>>>>
>>>>>> Thank you in advance for the help.
>>>>>>
>>>>>> Cheers,
>>>>>> Cliff
>>>>>>
>>>>>>
>>>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: FW: Question regarding the adjustment of response timeouts
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Hi Cliff,
Thank you for your help in figuring out the cause of the problem.
The problem was not exactly in there, but in http sender. But your
pointers helped to locate that.
I have now fixed this and tested on Windows and commited to svn
head. 1.3 release should have it.
Thanks,
Samisa...
Clifford THOMPSON wrote:
> Hello,
>
> I made a mistake in my last message. Please see my inline comment for
> the correction
>
> Cheers,
> Cliff
>
> -----Original Message-----
> From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
> Sent: February 22, 2008 15:08
> To: Apache AXIS C Developers List
> Subject: RE: FW: Question regarding the adjustment of response timeouts
>
>
>> Hello Samisa,
>>
>> I have been doing some tracing, and hopefully I've found some
>>
> information that may be useful. I have traced through my blocking
> service call:
>
>> + axis2_stub_op_MyService_MyOperation
>> + axis2_svc_client_send_receive_with_op_name
>> + axis2_op_client_execute
>> + axis2_op_client_two_way_send
>>
>> It appears that the call to "axis2_msg_ctx_get_property" returns NULL:
>>
>> <code>
>> AXIS2_EXTERN axis2_msg_ctx_t *AXIS2_CALL
>> axis2_op_client_two_way_send(
>> const axutil_env_t * env,
>> axis2_msg_ctx_t * msg_ctx)
>> {
>> axis2_engine_t *engine = NULL;
>> axis2_status_t status = AXIS2_SUCCESS;
>> axis2_msg_ctx_t *response = NULL;
>> axis2_conf_ctx_t *conf_ctx = NULL;
>> axis2_op_t *op = NULL;
>> axiom_soap_envelope_t *response_envelope = NULL;
>> axutil_property_t *property = NULL;
>> long index = -1;
>> axis2_bool_t wait_indefinitely = AXIS2_FALSE;
>>
>> AXIS2_ENV_CHECK(env, NULL);
>>
>> conf_ctx = axis2_msg_ctx_get_conf_ctx(msg_ctx, env);
>> engine = axis2_engine_create(env, conf_ctx);
>> if (!engine)
>> return NULL;
>> property =
>> axis2_msg_ctx_get_property(msg_ctx, env,
>>
> AXIS2_TIMEOUT_IN_SECONDS); </code>
>
>> And thus the next section of code never picks up the timeout value
>>
> since we never find the "property" for the timeout:
>
>> <code>
>> if (property)
>> {
>> axis2_char_t *value = axutil_property_get_value(property,
>> env);
>> if (value)
>> index = AXIS2_ATOI(value);
>> if (index == -1)
>> {
>> wait_indefinitely = AXIS2_TRUE;
>> index = 1;
>> }
>> }
>> </code>
>>
>> which is used later in the function:
>>
>> <code>
>> else
>> {
>> while (!response_envelope && index > 0)
>> {
>> /*wait till the response arrives */
>> AXIS2_SLEEP(1);
>> if (!wait_indefinitely)
>> index--;
>> response_envelope =
>> axis2_msg_ctx_get_response_soap_envelope(msg_ctx,
>> env);
>> }
>> </code>
>>
>> You guys are much more familiar which the code base, so does the call
>>
> to "axis2_op_client_get_msg_ctx" copy the timeout information from the >
>
>>> "options" member of "op_client" into "msg_ctx" (the variable that is
>>>
> eventually passed to "axis2_msg_ctx_get_property"):
>
> I meant the call to "axis2_msg_ctx_set_options" not
> "axis2_op_client_get_msg_ctx", please see the additional code in the
> snippet below:
>
>
>> <code>
>> AXIS2_EXTERN axis2_status_t AXIS2_CALL
>> axis2_op_client_execute(
>> axis2_op_client_t * op_client,
>> const axutil_env_t * env,
>> const axis2_bool_t block)
>> {
>> axis2_conf_ctx_t *conf_ctx = NULL;
>> axis2_msg_ctx_t *msg_ctx = NULL;
>>
>> axis2_transport_out_desc_t *transport_out = NULL;
>> axis2_transport_in_desc_t *transport_in = NULL;
>>
>> axis2_status_t status = AXIS2_FAILURE;
>> axis2_op_t *op = NULL;
>> axis2_char_t *msg_id = NULL;
>>
>> AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
>>
>> if (op_client->completed)
>> {
>> return AXIS2_FAILURE;
>> }
>>
>> conf_ctx = axis2_svc_ctx_get_conf_ctx(op_client->svc_ctx,
>>
> env);
>
>> msg_ctx = (axis2_msg_ctx_t *)
>> axis2_op_client_get_msg_ctx(op_client, env,
>>
>> AXIS2_WSDL_MESSAGE_LABEL_OUT);
>> </code>
>>
>
> <code>
> if (!msg_ctx)
> {
> return AXIS2_FAILURE;
> }
>
> axis2_msg_ctx_set_options(msg_ctx, env, op_client->options);
> </code>
>
>
>> When I traced through the call to "axis2_msg_ctx_get_property", all of
>>
> the hash tables stored within "msg_ctx" or its children appear to be > >
>
>> empty. I am not sure if this is correct or not, but I hope this all
>>
> helps out with the bug tracking.
>
>> Cheers,
>> Cliff
>>
>> -----Original Message-----
>> From: Samisa Abeysinghe [mailto:samisa@wso2.com]
>> Sent: February 20, 2008 18:06
>> To: Apache AXIS C Developers List
>> Subject: Re: FW: Question regarding the adjustment of response
>>
> timeouts
>
>> The current problem is that, for the normal non blocking case, the
>>
> implementation does not pick the user option and set it on the socket.
>
>> I hope the fix is straight forward.
>>
>> Regards,
>> Samisa...
>>
>> Clifford THOMPSON wrote:
>>
>>> I meant 60000ms...
>>>
>>> -----Original Message-----
>>> From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
>>> Sent: February 20, 2008 13:40
>>> To: Apache AXIS C Developers List
>>> Subject: RE: FW: Question regarding the adjustment of response
>>> timeouts
>>>
>>> Hello Senaka,
>>>
>>> I took a look at "axis2_http_transport.h" and noticed that the
>>> constants, AXIS2_HTTP_DEFAULT_SO_TIMEOUT and
>>> AXIS2_HTTP_DEFAULT_CONNECTION_TIMEOUT, both held values of 6000ms.
>>> This coincides with the upper timeout limit our team was
>>>
> experiencing,
>
>>> so it may provide a clue to the timeout problem.
>>>
>>> Cheers,
>>> Cliff
>>>
>>> -----Original Message-----
>>> From: Senaka Fernando [mailto:senaka@wso2.com]
>>> Sent: February 18, 2008 11:35
>>> To: Apache AXIS C Developers List
>>> Subject: Re: FW: Question regarding the adjustment of response
>>> timeouts
>>>
>>> Hi Cliff,
>>>
>>> We'll look into this before the 1.3.0 release and try to have it
>>>
> fixed
>
>>> before we release.
>>>
>>> Regards,
>>> Senaka
>>>
>>>
>>>
>>>> Hello Dev Team,
>>>>
>>>> I presented this question with regards to using timeouts in the
>>>> axis2-c-user forum. Dimuthu is getting similar results under Linux,
>>>>
>
>
>>>> and suggested that there may be a bug in timeout behaviour. Please
>>>> see
>>>>
>>>>
>>>
>>>
>>>> below for the details.
>>>>
>>>> Cheers,
>>>> Cliff
>>>>
>>>> -----Original Message-----
>>>> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
>>>> Sent: February 16, 2008 05:23
>>>> To: Apache AXIS C User List
>>>> Subject: Re: [AXIS2C] Question regarding the adjustment of response
>>>>
>
>
>>>> timeouts
>>>>
>>>> Hi,
>>>>
>>>> I too checked it in Linux and got the same result,
>>>>
>>>> Seems we are not using axis2_options_get_timeout_in_milli_seconds
>>>> anywhere.. If this is a bug, should be fixed before the 1.3
>>>>
> release.
>
>>>> Thanks
>>>> Dimuthu
>>>>
>>>> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
>>>> <cl...@mdacorporation.com> wrote:
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>> I have a question about adjusting the timeout period for web
>>>>>
>>>>>
>>> services.
>>>
>>>
>>>>> Our current software dictates that we can have upwards of a 300
>>>>> second
>>>>>
>>>>> delay before a response is sent (we have a large amount of data
>>>>>
> that
>
>>>>> needs to be prepared before being sent). Currently, our web
>>>>>
> service
>
>>>>> component will timeout after roughly 60 sec (I'm not sure if this
>>>>>
> is
>
>>>>> the Axis API, or from the OS). I have tried using some of the
>>>>> timeout
>>>>>
>>>>>
>>>
>>>
>>>>> functions in the Axis2C API, but they appear to have no effect (if
>>>>>
> I
>
>>>>> set the timeout 5 secs and the server takes 10 secs to respond,
>>>>>
> the
>
>>>>> client will wait 10 secs for the response). I am assuming that I
>>>>>
> am
>
>>>>> using the API incorrectly. We are working under WinXP, and have
>>>>>
>>>>>
>>>> generate portions of our code using the WSDL2C tool.
>>>>
>>>>
>>>>> We have chosen to generate synchronous code using WSDL2C (so the
>>>>> eventual call in the generate code will be to
>>>>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>>>>> paraphrase of the code that we have and how I thought the timeout
>>>>> function should be
>>>>> applied:
>>>>>
>>>>> env = axutil_env_create_all( "MyServiceLog.log",
>>>>> AXIS2_LOG_LEVEL_TRACE);
>>>>> assert(NULL != env);
>>>>>
>>>>> stub = axis2_stub_create_MyService( env,
>>>>>
>>>>>
> AXIS2_GETENV("AXIS2C_HOME"),
>
>>>>> "http://myserver.ca:8080/services/MyService");
>>>>> assert(NULL != stub);
>>>>>
>>>>>
>>>>> status = axis2_options_set_timeout_in_milli_seconds(
>>>>> axis2_stub_get_options( stub,
>>>>> env ),
>>>>> env,
>>>>> 300000);
>>>>> assert(AXIS2_SUCCESS == status);
>>>>>
>>>>> /* */
>>>>> /* lots of interleaving non-Axis2C code */
>>>>> /* */
>>>>>
>>>>> responseNode = axis2_stub_op_MyService_MyOperation(
>>>>> stub,
>>>>> env,
>>>>> headerNode1,
>>>>> headerNode2,
>>>>> bodyNode);
>>>>> if(NULL !=)
>>>>> {
>>>>> /* process the response */
>>>>> }
>>>>> else
>>>>> {
>>>>> /* log the response error */
>>>>> }
>>>>>
>>>>> Thank you in advance for the help.
>>>>>
>>>>> Cheers,
>>>>> Cliff
>>>>>
>>>>>
>>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: FW: Question regarding the adjustment of response timeouts
Posted by Clifford THOMPSON <ct...@mdacorporation.com>.
Hello,
I made a mistake in my last message. Please see my inline comment for
the correction
Cheers,
Cliff
-----Original Message-----
From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
Sent: February 22, 2008 15:08
To: Apache AXIS C Developers List
Subject: RE: FW: Question regarding the adjustment of response timeouts
> Hello Samisa,
>
> I have been doing some tracing, and hopefully I've found some
information that may be useful. I have traced through my blocking
service call:
>
> + axis2_stub_op_MyService_MyOperation
> + axis2_svc_client_send_receive_with_op_name
> + axis2_op_client_execute
> + axis2_op_client_two_way_send
>
> It appears that the call to "axis2_msg_ctx_get_property" returns NULL:
>
> <code>
> AXIS2_EXTERN axis2_msg_ctx_t *AXIS2_CALL
> axis2_op_client_two_way_send(
> const axutil_env_t * env,
> axis2_msg_ctx_t * msg_ctx)
> {
> axis2_engine_t *engine = NULL;
> axis2_status_t status = AXIS2_SUCCESS;
> axis2_msg_ctx_t *response = NULL;
> axis2_conf_ctx_t *conf_ctx = NULL;
> axis2_op_t *op = NULL;
> axiom_soap_envelope_t *response_envelope = NULL;
> axutil_property_t *property = NULL;
> long index = -1;
> axis2_bool_t wait_indefinitely = AXIS2_FALSE;
>
> AXIS2_ENV_CHECK(env, NULL);
>
> conf_ctx = axis2_msg_ctx_get_conf_ctx(msg_ctx, env);
> engine = axis2_engine_create(env, conf_ctx);
> if (!engine)
> return NULL;
> property =
> axis2_msg_ctx_get_property(msg_ctx, env,
AXIS2_TIMEOUT_IN_SECONDS); </code>
>
> And thus the next section of code never picks up the timeout value
since we never find the "property" for the timeout:
>
> <code>
> if (property)
> {
> axis2_char_t *value = axutil_property_get_value(property,
> env);
> if (value)
> index = AXIS2_ATOI(value);
> if (index == -1)
> {
> wait_indefinitely = AXIS2_TRUE;
> index = 1;
> }
> }
> </code>
>
> which is used later in the function:
>
> <code>
> else
> {
> while (!response_envelope && index > 0)
> {
> /*wait till the response arrives */
> AXIS2_SLEEP(1);
> if (!wait_indefinitely)
> index--;
> response_envelope =
> axis2_msg_ctx_get_response_soap_envelope(msg_ctx,
> env);
> }
> </code>
>
> You guys are much more familiar which the code base, so does the call
to "axis2_op_client_get_msg_ctx" copy the timeout information from the >
> > "options" member of "op_client" into "msg_ctx" (the variable that is
eventually passed to "axis2_msg_ctx_get_property"):
I meant the call to "axis2_msg_ctx_set_options" not
"axis2_op_client_get_msg_ctx", please see the additional code in the
snippet below:
>
> <code>
> AXIS2_EXTERN axis2_status_t AXIS2_CALL
> axis2_op_client_execute(
> axis2_op_client_t * op_client,
> const axutil_env_t * env,
> const axis2_bool_t block)
> {
> axis2_conf_ctx_t *conf_ctx = NULL;
> axis2_msg_ctx_t *msg_ctx = NULL;
>
> axis2_transport_out_desc_t *transport_out = NULL;
> axis2_transport_in_desc_t *transport_in = NULL;
>
> axis2_status_t status = AXIS2_FAILURE;
> axis2_op_t *op = NULL;
> axis2_char_t *msg_id = NULL;
>
> AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
>
> if (op_client->completed)
> {
> return AXIS2_FAILURE;
> }
>
> conf_ctx = axis2_svc_ctx_get_conf_ctx(op_client->svc_ctx,
env);
>
> msg_ctx = (axis2_msg_ctx_t *)
> axis2_op_client_get_msg_ctx(op_client, env,
>
> AXIS2_WSDL_MESSAGE_LABEL_OUT);
> </code>
<code>
if (!msg_ctx)
{
return AXIS2_FAILURE;
}
axis2_msg_ctx_set_options(msg_ctx, env, op_client->options);
</code>
>
>
> When I traced through the call to "axis2_msg_ctx_get_property", all of
the hash tables stored within "msg_ctx" or its children appear to be > >
> empty. I am not sure if this is correct or not, but I hope this all
helps out with the bug tracking.
>
> Cheers,
> Cliff
>
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa@wso2.com]
> Sent: February 20, 2008 18:06
> To: Apache AXIS C Developers List
> Subject: Re: FW: Question regarding the adjustment of response
timeouts
>
> The current problem is that, for the normal non blocking case, the
implementation does not pick the user option and set it on the socket.
>
> I hope the fix is straight forward.
>
> Regards,
> Samisa...
>
> Clifford THOMPSON wrote:
> > I meant 60000ms...
> >
> > -----Original Message-----
> > From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
> > Sent: February 20, 2008 13:40
> > To: Apache AXIS C Developers List
> > Subject: RE: FW: Question regarding the adjustment of response
> > timeouts
> >
> > Hello Senaka,
> >
> > I took a look at "axis2_http_transport.h" and noticed that the
> > constants, AXIS2_HTTP_DEFAULT_SO_TIMEOUT and
> > AXIS2_HTTP_DEFAULT_CONNECTION_TIMEOUT, both held values of 6000ms.
> > This coincides with the upper timeout limit our team was
experiencing,
>
> > so it may provide a clue to the timeout problem.
> >
> > Cheers,
> > Cliff
> >
> > -----Original Message-----
> > From: Senaka Fernando [mailto:senaka@wso2.com]
> > Sent: February 18, 2008 11:35
> > To: Apache AXIS C Developers List
> > Subject: Re: FW: Question regarding the adjustment of response
> > timeouts
> >
> > Hi Cliff,
> >
> > We'll look into this before the 1.3.0 release and try to have it
fixed
>
> > before we release.
> >
> > Regards,
> > Senaka
> >
> >
> >> Hello Dev Team,
> >>
> >> I presented this question with regards to using timeouts in the
> >> axis2-c-user forum. Dimuthu is getting similar results under Linux,
> >> and suggested that there may be a bug in timeout behaviour. Please
> >> see
> >>
> >
> >
> >> below for the details.
> >>
> >> Cheers,
> >> Cliff
> >>
> >> -----Original Message-----
> >> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
> >> Sent: February 16, 2008 05:23
> >> To: Apache AXIS C User List
> >> Subject: Re: [AXIS2C] Question regarding the adjustment of response
> >> timeouts
> >>
> >> Hi,
> >>
> >> I too checked it in Linux and got the same result,
> >>
> >> Seems we are not using axis2_options_get_timeout_in_milli_seconds
> >> anywhere.. If this is a bug, should be fixed before the 1.3
release.
> >>
> >> Thanks
> >> Dimuthu
> >>
> >> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
> >> <cl...@mdacorporation.com> wrote:
> >>
> >>> Hello,
> >>>
> >>> I have a question about adjusting the timeout period for web
> >>>
> > services.
> >
> >>> Our current software dictates that we can have upwards of a 300
> >>> second
> >>>
> >>> delay before a response is sent (we have a large amount of data
that
>
> >>> needs to be prepared before being sent). Currently, our web
service
> >>> component will timeout after roughly 60 sec (I'm not sure if this
is
>
> >>> the Axis API, or from the OS). I have tried using some of the
> >>> timeout
> >>>
> >
> >
> >>> functions in the Axis2C API, but they appear to have no effect (if
I
>
> >>> set the timeout 5 secs and the server takes 10 secs to respond,
the
> >>> client will wait 10 secs for the response). I am assuming that I
am
> >>> using the API incorrectly. We are working under WinXP, and have
> >>>
> >> generate portions of our code using the WSDL2C tool.
> >>
> >>> We have chosen to generate synchronous code using WSDL2C (so the
> >>> eventual call in the generate code will be to
> >>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
> >>> paraphrase of the code that we have and how I thought the timeout
> >>> function should be
> >>> applied:
> >>>
> >>> env = axutil_env_create_all( "MyServiceLog.log",
> >>> AXIS2_LOG_LEVEL_TRACE);
> >>> assert(NULL != env);
> >>>
> >>> stub = axis2_stub_create_MyService( env,
> >>>
AXIS2_GETENV("AXIS2C_HOME"),
> >>>
> >>> "http://myserver.ca:8080/services/MyService");
> >>> assert(NULL != stub);
> >>>
> >>>
> >>> status = axis2_options_set_timeout_in_milli_seconds(
> >>> axis2_stub_get_options( stub,
> >>> env ),
> >>> env,
> >>> 300000);
> >>> assert(AXIS2_SUCCESS == status);
> >>>
> >>> /* */
> >>> /* lots of interleaving non-Axis2C code */
> >>> /* */
> >>>
> >>> responseNode = axis2_stub_op_MyService_MyOperation(
> >>> stub,
> >>> env,
> >>> headerNode1,
> >>> headerNode2,
> >>> bodyNode);
> >>> if(NULL !=)
> >>> {
> >>> /* process the response */
> >>> }
> >>> else
> >>> {
> >>> /* log the response error */
> >>> }
> >>>
> >>> Thank you in advance for the help.
> >>>
> >>> Cheers,
> >>> Cliff
> >>>
> >>>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: FW: Question regarding the adjustment of response timeouts
Posted by Clifford THOMPSON <ct...@mdacorporation.com>.
Hello Samisa,
I have been doing some tracing, and hopefully I've found some
information that may be useful. I have traced through my blocking
service call:
+ axis2_stub_op_MyService_MyOperation
+ axis2_svc_client_send_receive_with_op_name
+ axis2_op_client_execute
+ axis2_op_client_two_way_send
It appears that the call to "axis2_msg_ctx_get_property" returns NULL:
<code>
AXIS2_EXTERN axis2_msg_ctx_t *AXIS2_CALL
axis2_op_client_two_way_send(
const axutil_env_t * env,
axis2_msg_ctx_t * msg_ctx)
{
axis2_engine_t *engine = NULL;
axis2_status_t status = AXIS2_SUCCESS;
axis2_msg_ctx_t *response = NULL;
axis2_conf_ctx_t *conf_ctx = NULL;
axis2_op_t *op = NULL;
axiom_soap_envelope_t *response_envelope = NULL;
axutil_property_t *property = NULL;
long index = -1;
axis2_bool_t wait_indefinitely = AXIS2_FALSE;
AXIS2_ENV_CHECK(env, NULL);
conf_ctx = axis2_msg_ctx_get_conf_ctx(msg_ctx, env);
engine = axis2_engine_create(env, conf_ctx);
if (!engine)
return NULL;
property =
axis2_msg_ctx_get_property(msg_ctx, env,
AXIS2_TIMEOUT_IN_SECONDS);
</code>
And thus the next section of code never picks up the timeout value since
we never find the "property" for the timeout:
<code>
if (property)
{
axis2_char_t *value = axutil_property_get_value(property,
env);
if (value)
index = AXIS2_ATOI(value);
if (index == -1)
{
wait_indefinitely = AXIS2_TRUE;
index = 1;
}
}
</code>
which is used later in the function:
<code>
else
{
while (!response_envelope && index > 0)
{
/*wait till the response arrives */
AXIS2_SLEEP(1);
if (!wait_indefinitely)
index--;
response_envelope =
axis2_msg_ctx_get_response_soap_envelope(msg_ctx,
env);
}
</code>
You guys are much more familiar which the code base, so does the call to
"axis2_op_client_get_msg_ctx" copy the timeout information from the
"options" member of "op_client" into "msg_ctx" (the variable that is
eventually passed to "axis2_msg_ctx_get_property"):
<code>
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axis2_op_client_execute(
axis2_op_client_t * op_client,
const axutil_env_t * env,
const axis2_bool_t block)
{
axis2_conf_ctx_t *conf_ctx = NULL;
axis2_msg_ctx_t *msg_ctx = NULL;
axis2_transport_out_desc_t *transport_out = NULL;
axis2_transport_in_desc_t *transport_in = NULL;
axis2_status_t status = AXIS2_FAILURE;
axis2_op_t *op = NULL;
axis2_char_t *msg_id = NULL;
AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
if (op_client->completed)
{
return AXIS2_FAILURE;
}
conf_ctx = axis2_svc_ctx_get_conf_ctx(op_client->svc_ctx, env);
msg_ctx = (axis2_msg_ctx_t *)
axis2_op_client_get_msg_ctx(op_client, env,
AXIS2_WSDL_MESSAGE_LABEL_OUT);
</code>
When I traced through the call to "axis2_msg_ctx_get_property", all of
the hash tables stored within "msg_ctx" or its children appear to be
empty. I am not sure if this is correct or not, but I hope this all
helps out with the bug tracking.
Cheers,
Cliff
-----Original Message-----
From: Samisa Abeysinghe [mailto:samisa@wso2.com]
Sent: February 20, 2008 18:06
To: Apache AXIS C Developers List
Subject: Re: FW: Question regarding the adjustment of response timeouts
The current problem is that, for the normal non blocking case, the
implementation does not pick the user option and set it on the socket.
I hope the fix is straight forward.
Regards,
Samisa...
Clifford THOMPSON wrote:
> I meant 60000ms...
>
> -----Original Message-----
> From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
> Sent: February 20, 2008 13:40
> To: Apache AXIS C Developers List
> Subject: RE: FW: Question regarding the adjustment of response
> timeouts
>
> Hello Senaka,
>
> I took a look at "axis2_http_transport.h" and noticed that the
> constants, AXIS2_HTTP_DEFAULT_SO_TIMEOUT and
> AXIS2_HTTP_DEFAULT_CONNECTION_TIMEOUT, both held values of 6000ms.
> This coincides with the upper timeout limit our team was experiencing,
> so it may provide a clue to the timeout problem.
>
> Cheers,
> Cliff
>
> -----Original Message-----
> From: Senaka Fernando [mailto:senaka@wso2.com]
> Sent: February 18, 2008 11:35
> To: Apache AXIS C Developers List
> Subject: Re: FW: Question regarding the adjustment of response
> timeouts
>
> Hi Cliff,
>
> We'll look into this before the 1.3.0 release and try to have it fixed
> before we release.
>
> Regards,
> Senaka
>
>
>> Hello Dev Team,
>>
>> I presented this question with regards to using timeouts in the
>> axis2-c-user forum. Dimuthu is getting similar results under Linux,
>> and suggested that there may be a bug in timeout behaviour. Please
>> see
>>
>
>
>> below for the details.
>>
>> Cheers,
>> Cliff
>>
>> -----Original Message-----
>> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
>> Sent: February 16, 2008 05:23
>> To: Apache AXIS C User List
>> Subject: Re: [AXIS2C] Question regarding the adjustment of response
>> timeouts
>>
>> Hi,
>>
>> I too checked it in Linux and got the same result,
>>
>> Seems we are not using axis2_options_get_timeout_in_milli_seconds
>> anywhere.. If this is a bug, should be fixed before the 1.3 release.
>>
>> Thanks
>> Dimuthu
>>
>> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
>> <cl...@mdacorporation.com> wrote:
>>
>>> Hello,
>>>
>>> I have a question about adjusting the timeout period for web
>>>
> services.
>
>>> Our current software dictates that we can have upwards of a 300
>>> second
>>>
>>> delay before a response is sent (we have a large amount of data that
>>> needs to be prepared before being sent). Currently, our web service
>>> component will timeout after roughly 60 sec (I'm not sure if this is
>>> the Axis API, or from the OS). I have tried using some of the
>>> timeout
>>>
>
>
>>> functions in the Axis2C API, but they appear to have no effect (if I
>>> set the timeout 5 secs and the server takes 10 secs to respond, the
>>> client will wait 10 secs for the response). I am assuming that I am
>>> using the API incorrectly. We are working under WinXP, and have
>>>
>> generate portions of our code using the WSDL2C tool.
>>
>>> We have chosen to generate synchronous code using WSDL2C (so the
>>> eventual call in the generate code will be to
>>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>>> paraphrase of the code that we have and how I thought the timeout
>>> function should be
>>> applied:
>>>
>>> env = axutil_env_create_all( "MyServiceLog.log",
>>> AXIS2_LOG_LEVEL_TRACE);
>>> assert(NULL != env);
>>>
>>> stub = axis2_stub_create_MyService( env,
>>> AXIS2_GETENV("AXIS2C_HOME"),
>>>
>>> "http://myserver.ca:8080/services/MyService");
>>> assert(NULL != stub);
>>>
>>>
>>> status = axis2_options_set_timeout_in_milli_seconds(
>>> axis2_stub_get_options( stub,
>>> env ),
>>> env,
>>> 300000);
>>> assert(AXIS2_SUCCESS == status);
>>>
>>> /* */
>>> /* lots of interleaving non-Axis2C code */
>>> /* */
>>>
>>> responseNode = axis2_stub_op_MyService_MyOperation(
>>> stub,
>>> env,
>>> headerNode1,
>>> headerNode2,
>>> bodyNode);
>>> if(NULL !=)
>>> {
>>> /* process the response */
>>> }
>>> else
>>> {
>>> /* log the response error */
>>> }
>>>
>>> Thank you in advance for the help.
>>>
>>> Cheers,
>>> Cliff
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: FW: Question regarding the adjustment of response timeouts
Posted by Samisa Abeysinghe <sa...@wso2.com>.
The current problem is that, for the normal non blocking case, the
implementation does not pick the user option and set it on the socket.
I hope the fix is straight forward.
Regards,
Samisa...
Clifford THOMPSON wrote:
> I meant 60000ms...
>
> -----Original Message-----
> From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
> Sent: February 20, 2008 13:40
> To: Apache AXIS C Developers List
> Subject: RE: FW: Question regarding the adjustment of response timeouts
>
> Hello Senaka,
>
> I took a look at "axis2_http_transport.h" and noticed that the
> constants, AXIS2_HTTP_DEFAULT_SO_TIMEOUT and
> AXIS2_HTTP_DEFAULT_CONNECTION_TIMEOUT, both held values of 6000ms. This
> coincides with the upper timeout limit our team was experiencing, so it
> may provide a clue to the timeout problem.
>
> Cheers,
> Cliff
>
> -----Original Message-----
> From: Senaka Fernando [mailto:senaka@wso2.com]
> Sent: February 18, 2008 11:35
> To: Apache AXIS C Developers List
> Subject: Re: FW: Question regarding the adjustment of response timeouts
>
> Hi Cliff,
>
> We'll look into this before the 1.3.0 release and try to have it fixed
> before we release.
>
> Regards,
> Senaka
>
>
>> Hello Dev Team,
>>
>> I presented this question with regards to using timeouts in the
>> axis2-c-user forum. Dimuthu is getting similar results under Linux,
>> and suggested that there may be a bug in timeout behaviour. Please see
>>
>
>
>> below for the details.
>>
>> Cheers,
>> Cliff
>>
>> -----Original Message-----
>> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
>> Sent: February 16, 2008 05:23
>> To: Apache AXIS C User List
>> Subject: Re: [AXIS2C] Question regarding the adjustment of response
>> timeouts
>>
>> Hi,
>>
>> I too checked it in Linux and got the same result,
>>
>> Seems we are not using axis2_options_get_timeout_in_milli_seconds
>> anywhere.. If this is a bug, should be fixed before the 1.3 release.
>>
>> Thanks
>> Dimuthu
>>
>> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
>> <cl...@mdacorporation.com> wrote:
>>
>>> Hello,
>>>
>>> I have a question about adjusting the timeout period for web
>>>
> services.
>
>>> Our current software dictates that we can have upwards of a 300
>>> second
>>>
>>> delay before a response is sent (we have a large amount of data that
>>> needs to be prepared before being sent). Currently, our web service
>>> component will timeout after roughly 60 sec (I'm not sure if this is
>>> the Axis API, or from the OS). I have tried using some of the timeout
>>>
>
>
>>> functions in the Axis2C API, but they appear to have no effect (if I
>>> set the timeout 5 secs and the server takes 10 secs to respond, the
>>> client will wait 10 secs for the response). I am assuming that I am
>>> using the API incorrectly. We are working under WinXP, and have
>>>
>> generate portions of our code using the WSDL2C tool.
>>
>>> We have chosen to generate synchronous code using WSDL2C (so the
>>> eventual call in the generate code will be to
>>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>>> paraphrase of the code that we have and how I thought the timeout
>>> function should be
>>> applied:
>>>
>>> env = axutil_env_create_all( "MyServiceLog.log",
>>> AXIS2_LOG_LEVEL_TRACE);
>>> assert(NULL != env);
>>>
>>> stub = axis2_stub_create_MyService( env,
>>> AXIS2_GETENV("AXIS2C_HOME"),
>>>
>>> "http://myserver.ca:8080/services/MyService");
>>> assert(NULL != stub);
>>>
>>>
>>> status = axis2_options_set_timeout_in_milli_seconds(
>>> axis2_stub_get_options( stub,
>>> env ),
>>> env,
>>> 300000);
>>> assert(AXIS2_SUCCESS == status);
>>>
>>> /* */
>>> /* lots of interleaving non-Axis2C code */
>>> /* */
>>>
>>> responseNode = axis2_stub_op_MyService_MyOperation(
>>> stub,
>>> env,
>>> headerNode1,
>>> headerNode2,
>>> bodyNode);
>>> if(NULL !=)
>>> {
>>> /* process the response */
>>> }
>>> else
>>> {
>>> /* log the response error */
>>> }
>>>
>>> Thank you in advance for the help.
>>>
>>> Cheers,
>>> Cliff
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: FW: Question regarding the adjustment of response timeouts
Posted by Clifford THOMPSON <ct...@mdacorporation.com>.
I meant 60000ms...
-----Original Message-----
From: Clifford THOMPSON [mailto:cthompso@mdacorporation.com]
Sent: February 20, 2008 13:40
To: Apache AXIS C Developers List
Subject: RE: FW: Question regarding the adjustment of response timeouts
Hello Senaka,
I took a look at "axis2_http_transport.h" and noticed that the
constants, AXIS2_HTTP_DEFAULT_SO_TIMEOUT and
AXIS2_HTTP_DEFAULT_CONNECTION_TIMEOUT, both held values of 6000ms. This
coincides with the upper timeout limit our team was experiencing, so it
may provide a clue to the timeout problem.
Cheers,
Cliff
-----Original Message-----
From: Senaka Fernando [mailto:senaka@wso2.com]
Sent: February 18, 2008 11:35
To: Apache AXIS C Developers List
Subject: Re: FW: Question regarding the adjustment of response timeouts
Hi Cliff,
We'll look into this before the 1.3.0 release and try to have it fixed
before we release.
Regards,
Senaka
> Hello Dev Team,
>
> I presented this question with regards to using timeouts in the
> axis2-c-user forum. Dimuthu is getting similar results under Linux,
> and suggested that there may be a bug in timeout behaviour. Please see
> below for the details.
>
> Cheers,
> Cliff
>
> -----Original Message-----
> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
> Sent: February 16, 2008 05:23
> To: Apache AXIS C User List
> Subject: Re: [AXIS2C] Question regarding the adjustment of response
> timeouts
>
> Hi,
>
> I too checked it in Linux and got the same result,
>
> Seems we are not using axis2_options_get_timeout_in_milli_seconds
> anywhere.. If this is a bug, should be fixed before the 1.3 release.
>
> Thanks
> Dimuthu
>
> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
> <cl...@mdacorporation.com> wrote:
>>
>>
>> Hello,
>>
>> I have a question about adjusting the timeout period for web
services.
>
>> Our current software dictates that we can have upwards of a 300
>> second
>
>> delay before a response is sent (we have a large amount of data that
>> needs to be prepared before being sent). Currently, our web service
>> component will timeout after roughly 60 sec (I'm not sure if this is
>> the Axis API, or from the OS). I have tried using some of the timeout
>> functions in the Axis2C API, but they appear to have no effect (if I
>> set the timeout 5 secs and the server takes 10 secs to respond, the
>> client will wait 10 secs for the response). I am assuming that I am
>> using the API incorrectly. We are working under WinXP, and have
> generate portions of our code using the WSDL2C tool.
>> We have chosen to generate synchronous code using WSDL2C (so the
>> eventual call in the generate code will be to
>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>> paraphrase of the code that we have and how I thought the timeout
>> function should be
>> applied:
>>
>> env = axutil_env_create_all( "MyServiceLog.log",
>> AXIS2_LOG_LEVEL_TRACE);
>> assert(NULL != env);
>>
>> stub = axis2_stub_create_MyService( env,
>> AXIS2_GETENV("AXIS2C_HOME"),
>>
>> "http://myserver.ca:8080/services/MyService");
>> assert(NULL != stub);
>>
>>
>> status = axis2_options_set_timeout_in_milli_seconds(
>> axis2_stub_get_options( stub,
>> env ),
>> env,
>> 300000);
>> assert(AXIS2_SUCCESS == status);
>>
>> /* */
>> /* lots of interleaving non-Axis2C code */
>> /* */
>>
>> responseNode = axis2_stub_op_MyService_MyOperation(
>> stub,
>> env,
>> headerNode1,
>> headerNode2,
>> bodyNode);
>> if(NULL !=)
>> {
>> /* process the response */
>> }
>> else
>> {
>> /* log the response error */
>> }
>>
>> Thank you in advance for the help.
>>
>> Cheers,
>> Cliff
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: FW: Question regarding the adjustment of response timeouts
Posted by Clifford THOMPSON <ct...@mdacorporation.com>.
Hello Senaka,
I took a look at "axis2_http_transport.h" and noticed that the
constants, AXIS2_HTTP_DEFAULT_SO_TIMEOUT and
AXIS2_HTTP_DEFAULT_CONNECTION_TIMEOUT, both held values of 6000ms. This
coincides with the upper timeout limit our team was experiencing, so it
may provide a clue to the timeout problem.
Cheers,
Cliff
-----Original Message-----
From: Senaka Fernando [mailto:senaka@wso2.com]
Sent: February 18, 2008 11:35
To: Apache AXIS C Developers List
Subject: Re: FW: Question regarding the adjustment of response timeouts
Hi Cliff,
We'll look into this before the 1.3.0 release and try to have it fixed
before we release.
Regards,
Senaka
> Hello Dev Team,
>
> I presented this question with regards to using timeouts in the
> axis2-c-user forum. Dimuthu is getting similar results under Linux,
> and suggested that there may be a bug in timeout behaviour. Please see
> below for the details.
>
> Cheers,
> Cliff
>
> -----Original Message-----
> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
> Sent: February 16, 2008 05:23
> To: Apache AXIS C User List
> Subject: Re: [AXIS2C] Question regarding the adjustment of response
> timeouts
>
> Hi,
>
> I too checked it in Linux and got the same result,
>
> Seems we are not using axis2_options_get_timeout_in_milli_seconds
> anywhere.. If this is a bug, should be fixed before the 1.3 release.
>
> Thanks
> Dimuthu
>
> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
> <cl...@mdacorporation.com> wrote:
>>
>>
>> Hello,
>>
>> I have a question about adjusting the timeout period for web
services.
>
>> Our current software dictates that we can have upwards of a 300
>> second
>
>> delay before a response is sent (we have a large amount of data that
>> needs to be prepared before being sent). Currently, our web service
>> component will timeout after roughly 60 sec (I'm not sure if this is
>> the Axis API, or from the OS). I have tried using some of the timeout
>> functions in the Axis2C API, but they appear to have no effect (if I
>> set the timeout 5 secs and the server takes 10 secs to respond, the
>> client will wait 10 secs for the response). I am assuming that I am
>> using the API incorrectly. We are working under WinXP, and have
> generate portions of our code using the WSDL2C tool.
>> We have chosen to generate synchronous code using WSDL2C (so the
>> eventual call in the generate code will be to
>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>> paraphrase of the code that we have and how I thought the timeout
>> function should be
>> applied:
>>
>> env = axutil_env_create_all( "MyServiceLog.log",
>> AXIS2_LOG_LEVEL_TRACE);
>> assert(NULL != env);
>>
>> stub = axis2_stub_create_MyService( env,
>> AXIS2_GETENV("AXIS2C_HOME"),
>>
>> "http://myserver.ca:8080/services/MyService");
>> assert(NULL != stub);
>>
>>
>> status = axis2_options_set_timeout_in_milli_seconds(
>> axis2_stub_get_options( stub,
>> env ),
>> env,
>> 300000);
>> assert(AXIS2_SUCCESS == status);
>>
>> /* */
>> /* lots of interleaving non-Axis2C code */
>> /* */
>>
>> responseNode = axis2_stub_op_MyService_MyOperation(
>> stub,
>> env,
>> headerNode1,
>> headerNode2,
>> bodyNode);
>> if(NULL !=)
>> {
>> /* process the response */
>> }
>> else
>> {
>> /* log the response error */
>> }
>>
>> Thank you in advance for the help.
>>
>> Cheers,
>> Cliff
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: FW: Question regarding the adjustment of response timeouts
Posted by Senaka Fernando <se...@wso2.com>.
Hi Cliff,
We'll look into this before the 1.3.0 release and try to have it fixed
before we release.
Regards,
Senaka
> Hello Dev Team,
>
> I presented this question with regards to using timeouts in the
> axis2-c-user forum. Dimuthu is getting similar results under Linux, and
> suggested that there may be a bug in timeout behaviour. Please see below
> for the details.
>
> Cheers,
> Cliff
>
> -----Original Message-----
> From: Dimuthu Gamage [mailto:dimuthuc@gmail.com]
> Sent: February 16, 2008 05:23
> To: Apache AXIS C User List
> Subject: Re: [AXIS2C] Question regarding the adjustment of response
> timeouts
>
> Hi,
>
> I too checked it in Linux and got the same result,
>
> Seems we are not using axis2_options_get_timeout_in_milli_seconds
> anywhere.. If this is a bug, should be fixed before the 1.3 release.
>
> Thanks
> Dimuthu
>
> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
> <cl...@mdacorporation.com> wrote:
>>
>>
>> Hello,
>>
>> I have a question about adjusting the timeout period for web services.
>
>> Our current software dictates that we can have upwards of a 300 second
>
>> delay before a response is sent (we have a large amount of data that
>> needs to be prepared before being sent). Currently, our web service
>> component will timeout after roughly 60 sec (I'm not sure if this is
>> the Axis API, or from the OS). I have tried using some of the timeout
>> functions in the Axis2C API, but they appear to have no effect (if I
>> set the timeout 5 secs and the server takes 10 secs to respond, the
>> client will wait 10 secs for the response). I am assuming that I am
>> using the API incorrectly. We are working under WinXP, and have
> generate portions of our code using the WSDL2C tool.
>> We have chosen to generate synchronous code using WSDL2C (so the
>> eventual call in the generate code will be to
>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>> paraphrase of the code that we have and how I thought the timeout
>> function should be
>> applied:
>>
>> env = axutil_env_create_all( "MyServiceLog.log",
>> AXIS2_LOG_LEVEL_TRACE);
>> assert(NULL != env);
>>
>> stub = axis2_stub_create_MyService( env,
>> AXIS2_GETENV("AXIS2C_HOME"),
>>
>> "http://myserver.ca:8080/services/MyService");
>> assert(NULL != stub);
>>
>>
>> status = axis2_options_set_timeout_in_milli_seconds(
>> axis2_stub_get_options( stub,
>> env ),
>> env,
>> 300000);
>> assert(AXIS2_SUCCESS == status);
>>
>> /* */
>> /* lots of interleaving non-Axis2C code */
>> /* */
>>
>> responseNode = axis2_stub_op_MyService_MyOperation(
>> stub,
>> env,
>> headerNode1,
>> headerNode2,
>> bodyNode);
>> if(NULL !=)
>> {
>> /* process the response */
>> }
>> else
>> {
>> /* log the response error */
>> }
>>
>> Thank you in advance for the help.
>>
>> Cheers,
>> Cliff
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org