axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando (JIRA)" <>
Subject [jira] Commented: (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, 07 Feb 2008 06:41:08 GMT


Senaka Fernando commented on AXIS2C-791:

Hi again Bill,

I do have a second thought in this regard, to which I'm presently looking into. That is to
leave alone the way in which the param checks are implemented and manually set the status
to failure when you are sure that it has failed. This stratergy can be adopted so that your
status code will be preserved and the robust operation would not return a SUCCESS.

I will do this change for 1.3.0.


> 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
>                 URL:
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: core/clientapi
>    Affects Versions: 1.1.0
>         Environment: Windows XP, Visual Studio 2005
>            Reporter: Bill Mitchell
>            Assignee: Bill Mitchell
>            Priority: Minor
>             Fix For: 1.3.0
>         Attachments: diff.txt
> 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)
>             {
>                 AXIS2_ERROR_SET(env->error,
>                                 AXIS2_FAILURE);
>                 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_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.

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