[
https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565396#action_12565396
]
Dinesh Premalal commented on AXIS2C-791:
----------------------------------------
Hi Bill,
If time permits , please look into this issue. I guess you could resolve
this issue.
> 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]
