axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Mitchell (JIRA)" <>
Subject [jira] Created: (AXIS2C-791) On in-out message flow that fails with no response, no error code or misleading error code is returned, expected error number 3.
Date Thu, 29 Nov 2007 02:38:43 GMT
On in-out message flow that fails with no response, no error code or misleading error code
is returned, expected error number 3.  

                 Key: AXIS2C-791
             Project: Axis2-C
          Issue Type: Bug
          Components: core/clientapi
    Affects Versions: 1.1.0
         Environment: Windows XP, Visual Studio 2005
            Reporter: Bill Mitchell
            Priority: Minor

If a blocking I/O is requested for an in-out message exchange and no response is received,
axis2_svc_client_send_receive 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)
                if (engine)
                    axis2_engine_free(engine, env);
                    engine = NULL;
                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_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.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message