[
https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566477#action_12566477
]
Senaka Fernando commented on AXIS2C-791:
----------------------------------------
Hi once again,
I saw your modifications. That's something really nice to be doing. Actually,
why bother to use the param check. But, one word of caution. You also got to do
this, Bill. AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE); So that we know
for sure the error has been neatly set.
Anyway, my latest modification will not be requiring this change.
Regards,
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
