CDV ❯ Replicated cache events on TC clustered caches may not work in all configurations

• Type: Bug
• Status: Closed
• Priority: 2 Major
• Resolution: Fixed
• Component/s:
• Labels:

• Assignee: teck
• Reporter: teck
• Created: August 03, 2011
• Votes: 1
• Watchers: 0
• Updated:

  July 27, 2012
• Resolved:

  August 09, 2011

Description

This scenario came up in an OSGi context but the issue isn’t necessarily specific to that environment.

When cache events are replicated to other nodes in the cluster via TerracottaCacheEventReplication/TerracottaCacheEventReplicationFactory it is possible that the element cannot be deserialized on the remote node. This is not a fatal error but an exception will be logged.

https://jira.terracotta.org/jira/secure/EditIssue!default.jspa?id=31708There is a problem in how we a classloader is selected when deseriaizing in this context. For normal get() calls on the cache we first use TCCL and fallback to the defining loader of the cache. When these replicated cache events are being procesed however this is not done by an application thread (in our case it is the DMI stage thread), therefore TCCL is of no use in this context, and the defining loader of ehcache is also not appropriate (assuming ehcache and the app are in different osgi bundles).

The closest thing I can think of to mirror how get() works in terms of classloading is to use the defining classloader of each registered event listener. The way things are wired however that might be a large change.

Comments