Another strange stacktrace in agent log

Thomas Segismont tsegismo at redhat.com
Thu Feb 13 14:27:51 UTC 2014


Le 12/02/2014 15:07, Lukas Krejci a écrit :
> On Tuesday, February 11, 2014 12:17:05 Jay Shaughnessy wrote:
>> >Hi Thomas,
>> >
>> >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).
>> >
> IMHO, ResourceTypes are readonly structures on agent side, because any change
> to a resource type (i.e. a plugin) requires a restart of plugin container
> anyway.
>
> Therefore I'd vote for going an extra mile and actually DROP all the results
> of plugin descriptor parsing once we're done with them during startup and have
> immutable impl. of resource types on the agent side, possibly with arrays
> instead of sets/lists/whatever (of course, that depends on how we use those -
> for example we would have to think how to sort the arrays so that we can
> efficiently search in them, etc).
>
> Having immutable data structures gives us 2 things:
> * implicit thread-safety
> * chance to minimize memory usage by using minimalistic data-structures
>
> Of course, this would not be a simple change because it would basically mean
> "forking" resource/resourceType data structures for the agent-side but I do
> believe it would give us both speed boost and memory footprint decrease.
>

That would be a good thing to investigate when we'll work on the next 
major version. But the purpose of my change is really:
* 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



More information about the rhq-devel mailing list