axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senaka Fernando (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (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:17:08 GMT

    [ https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566456#action_12566456
] 

senakafdo edited comment on AXIS2C-791 at 2/6/08 10:16 PM:
-----------------------------------------------------------------

I strongly agree with what you say, Bill. I believe that the param checks or what so ever
portion of code, should not rectify a FAILURE into a SUCCESS. I think you have discovered
a critical bug, and which I believe can be solved in this manner.

* Set the status to FAILURE, if it was not a CRITICAL_FAILURE if it fails, or leave it as
it is for SUCCESS. *

I think that should be the way to go ahead. Also, I believe that the fix no 1, I provided,
is a mere camouflage as you say. I adopted that stratergy as I did not have any alternative.

I think we can do a post 1.3.0 fix to alter the behaviour of param checks, and make sure it
doesn't cause any havoc on un-obvious assumptions.

Thanks,
Senaka

      was (Author: senakafdo):
    I strongly agree with what you say, Bill. I believe that the param checks or what so ever
portion of code, should not rectify a FAILURE into a SUCCESS. I think you have discovered
a critical bug, and which I believe can be solved in this manner.

* Set the status to FAILURE, if it was not a CRITICAL_FAILURE if it fails, or leave it as
it is for SUCCESS. *

I think that should be the way to go ahead. Also, I believe that the fix no 1, I provided
by me is a mere camouflage as you say. I adopted that stratergy as I did not have any alternative.

I think we can do a post 1.3.0 fix to alter the behaviour of param checks, and make sure it
doesn't cause any havoc on un-obvious assumptions.

Thanks,
Senaka
  
> 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: https://issues.apache.org/jira/browse/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
>            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 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_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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message