Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
1.1.0
-
None
-
Windows XP, Visual Studio 2005
Description
If a blocking I/O is requested for an in-out message exchange and no response is received, axis2_svc_client_send_receive et.al. return a zero response pointer. But one would expect the errno variable to contain some value indicating the error.
In op_client.c in axis2_op_client_two_way_send() there is code at the very end, when there is no response envelope, to ensure that an error code is returned:
if (AXIS2_ERROR_GET_STATUS_CODE(env->error) != AXIS2_SUCCESS)
{
AXIS2_ERROR_SET(env->error,
AXIS2_ERROR_BLOCKING_INVOCATION_EXPECTS_RESPONSE,
AXIS2_FAILURE);
if (engine)
axis2_msg_ctx_free(response, env);
return NULL;
}
As you can see, the !=AXIS2_SUCCESS test should be ==AXIS2_SUCCESS, as the intent is to return error number 3 when no other error has been diagnosed.
Unfortunately, even after this fix, in the nightly build of 11/27/07, there is a new bug that causes error number 3 to be replaced with an uninformative error 2, invalid null parameter. In svc_client, when the empty response is returned, axis2_op_client_add_msg_ctx() is called with an intentional null value clear the ctx.
In the post 1.1 source, parameter validation has been added to axis2_op_client_add_msg_ctx() to diagnose this intended result as an error:
AXIS2_EXTERN axis2_status_t AXIS2_CALL
axis2_op_client_add_msg_ctx(
axis2_op_client_t * op_client,
const axutil_env_t * env,
axis2_msg_ctx_t * mc)
{
axis2_msg_ctx_t *out_msg_ctx = NULL,
*in_msg_ctx = NULL;
axis2_msg_ctx_t **msg_ctx_map = NULL;
AXIS2_PARAM_CHECK (env->error, op_client, AXIS2_FAILURE);
AXIS2_PARAM_CHECK (env->error, mc, AXIS2_FAILURE);
The second AXIS2_PARAM_CHECK should be removed.
After making both these changes in the development shapshot, when the client receives no response, for example if the URL points to a non-running server, the client correctly receives error 3, Blocking invocation expects response.