Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Subject: Re: Holding bus references
Date: Mon, 29 Nov 2010 14:04:51 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.36; KDE/4.5.3; x86_64; ; )
Cc: Benson Margulies <bimargulies@gmail.com>
References: <AANLkTi=gf8upoDFNeKg1tOq19zK6ZpD0BU-Gi12607Ns@mail.gmail.com>
In-Reply-To: <AANLkTi=gf8upoDFNeKg1tOq19zK6ZpD0BU-Gi12607Ns@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201011291404.51380.dkulp@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