cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Holding bus references
Date Mon, 29 Nov 2010 19:19:51 GMT
OK, I'll unwind.

On Mon, Nov 29, 2010 at 2:04 PM, Daniel Kulp <> wrote:
> 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