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/20 22:18:29 UTC
Why isn't BusFactory.defaultBus a leakage opportunity?
It's not weak. Nothing ever sets it to null. I propose to declare it
as a WeakReference.
Re: Why isn't BusFactory.defaultBus a leakage opportunity?
Posted by Alessio Soldano <as...@redhat.com>.
mmh, you're right, if someone explicitly set the default / thread bus,
we can't afford to have that GC-ed, as we can't be sure we'll be able to
re-create an equivalent one later, while the user would expect that to
be in place.
To be honest, even this solution (soft ref for bus created by magic)
might expose to possible side effects, given -for instance- the bus
creation process depends on the current thread context classloader. This
argument is probably something not that relevant after all, but I still
believe this kind of changes should be documented / included in
migration notes [1].
Cheers
Alessio
[1] btw, I think the other changes for CXF-3142 have been merged to
2.3.x already by Dan, right?
On 11/23/2010 10:50 PM, Benson Margulies wrote:
> An additional thought:
>
> if a bus is being created 'by magic', refer to it softly, either
> default or per-thread.
>
> If someone, on the other hand, makes an _explicit_ call to set a
> default bus, reference it strongly.
>
>
> On Tue, Nov 23, 2010 at 4:15 PM, Benson Margulies<bi...@gmail.com> wrote:
>> I just realized that I didn't really do the whole job. Arguable, the
>> per-thread busses should be sitting in a
>>
>> WeakHashMap<Thread, Reference<Bus>>, with SoftReferences. Otherwise,
>> the implicit bus hangs around just as effectively as it's creating
>> thread's default bus.
>>
>> That make sense?
>>
>>
>> On Tue, Nov 23, 2010 at 3:06 AM, Alessio Soldano<as...@redhat.com> wrote:
>>> Hi Benson,
>>> don't get me wrong, I'm fine with the changes, just saying that this needs
>>> to be documented :-)
>>> Cheers
>>> Alessio
>>>
>>> On 11/22/2010 07:43 PM, Benson Margulies wrote:
>>>> But the GC will only hammer you if you are low on memory, no?
>>>> Particularly if it's soft. If you are that low on memory, isn't
>>>> recreating the CXF bus all the time the least of your performance
>>>> problems?
>>>>
>>>> I feel a need to win an argument here; I'll change to Soft, and if you
>>>> don't want to migrate, don't migrate.
>>>>
>>>>
>>>> On Mon, Nov 22, 2010 at 12:30 PM, Alessio Soldano<as...@redhat.com>
>>>> wrote:
>>>>> +1 on adding this to the migration notes, this could be a major change
>>>>> for
>>>>> those just using jaxws api
>>>>>
>>>>>
>>>>> On 11/22/2010 05:34 PM, Daniel Kulp wrote:
>>>>>> On Saturday 20 November 2010 4:18:29 pm Benson Margulies wrote:
>>>>>>> It's not weak. Nothing ever sets it to null. I propose to declare it
>>>>>>> as a WeakReference.
>>>>>> There are SOME usage patterns that this change would make much slower.
>>>>>> I'm
>>>>>> thinking of the case where you use the pure JAX-WS API's and just
>>>>>> create
>>>>>> clients as needed, make a call, discard the client. In that case, the
>>>>>> Bus
>>>>>> would then be dereferenced and GC'd. That would cause everything that
>>>>>> it
>>>>>> caches (like the WSDL's) to also be GC'd. Thus, the next client to be
>>>>>> created
>>>>>> needs to re-create it all. Obviously the workaround is to have them
>>>>>> hold
>>>>>> the bus strongly someplace (or re-use the proxies), but it is a behavior
>>>>>> change.
>>>>>>
>>>>>> I think I'd suggest two things:
>>>>>>
>>>>>> 1) This should only be done on trunk (and migration note it for 2.4)
>>>>>> 2) Change to a SoftReference, not a WeakReference. Should mitigate the
>>>>>> issue
>>>>>> a bit.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>> --
>>>>> Alessio Soldano
>>>>> Web Service Lead, JBoss
>>>>>
>>>>>
>>>
>>> --
>>> Alessio Soldano
>>> Web Service Lead, JBoss
>>>
>>>
--
Alessio Soldano
Web Service Lead, JBoss
Re: Why isn't BusFactory.defaultBus a leakage opportunity?
Posted by Benson Margulies <bi...@gmail.com>.
An additional thought:
if a bus is being created 'by magic', refer to it softly, either
default or per-thread.
If someone, on the other hand, makes an _explicit_ call to set a
default bus, reference it strongly.
On Tue, Nov 23, 2010 at 4:15 PM, Benson Margulies <bi...@gmail.com> wrote:
> I just realized that I didn't really do the whole job. Arguable, the
> per-thread busses should be sitting in a
>
> WeakHashMap<Thread, Reference<Bus>>, with SoftReferences. Otherwise,
> the implicit bus hangs around just as effectively as it's creating
> thread's default bus.
>
> That make sense?
>
>
> On Tue, Nov 23, 2010 at 3:06 AM, Alessio Soldano <as...@redhat.com> wrote:
>> Hi Benson,
>> don't get me wrong, I'm fine with the changes, just saying that this needs
>> to be documented :-)
>> Cheers
>> Alessio
>>
>> On 11/22/2010 07:43 PM, Benson Margulies wrote:
>>>
>>> But the GC will only hammer you if you are low on memory, no?
>>> Particularly if it's soft. If you are that low on memory, isn't
>>> recreating the CXF bus all the time the least of your performance
>>> problems?
>>>
>>> I feel a need to win an argument here; I'll change to Soft, and if you
>>> don't want to migrate, don't migrate.
>>>
>>>
>>> On Mon, Nov 22, 2010 at 12:30 PM, Alessio Soldano<as...@redhat.com>
>>> wrote:
>>>>
>>>> +1 on adding this to the migration notes, this could be a major change
>>>> for
>>>> those just using jaxws api
>>>>
>>>>
>>>> On 11/22/2010 05:34 PM, Daniel Kulp wrote:
>>>>>
>>>>> On Saturday 20 November 2010 4:18:29 pm Benson Margulies wrote:
>>>>>>
>>>>>> It's not weak. Nothing ever sets it to null. I propose to declare it
>>>>>> as a WeakReference.
>>>>>
>>>>> There are SOME usage patterns that this change would make much slower.
>>>>> I'm
>>>>> thinking of the case where you use the pure JAX-WS API's and just
>>>>> create
>>>>> clients as needed, make a call, discard the client. In that case, the
>>>>> Bus
>>>>> would then be dereferenced and GC'd. That would cause everything that
>>>>> it
>>>>> caches (like the WSDL's) to also be GC'd. Thus, the next client to be
>>>>> created
>>>>> needs to re-create it all. Obviously the workaround is to have them
>>>>> hold
>>>>> the bus strongly someplace (or re-use the proxies), but it is a behavior
>>>>> change.
>>>>>
>>>>> I think I'd suggest two things:
>>>>>
>>>>> 1) This should only be done on trunk (and migration note it for 2.4)
>>>>> 2) Change to a SoftReference, not a WeakReference. Should mitigate the
>>>>> issue
>>>>> a bit.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>
>>>> --
>>>> Alessio Soldano
>>>> Web Service Lead, JBoss
>>>>
>>>>
>>
>>
>> --
>> Alessio Soldano
>> Web Service Lead, JBoss
>>
>>
>
Re: Why isn't BusFactory.defaultBus a leakage opportunity?
Posted by Alessio Soldano <as...@redhat.com>.
+1 on adding this to the migration notes, this could be a major change
for those just using jaxws api
On 11/22/2010 05:34 PM, Daniel Kulp wrote:
> On Saturday 20 November 2010 4:18:29 pm Benson Margulies wrote:
>> It's not weak. Nothing ever sets it to null. I propose to declare it
>> as a WeakReference.
> There are SOME usage patterns that this change would make much slower. I'm
> thinking of the case where you use the pure JAX-WS API's and just create
> clients as needed, make a call, discard the client. In that case, the Bus
> would then be dereferenced and GC'd. That would cause everything that it
> caches (like the WSDL's) to also be GC'd. Thus, the next client to be created
> needs to re-create it all. Obviously the workaround is to have them hold
> the bus strongly someplace (or re-use the proxies), but it is a behavior
> change.
>
> I think I'd suggest two things:
>
> 1) This should only be done on trunk (and migration note it for 2.4)
> 2) Change to a SoftReference, not a WeakReference. Should mitigate the issue
> a bit.
>
> Thoughts?
>
--
Alessio Soldano
Web Service Lead, JBoss
Re: Why isn't BusFactory.defaultBus a leakage opportunity?
Posted by Daniel Kulp <dk...@apache.org>.
On Saturday 20 November 2010 4:18:29 pm Benson Margulies wrote:
> It's not weak. Nothing ever sets it to null. I propose to declare it
> as a WeakReference.
There are SOME usage patterns that this change would make much slower. I'm
thinking of the case where you use the pure JAX-WS API's and just create
clients as needed, make a call, discard the client. In that case, the Bus
would then be dereferenced and GC'd. That would cause everything that it
caches (like the WSDL's) to also be GC'd. Thus, the next client to be created
needs to re-create it all. Obviously the workaround is to have them hold
the bus strongly someplace (or re-use the proxies), but it is a behavior
change.
I think I'd suggest two things:
1) This should only be done on trunk (and migration note it for 2.4)
2) Change to a SoftReference, not a WeakReference. Should mitigate the issue
a bit.
Thoughts?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog