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]
