You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Dzmitry Kazimirchyk (JIRA)" <ji...@apache.org> on 2011/08/23 17:29:29 UTC
[jira] [Closed] (CAY-1602) OSCache clustering should be shared per
JVM - @CacheGroup annotation causes creation of too many cluster listeners
[ https://issues.apache.org/jira/browse/CAY-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dzmitry Kazimirchyk closed CAY-1602.
------------------------------------
Resolution: Fixed
Fix Version/s: 3.1M3
Since CAY-1537 have been implemented, suppose this fixed.
> OSCache clustering should be shared per JVM - @CacheGroup annotation causes creation of too many cluster listeners
> ------------------------------------------------------------------------------------------------------------------
>
> Key: CAY-1602
> URL: https://issues.apache.org/jira/browse/CAY-1602
> Project: Cayenne
> Issue Type: Bug
> Components: Core Library
> Affects Versions: 3.1M2
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
> Fix For: 3.1M3
>
>
> This issue exists in 3.0.x in theory, but is probably not as visible due to different cache access patterns. It became very visible in 3.1. See the internal bug report from my company project below for the symptoms. The cause is that temporary throwaway ObjectContexts in an app that themselves do not have any queries with LOCAL_CACHE, and hence shouldn't have associated QueryCache instances, on commit process @CacheGroup annotations and dispatch query cache events. In case of OSCache provider and JGroups clustering, this causes creation of JGroups listeners per ObjectContext, potentially straining the cluster and using extra resources.
> Will need to implement OSQueryCacheProvider that creates multiple OSCache instances with the same clustering provider , or alternatively, implement a shared cache with local cache regions per CAY-1537 (meaning fixing CAY-1537 will be equivalent to fixing this bug).
> ----
> When doing some editor work, I've been watching the site log to ensure that clustering works... Say I am saving an article in the editor. I get this output in the log:
> [13/Aug/2011:20:58:04] Incoming-1,OSCacheBus,us-rs02-18026 INFO JGroupsBroadcastingListener: A new member at address 'us-rs02-50475' has joined the cluster
> [13/Aug/2011:20:58:04] Incoming-1,OSCacheBus,us-rs02-18026 INFO AbstractBroadcastingListener: Cluster notification (type=2, data=article) was received.
> Saving it again, getting the same 2 lines again:
> [13/Aug/2011:20:59:34] Incoming-2,OSCacheBus,us-rs02-18026 INFO JGroupsBroadcastingListener: A new member at address 'us-rs02-35790' has joined the cluster
> [13/Aug/2011:20:59:34] Incoming-2,OSCacheBus,us-rs02-18026 INFO AbstractBroadcastingListener: Cluster notification (type=2, data=article) was received.
> The second line is correct, however the first line " A new member at address 'us-rs02-35790' has joined the cluster" is suspect - a cluster member once joined should stay in the cluster, so not sure hwy it joins on every event. This can create a potential resource leak I guess, so while not critical, we need to investigate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira