OK I did some digging. 1. The ClusterTrackingService seems to be little more than a complicated cover over a cluster-wide distributed cache of users and app server ids. 2. Outside of the cluster bundle, only 2 or 3 methods of the CTS are ever used. 90% of the time its to get the name of the current app server.
bundles/files/.../CreateContentPoolServlet.java Uses CST to generate the poolId bundles/search/.../DeletedPathsServiceImpl.java Deletes paths from all server content caches when content is deleted bundles/events/.../OsgiJmsBridge.java Get the server id to mark messages with the originating server. bundles/trustedauth/.../TrustedTokenServiceImpl.java Get the server id to set up local trust stores. Here goes the ClusterUserMessageListener. That class listens on a per-server topic yes. 1. When it receives a message it looks for 4 items: from-server, to-server, remoteUser, and trackingCookie. 2. It them promptly drops that information by calling clusterTrackingServiceImpl.pingTracking(trackingCookie, remoteUser, false) and exiting. That last false parameter is important because it causes the CTSImpl.pingTracking not to call CTSImpl.pingRemoteTracking. So we never post to the other server topics. The ClusterTrackingFilter DOES call pingRemoteTracking with the last argument set to true. I'm not sure what value it has though. What value is it to another app node to know "Erik just signed in on app2"? My user record will be in the clustered cache if another app server tried to look me up. Maybe someone knows better? We've been running a few clusters in production without clustered AMQ installations and haven't seen any ill-effects. I've read Ian's rationale behind this a few times and I still don't get it. https://confluence.sakaiproject.org/display/KERNDOC/KERN-537+Cluster+Tracking+Service Erik On Fri, Aug 10, 2012 at 9:36 AM, Zach A. Thomas <zach.tho...@gmail.com> wrote: > Yes, please. As far as I’m concerned, anyone should feel free to update any > documentation at any time. An overabundance of edits to our documentation is > not currently a problem we have! > > The reason ActiveMQ clustering is in there is this guy: > https://github.com/sakaiproject/nakamura/blob/master/bundles/cluster/src/main/java/org/sakaiproject/nakamura/cluster/ClusterUserMessageListener.java > > Every server listens on a unique, per-server topic, but they only post events > to other servers’ topics (in ClusterTrackingServiceImpl). I inferred from > this that JMS would need to be clustered. > > Can you confirm that ClusterUserMessageListener is never used? If so, we can > (and should) delete it along with the code that posts to those topics. > > Zach > > On Aug 9, 2012, at 10:34 AM, Erik Froese <erik.fro...@gmail.com> wrote: > >> I'm not a core team member so I don't know if I can call for a vote or not. >> I'd appreciate an up down on these following changes to the OAE >> cluster setup confluence document. >> >> https://confluence.sakaiproject.org/display/KERNDOC/OAE+Cluster+Setup >> >> 1. Remove the custom repository.xml and references to connecting >> Jackrabbit to MySQL (or other persistant storage) >> >> This is not necessary anymore. Everything in the JCR should be present >> in the UX bundle. >> If your institution MUST insert assets at run time they still have to >> be inserted on each app server as we don't provide or recommend JCR >> clustering (Apparently it scale well unless you run CRX) >> >> It's been a cause of pain for new adopters over and over again and >> it's just not useful. The JCR on top of derby runs just fine. >> >> 2. Remove the ActiveMQ clustering information. >> >> If set up correctly you'd have a STORM of events flowing from every >> node to every other. YIKES. >> As far as I know there's no functionality in the OAE codebase that >> uses or expects a clustered ActiveMQ environment. >> >> Any thought? Objections? >> >> Erik >> _______________________________________________ >> oae-dev mailing list >> oae-dev@collab.sakaiproject.org >> http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-dev mailing list oae-dev@collab.sakaiproject.org http://collab.sakaiproject.org/mailman/listinfo/oae-dev
