[
https://issues.apache.org/jira/browse/AXIS2C-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell updated AXIS2C-791:
---------------------------------
Attachment: diff.txt
Senaka, I worried some about the changes to axis2_op_client_add_msg_ctx. But
when I saw that the code already treaterlater on the case of the incoming
message_ctx value being zero, I inferred that the author intending zero to be a
normal case. It does not surprise me that allowing it to go through this path
again uncovered the absence of a guard on the op_ctx pointer in the client
being zero, and that this would show up on some path not exercised in the SOAP
flow I tested.
When I looked at your changes in axis2_op_client_two_way_send, I worried that
they defeated the entire purpose of my initial issue. Artificially generating
a 75 error might camoflage the error reported at the lower layer. Albeit in my
testing the lower layer reported an error 74, almost the same error. But in
fact your change here had no effect on the test, as the env error status_code
value is false at this point, and gets clobbered to be true at the
AXIS2_PARM_CHECK call at the beginning of axis2_op_client_add_msg_ctx. So your
change here does no harm, and may remedy some problem, but it does not remedy
the problem behavior you saw.
I observed this same behavior myself, that lower level routines would post an
error number, but that the status code would frequently be changed back to
success on the way out. So I inferred that the convention was the caller
should not trust the status code, but rather if a null pointer is returned for
the response message, the caller should recognize the presence of an error and
grab the error number. You suggest that the env status code should always
indicate whether an interesting error number is present. That's a perfectly
good convention as well, it is clear and understandable, but it means that all
the routines on the exit paths from the lower levels back out must not modify
the status code when an error is already present, else they will mask the real
error -- exactly the problematic behavior I reported.
Unfortunately, the standard macros AXIS2_PARAM_CHECK and AXIS2_FUNC_PARAM_CHECK
do just that. They report an error if the parameter is null, but they also
change the status to success when no error is detected.
As a brute force solution to the problematic behavior I reported, I have gone
through all the offending routines on the error path from two-way send and
changed these to avoid the AXIS2_PARAM_CHECK, to do their own testing inline,
and fail appropriately without modifying the env status code when the incoming
parameter is valid. (See the attached diff for the affected routines.) At
best, this is a fragile solution, as it will be easy for someone to
inadvertently introduce new instances of AXIS2_PARAM_CHECK in these or other
routines that happen to be used on the error exit path. My suggestion, for
discussion, is that AXIS2_PARAM_CHECK and AXIS2_FUNC_PARAM_CHECK routines
should never set the env status code to success. Rather, the env status code
should be set to success only at the initial outer entry points to the main
component routines, and wherever a reported error is ignored and processing
continues. But implementing this suggestion requires someone spend a fair
amount of time introducing the clearing of the status code in the right places,
and the odds are the results will not be perfect on the first pass.
Needless to say, I did verify that in my test case, where the server never
responds to the connect request, the error number is returned and the status
code of failure is now returned all the way out through the generated adb stubs
to the application.
The attached diff was incorporated in svn rev 619201.
> 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]
