cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Holding bus references
Date Mon, 29 Nov 2010 19:04:51 GMT
On Thursday 25 November 2010 11:39:07 am Benson Margulies wrote:
> I bet that Dan is his usual overtaxed self, but I'm restarting this
> thread to attract his attention, since I fear that I've dug us into a
> whole.
> The idea of a default, or thread default, bus in CXF is modelled, in
> some respects, on the thread context class loader. However, there's
> one big difference.
> A thread has no context class loader until some gives it one. (The
> initial thread gets one if you are launched from the java command).
> So, since some piece of code has to take explicit action to put a
> reference to a class loader in there, no one can claim to be surprised
> if that class loader is protected from GC for the life of the thread
> or until someone takes the reference back out.
> Our situation, unfortunately, is more complex, insofar as busses
> become default in some rather unpredictable ways. The CXFBusImpl
> constructors and the CXFBusFactory call the all-too-accurately named
> 'perhapsSetDefaultBus'.
> This seems to me to blow up the distinction I tried to draw in recent
> email between implicit and explicit busses. Some piece of code uses
> one of them to create an 'interesting' bus. If we hold a hard
> reference, then that bus might amount to a memory leak. If we hold a
> soft reference, that bus might evaporate out from under them, leading
> to a surprise.
> This seems to me to leave us with two choices. (1) undo what I did,
> and replace it with a lot of documentation warning people that they
> need to be careful to call setDefaultBus(null) or
> setThreadDefaultBus(null) to turn off leaks.
> (2) remove the setting of a default bus from the two mechanisms above.
> If someone wants to create a bus for themselves, and use it as a
> default (as opposed to passing it into the API), they should tell us
> so explicitly (via extra booleans in that API). If they don't *ask*
> for a default, the default remains null.
> This is fairly conspicuous in the incompatibility dept, all to save
> having to tell people to make one or two calls to ensure that CXF
> isn't holding a default bus reference that they don't want. So I'm
> leaning to (1), but I'd like to hear from Dan and any other concerned
> parties.

Honestly, I'm kind of leaning toward #1 as well.   If we find places where we 
are "leaking" things (like in the  maven plugins or tooling), we should 
definitely fix those cases to make sure anything gets set gets unset.

Daniel Kulp

View raw message