cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: svn commit: r541364 [1/2] - in /incubator/cxf/trunk: api/src/main/java/org/apache/cxf/endpoint/ rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/ rt/core/src/main/java/org/apache/cxf/endpoint/ rt/core/src/main/resources/META-INF/c...
Date Thu, 24 May 2007 22:21:20 GMT
On Thursday 24 May 2007 17:54, Andrea Smyth wrote:
> Yes, and this can be improved upon slightly by creating the RMEndpoint
> only when there actually are messages to recover and resend. Otherwise
> the creation of the RMEndpoint can be deferred until the client makes
> its first request. Normally that should not make much of a difference
> though.
> If there is concern about the growth of the reliableEndpoint map in an
> application with many shortlived clients using RM, 

I'm more concerned about the case where the application has one client 
using RM (so the store/etc... is created), and a BUNCH of other short 
lived clients not using RM.    

Right now, it looks like all the other short lived clients end up in that 
map where they are held onto forever. 

> I would recommend 
> that the application tells the runtime when it's done with a
> particular client as the RMEndpoint object will then be removed from
> the map.

My point is that from a pure JAX-WS application, there isn't a way to do 
that.   By default, it cannot hold onto anything strongly.


> >It looks like for normal cases (RM not used), store is null so it's
> > not a problem.
> >
> >However, my major issue, I guess, is the API kind of implies that
> >the "ClientLifeCycleManager.clientDestroyed(...)" method will always
> > be called.   I just don't see that as being true.   I actually
> > expect it to rarely be called.
>
> It's only called when  the application explicitly informs the runtime
> that a is destroyed. In connection with RM users may want  to
> terminate the client's current sequence when it is clear that no more
> messages will be sent in the context of this sequence.
> Also, clients that use non-anonymous ReplyTo, with or without RM, may
> want to indicate that the ReplyTo, AcksTo listener on the client side
> can be shut down.
> If you prefer other names for the APIs I can of course change them.

No, the name is fine.   However, it needs some strong javadocs that warn 
against holding onto stuff using strong references and also warning that 
clientDestroyed is likely to not be called at all.

Honestly, I think the RM stuff should change to using WeakReferences and 
a ReferenceQueue for almost everything.   When the client is garbage 
collected, it can then clean things up.    Other 
ClientLifeCycleListeners should be encouraged to do the same thing.

Looking at the code, RM just uses the client to get the endpoint.  Thus, 
you probably could do something like:
Map<WeakReference<Client>, Endpoint>....

when the client is GC'd, you could still use the endpoint to clean things 
up.   Slightly tricky, but certainly more reliable than expecting users 
to call a non-existent (according to spec) destroy method. 

The other option is to put finalize methods on the clients, but I hate 
doing that cause finalize methods KILL GC performance.


-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message