[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.

["Bill Mitchell (JIRA)" <ji...@apache.org>]

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

Bill Mitchell commented on AXIS2C-791:
--------------------------------------

On testing again with source through svn revision 599502, I see different but still problematic behavior.  When the URL specified does not point to a running/listening server system, my client sees error 82, Input stream is NULL in message context.  

Stepping through the code, what I observe is:
(a) In axis2_http_transport_sender_write_message, after calling AXIS2_HTTP_SENDER_SEND, the error number is a valid 74, AXIS2_ERROR_HTTP_CLIENT_TRANSPORT_ERROR.
(b) But later in the code, when it is determined that the message is not output only, the call to axis2_http_transport_utils_create_soap_msg() replaces this error with the less informative error 82.  

Unless I'm missing something, like there is some path for retrying write operations, it seems to me that the initial send error number should be returned directly, as happens in the out-only path irrespective of whether an error occurs.  In particular, I would think that:
(1) In http_transport_sender.c, axis2_http_transport_sender_write_message(), if the status is not success on a two-way message exchange, it should return the error it already has without trying to process the non-existent response envelope.  
(2) In http_transport_sender.c, axis2_http_transport_sender_invoke() should return failure status if axis2_http_transport_sender_write_message fails, instead of ignoring returned status.
(3) In engine.c, axis2_engine_send(), should return failure if AXIS2_TRANSPORT_SENDER_INVOKE fails, instead of ignoring the returned status.  

> 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: Dinesh Premalal
>            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 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