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]
