[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
