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:[EMAIL PROTECTED] >> 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:[EMAIL PROTECTED] >>> 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:[EMAIL PROTECTED] >>>> 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:[EMAIL PROTECTED] >>>> 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:[EMAIL PROTECTED] >>>>> 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 >>>>> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
