Another strange stacktrace in agent log

Thomas Segismont tsegismo at redhat.com
Thu Feb 13 14:58:19 UTC 2014


Le 11/02/2014 18:17, Jay Shaughnessy a écrit :
> OK, sorry, I wasn't aware that we were already in this situation given
> Ian's work to address the concurrency issue at an earlier time. Although
> I realize that the CopyOnWriteArraySet implementation may not be
> necessary on the server-side the benefit gained is a simpler
> implementation overall.   And, we have seen instances of
> ConcurrentModificationException server-side, although I'm not sure it
> has affected Resource children.   I'm not sure we'll give up too much
> server-side as I think most of the childResources setting is done once,
> and child cardinality tends to be small.  Even if we took a hit in some
> areas of the code, I doubt it would be noticeable, in the overall scheme
> of things.
>
> The agent-side gets implicit thread-safety and would not need any
> changes/special case code.
>
> One thing I see in the branched impl is that we don't allow a null for
> childResources, when the custom Set is in place, the remove() method
> ensures an empty Set.  This may be OK but I think Heiko tried hard to
> ensure we don't have empty collections lying around agent-side.
>
> Anyway, I can go either way, but I'm attracted to the idea of a single
> Set impl for resource children.  Moreover, I think there are other Sets
> that could benefit.  A search of the server code shows several places
> where we copy child sets to avoid ConcurrentModExceptions (like
> childResourceTypes).
>
>

We can't have thread safety and ability to change the childResources 
field reference at the same time, unless we start to add some 
synchronization between the #set #remove and #add methods.

As I just said in a reply to the email from Lukas, the purpose of my 
change is:
* to have no impact on the current plugin container implementation
* to have very limited impact on memory consumption with respect to the 
effort put by Heiko recently

I'd like to see an implementation of the plugin container that does not 
rely on a JPA entity class, but this is too much work to be done before 
4.10 goes out.

Thomas


More information about the rhq-devel mailing list