cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: On finalize() potential issues
Date Tue, 07 Oct 2014 14:22:32 GMT

When IBM’s java 7 came out, we got bit by this pretty hard as it would garbage collect the
proxy before the invokes were complete.   Many of our system tests and such were failing.
  I did  a bunch of experimenting with the IBM jdk to find something that would work.   I
settled on:

git diff f6e9dfe11005696da3336accea722474c4f03a15..5517b8f1b755347f26aa3dcbad489b3e8cbbed37

which has seemed to fix things.   However, all of that work was back in 2012 before this presentation.
   I’d certainly be OK with flipping to volatile+static thing if that would be more reliable.

It’s actually a shame that the JAX-WS spec never actually mandated the Closable interface
on the proxies.   CXF’s proxies do, but not many know that.  (and for 3.1, we should add
AutoClosable).  Actually, if for the “cxf” frontend of the code generator, we COULD make
the SEI interface extend AutoClosable since we aren’t stuck with JAX-WS there and that could
make the CXF frontend MUCH more useful for pure CXF users, particularly with the try with
resources things.  Hmm….. something to think about….. 


On Oct 7, 2014, at 5:11 AM, Alessio Soldano <> wrote:

> Hi,
> some of you might already be aware that the finalize mechanism in the JVM is basically
flawed and there could be issues even when it's used for commonly accepted reasons (like cleaning
up stuff that the user forgot about). A very interesting presentation has been recently made
available on this topic, I suggest having a look at
> This said, it's many months (possibly years) since I started seeing infrequent transient
failures in the JBossWS <-> Apache CXF integration testsuite, usually caused by "Socket
closed" exceptions (here is an example,
To be honest, I have no proof this is actually related to the finalize() topic above, but
I'm wondering if anybody here ever seriously considered the potential issue.
> We do have a finalize() method in the ClientProxy, which calls the close() method which
in turn calls ClientImpl's destroy() method. That goes through multiple cleanup things, including
shutting down the Conduit, which is always based on URLConnection in my case. To give an idea
of the kind of issues, before you have a look at the presentation, especially on highly optimized
JDK, the finalize method might end up being called when the resources it's meant to cleanup
are still being used.
> Any thoughts?
> Cheers
> Alessio
> -- 
> Alessio Soldano
> Web Service Lead, JBoss

Daniel Kulp -
Talend Community Coder -

View raw message