Answering my own question here, after consultation with some CXF devs.
The anwser is, the lists returned from interceptors are returned from
the InterceptorProviders can and should be thread-safe, but it's a
current limitation that they are not. I've submitted https://
issues.apache.org/jira/browse/CXF-480 and am running the build on a
patch, which I'll submit shortly.
This still does not mean that one is completely out of the woods --
concurrent access to the interceptor list is safe, but you are still
not guaranteed that another thread hasn't already added (or removed)
an interceptor you may be looking for as you traverse it.
In my particular case, this should not be an issue, since I have
control over which interceptor (types) I am looking for and
inserting, but buyer beware, in the general case.
I suppose a general pattern we might adopt and urge on applications
is to acquire a lock on the list, itself, whilst traversing and
inserting or removing elements, e.g.,
synchronized(interceptorList) {
// look for the interceptor I want to add
// if it's not there, add it
// leave a breadcrumb so I know I already inserted it
}
That sort of thing. Not sure what else can be said, other than a C++-
style ::insert.
Someone else mentioned that it might be nice to have he notion of an
interceptor id, which I'd fully agree with, so that you could do a
lookup by id. Your interceptor lists are then just (sortable) maps
(or multimaps, as the case may be), and lookup can be done in O(lg
n). But that's a pretty disruptive change to the whole
architecture. OTOH, better to do it now than once the cat is out of
the bag...
-Fred
On Mar 21, 2007, at 5:48 AM, Fred Dushin wrote:
Also, if interceptors are being added in the course of servicing a
request, does one have to take special care of thread-safety
issues? I understand the InterceptorProvider returns you a List by
reference, not a copy, so you are free to add, delete, traverse
elements, etc. But if you're in the context of a request, is there
any mechanism to lock access to the interceptor list, so that
someone else in your application with the same devious plan won't
walk over the same data at the same time? Am I completely missing
something about the architecture, here? It seems like modifying an
interceptor list in flight has ConcurrentModification exceptions
written all over it.
