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