axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clifford THOMPSON" <cthom...@mdacorporation.com>
Subject RE: FW: Question regarding the adjustment of response timeouts
Date Mon, 25 Feb 2008 18:58:39 GMT
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 
>> >> <clifford.thompson@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


Mime
View raw message