When you say GmsImpl are you talking about org.jgroups.protocols.pbcast/GmsImpl?
If that's the case, the problem extends far beyond whether a field in that class is static. It implies the entire cache is being serialized, which is certainly not an intended behavior.
What are you putting in the List?
Yes, I'm talking about GmsImpl from jGroups package.
Actually we append so called value object to the List. That object is Serializable but not annotated to be aspectized.
In turn, the object has two references to other objects wich are annotated and aspectized accordingly and they are not stored in the cache.
Do you see any misuse here?
What version of JBoss Cache is this?
To restate what I think I've heard:
You put an aspectized pojo in the cache.
The pojo has a field of type List.
A Serializable object (non-aspectized) is placed in the List.
That object has a ref to 2 aspectized pojos, but those pojos were never placed in the cache.
That sounds fine. PojoCache should treat the non-aspectized object as opaque, so the fact that the other 2 pojos were aspectized shouldn't matter. Particularly if the cache never saw the 2 pojos directly.
Do the last two pojos have a reference to anything that was put in the cache?
Like Brian mentioned, you should not see JGroups classes being serialize/marshalled. My guess is your POJO somehow has reference to the cache itself and thus causing it to serialize?
It's JBossCache 1.4.0SP1.
Your restatement is correct, Brian, more specifically:
1. We put aspectized Participant object in the cache
2. We add Message object to the Participant.newMessages List
3. Message object has reference sender to Participant object and reference recipient to Recipient object which class is an abstract super class of Participant object class.
4. Recipient class declared with @InstanceOfPojoCacheable
5. So, both, sender and recipient are aspectized but are not in the cache
6. recipient in this case is a Conference object which has List of its Participants
7. In turn, Participant has a List of Conferences it participates in.
8. Actually, all these POJOs are [derived from] ValueObjects with a HashMap of attributes.
We debugged the deadlock again and found out that during serialization of the first sender's Conference attributes the framework (RegularObjectPersister.writeSlotWithFields()) tries to serialize MarshalledClassProxy which substitutes? attributes.
And here the whole story begins.... MarshalledClassProxy.advisor gets serialized and this leads to whole cache serialization.
Hope this explanation helps :)
OK, your Message object is not PojoCacheable, but in its object graph is a ref to a Collection/Map proxy that PojoCache has created (i.e. it's a Collection/Map that's stored in the cache either directly or as a field of a PojoCacheable object.)
This leads to http://jira.jboss.com/jira/browse/JBCACHE-830.
1) Make Message PojoCacheable. If all the classes are PojoCacheable, the cache can detect this kind of situation and deal with it.
2) Figure out where the ref to the cached Collection/Map is coming from. Change the code so a defensive copy of it is stored instead of a reference to the same object.
Brian, thanks a lot for pointing to the problem.