axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Schöning (JIRA) <>
Subject [jira] [Commented] (AXIS2-5775) upgrading from axis2 1.4 to 1.6.4
Date Thu, 17 Jan 2019 19:12:00 GMT


Thorsten Schöning commented on AXIS2-5775:

Couldn't upgrade Axis 2 yet and thought giving it a try to find the root cause of this, maybe
I'm doing something wrong and could fix this. Here's what I've found so far:

For some reason this problem always only occurs with "invokeRobust", I have no case where
it occurred with "invokeBlocking". Additionally, in my case I'm configuring some HTTP connection
manager within the configuration context provided by the service client and that configuration
does call "ConfigurationContext.getProperty" in the end, which leads to a call to "AbstractContext.needPropertyDifferences"
in theory as well. Exactly that call is the one failing later because of a missing "AxisConfiguration"
most likely. OTOH, during creation of an instance of "ServiceClient", that client is configured
assuming an "AxisConfiguration" to be available always and that never fails with a NPE. So,
for some reason whenever a response is received and Axis tries to manage some internal state,
"AxisConfiguration" seems to be missing.

        if (statusCode == HttpStatus.SC_OK) {
            // Save the HttpMethod so that we can release the connection when cleaning up
270         msgContext.setProperty(HTTPConstants.HTTP_METHOD, method);
            processResponse(method, msgContext);
        } else if (statusCode == HttpStatus.SC_ACCEPTED) {

I have the feeling that for some reason there are different "ConfigurationContext" in use
or "terminate" has been called already. That is nulling "AxisConfiguration" by purpose:

        if (axisConfiguration != null) {
            this.axisConfiguration = null;

But I didn't find an obvious caller of that method in my context. Additionally, it can not
be that simple, because the problem doesn't happen always. Instead I have the feeling it has
to do with multiple threads somehow. I'm using those wherever the problems occurs, but I'm
not sharing clients by those threads and instead creating individual instances per thread

I've found that the "MessageContext" is thread-local, so it might be that some "ConfigurationContext"
is reused by different threads successively and maybe garbage collection of Java is calling
"ConfigurationContext.terminate" at some point, because it is called by "ServiceClient.cleanup",
which is called by "ServiceClient.finalize". I currently don't call "cleanup" on my own.

    protected void finalize() throws Throwable {
        try {
        } finally {

       } else {

> upgrading from axis2 1.4 to 1.6.4
> ---------------------------------
>                 Key: AXIS2-5775
>                 URL:
>             Project: Axis2
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.6.4
>            Reporter: Rajesh
>            Priority: Major
> Hi All,
> This is related to existing JIRA AXIS2-5774.
> We are upgrading from axis2 1.4 to 1.6.4. We upgraded successfully and got response from
provider with execute() method.
> After 4 to 8 request , the service is throwing below error intemittently.
> (Modified now)
> Error:
> =======================
> at org.apache.axis2.engine.AxisEngine.send(
> 	at org.apache.axis2.description.OutInAxisOperationClient.send(
> 	at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(
> 	at org.apache.axis2.client.OperationClient.execute( 
> =========================
> So we added few logging to Kernel 1.6.4 and found that after few request Cleanup() method
in the serviceclient is cleaning the AxisConfiguration,hence the following request getting
failed with Null error.
> Also we see changes in AxisCOnfiguration in 1.4 and 1.6.4 in Cleanup method().
> Is this the normal behaviour in axis2 1.6.4?

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message