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 rt/frontend/simple/src/main/java/org/apache/cxf/frontend/ClientProxy.java 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….. Dan On Oct 7, 2014, at 5:11 AM, Alessio Soldano <[email protected]> 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 https://www.youtube.com/watch?v=UrGP6pfb0H8 . > 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" java.net.SocketException > exceptions (here is an example, http://www.fpaste.org/139814/41267248/raw/). > 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
