Databinding itest locking up?

[Simon Laws <si...@googlemail.com>]

Following Sebastiens post about the databinding test locking up (he went
ahead and removed it from the itest pom to get the build to work) I tried
the test and, once I had changed the poms to depend on http-jetty as they
used to, I got the same effect of the test hanging. The process is sitting
with port 8080 in the CLOSE_WAIT state which basically means that the client
hasn't closed the socket correctly.

I went in and commented out the line

     //       requestMC.getOptions().setProperty(
HTTPConstants.REUSE_HTTP_CLIENT, Boolean.TRUE);

In Axis2TargetInvoker.invokeTarget which was instigated by TUSCANY-1218 [1]
and it worked again.  Now Sebastien did point out a fault/feature of the
itest. The way the databinding itests work as checked in is that they only
create one runtime for all the tests that are run. However it neglects to
call SCARuntime.stop() at the end. I have put this change into my local copy
and it still locks up when using REUSE_HTTP_CLIENT.

Anyone else seeing this kind of behaviour. All of the basic web services
tests work on my box and I don't see that the SDO databinding itest (the
test I'm trying at the moment) is doing anything different.

Also did the databinding itests run ok after the TUSCANY-1218 change was
applied. We could be dealing with some combination of the effect of that
change and the changes since then.

I should note that, in the past, I have not experienced the connection
refused error that originated 1218. Is there some kind of system setting
that's being toggled off again by the code change (just a stab in the dark)?

Simon

[1] http://issues.apache.org/jira/browse/TUSCANY-1218

Re: Databinding itest locking up?

[Simon Laws <si...@googlemail.com>]

On 4/24/07, Simon Laws <si...@googlemail.com> wrote:
>
> Following Sebastiens post about the databinding test locking up (he went
> ahead and removed it from the itest pom to get the build to work) I tried
> the test and, once I had changed the poms to depend on http-jetty as they
> used to, I got the same effect of the test hanging. The process is sitting
> with port 8080 in the CLOSE_WAIT state which basically means that the client
> hasn't closed the socket correctly.
>
> I went in and commented out the line
>
>      //       requestMC.getOptions().setProperty(
> HTTPConstants.REUSE_HTTP_CLIENT, Boolean.TRUE);
>
> In Axis2TargetInvoker.invokeTarget which was instigated by TUSCANY-1218
> [1] and it worked again.  Now Sebastien did point out a fault/feature of the
> itest. The way the databinding itests work as checked in is that they only
> create one runtime for all the tests that are run. However it neglects to
> call SCARuntime.stop() at the end. I have put this change into my local
> copy and it still locks up when using REUSE_HTTP_CLIENT.
>
> Anyone else seeing this kind of behaviour. All of the basic web services
> tests work on my box and I don't see that the SDO databinding itest (the
> test I'm trying at the moment) is doing anything different.
>
> Also did the databinding itests run ok after the TUSCANY-1218 change was
> applied. We could be dealing with some combination of the effect of that
> change and the changes since then.
>
> I should note that, in the past, I have not experienced the connection
> refused error that originated 1218. Is there some kind of system setting
> that's being toggled off again by the code change (just a stab in the dark)?
>
>
> Simon
>
> [1] http://issues.apache.org/jira/browse/TUSCANY-1218
>

After more investigation I find that the SDO Databinding itest locks up on
the third call (3 seems to be the magic number with these networking
problems) to an operation from within a single JUnit test method. So this
lock up is not to do with the way that the runtime is stopped.

As I mention above I find that I don't get the problem if REUSE_HTTP_CLIENT
is not set. The problem happens the third time the
MultiThreadedHttpConnectionManager goes to get a connection from the
connection pool. So I'm assuming that the connection in question is still
marked as being in use in some way. I put a workround in the code on my
machine. In Axis2TargetInvoker.invokeTarget I changed the code as follows
(line 78);

            operationClient.execute(true);

            MessageContext responseMC = operationClient.getMessageContext(
WSDLConstants.MESSAGE_LABEL_IN_VALUE);

+            operationClient.complete(requestMC);

Now I'm not exactly sure what effect the call to complete has in the case
where we are trying to REUSE_HTTP_CLIENT. It maybe that it kills the
connection and hence the connection can't be resused. I'd be interested to
know if others who were seeing the original "connection Refused" error that
TUSCAY-1218 was targetting see it come back. I didn't see them in the fisrt
place so it's difficult for me to say.  If no one objects I'll check this in
later.

[1] http://issues.apache.org/jira/browse/TUSCANY-1218