You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2010/11/25 17:39:07 UTC
Holding bus references
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.
Re: Holding bus references
Posted by Benson Margulies <bi...@gmail.com>.
OK, I'll unwind.
On Mon, Nov 29, 2010 at 2:04 PM, Daniel Kulp <dk...@apache.org> 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
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: Holding bus references
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://dankulp.com/blog