On Thu, Apr 10, 2008 at 11:59 AM, Ramkumar R <[EMAIL PROTECTED]> wrote:
> Hi All,
> Looking at the history of JIRA's (2170, 2085, 2092) raised due to
> ConcurrentModificationException, its evident that our runtime would throw
> more such exceptions in the coming days, such problem occurs if two
> threads
> try to add a contribution simultaneously. Also the above mentioned JIRA's
> gives us a clue that mostly these issues are noticed for the
> ExtensionPoint
> implementation classes.
>
> Current Implementation of ExtensionPoint classes use either ArrayList OR
> HashMap to maintain the list of processors, listeners, factories and
> providers. Basically the Implementation of ArrayList & HashMap are not
> synchronized, hence If multiple threads try to access an ArrayList/HashMap
> instance concurrently, and at least one of the threads modifies the
> list/map
> structurally, it must be synchronized externally. Hence a fix is required
> for these classes, *please have a look at JIRA-2170 comments for more
> details on the implemented solution*.
>
> As a precautionary measure, I like to raise a JIRA for all the
> ExtensionPoint classes to provide this fix for the above said issue,
> before
> we encounter them one by one. Before I go ahead, I like to hear from
> people
> about their thought on this regard. Thanks.
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
Hi Ram
We need to be a little careful here. In general it's good to ensure thread
safety of the underlying collections but we also need to consider the wider
context and make sure we aren't masking other problems by fixing the
underlying errors.
For example, in TUSCANY-2092, the wider issue seems to be that the
loadListeners() method is not synchronized and hence runs twice when it
should only run once. Synchronizing the collection will ensure that the
error isn't thrown but we will likely end up with a list that is twice as
long as we expect it to be. This is because the test at the start of
loadListeners(),
if (loadedListeners)
return;
won't prevent multiple concurrent threads getting in here. In which case
each thread will load the listeners and we will end up with a list that is
twice as long as we expect it to be. There may be similar wider implications
in the other JIRA and certainly 2085 looks like it could suffer from the
same problem if the first two messages through the runtime required access
to databindings concurrently. It would be worth double checking these JIRA
to ensure that we aren't masking other issues by fixing the collections.
I would suggest setting up an itest to do some simple concurrency testing
by, in the first instance, loading two contributions concurrently and
sending multiple messages concurrently. We can then extend in the future if
required. I don't think there is a test for this already. There is a test
that sends many OneWay messages but that's not quite the same thing.
Regards
Simon
