We apologize for untranslated text, you can use the Google Translation button to get an automatic translation of the web page in the language of your choice.

Centralized Writes Plugin 2.1

Description

Dans une plateforme JCMS montée en cluster JSync, il est fortement recommandé de centraliser les écritures dans JStore. C’est naturellement le cas si la plateforme est en actif/passif (p. ex. en fail-over) mais si elle est en actif/actif (p. ex. en répartition de charge) les écritures peuvent avoir lieu sur plusieurs réplicas. Si les écritures de JStore ne sont pas centralisées, les phases de synchronisation JSync avec fusion seront plus nombreuses. Cela entrainera un accroissement du temps traitements et augmentera les risques de conflits. Tout cela ne concerne pas les écritures qui ont lieu dans JcmsDB.

Sur une plateforme JCMS le volume d’écriture dans JStore est généralement très faible (5%) par rapport au volume d’écritures dans JcmsDB (95%). Par ailleurs ces écritures sont généralement produites par une petite partie des utilisateurs de la plateforme. Pour centraliser les écritures de JStore, il suffit donc de centraliser sur le même réplica ces utilisateurs. Ce réplica doit être le leader car c’est sur celui-ci que sont aussi déclenchées les écritures planifiées (p. ex. les changements d’état du workflow)

Le module de contribution centralisée prend en charge la centralisation des membres qui font des écritures dans JStore. Il détecte les membres qui vont probablement écrire dans le store et il les redirige vers le leader. Pour cela, il se base sur les droits de contribution et surtout les contributions passées des membres. Si un membre a récemment effectué une écriture dans JStore alors la probabilité qu’il réitère est plus élevée qu’un membre qui n’a jamais écrit ou dont la dernière écriture date de plus d’un mois. Comme il s’agit d’un système prédictif, il se peut donc qu’un membre effectue quand même une écriture dans JStore alors qu’il n’est pas sur le leader. Lorsque cela arrive, JSync effectue une phase de synchronisation avec fusion puis ensuite le membre est redirigé sur le leader. Ses prochaines écritures seront alors bien centralisées.


Screenshots

1. A partir de JCMS 9 SP2, le module fournit une interface de suivi.

Installation

This plugin requires JCMS 7.0 SP3 or an above Service Pack. It is compatible with JCMS 7.1 and JCMS 8.

1. Installation

First, make sure your architecture match the following requirements :

  • A frontal server with a dedicated url (most commonly used to load balance users on 2 or more replica) (e.g. http://www.mysite.com)
  • A writing replica, that must be reachable to workers using a direct URL (e.g. http://publish.mysite.com)
  • Other replicas.

1. Install the plugin on each replica and restart.

2. Edit plugin properties.

There are three properties that must be filled (use same values on all replica) :

  • URID of the writing replica : This is the URID visible in the properties of the writing replica (e.g. "c"). It is required by the plugin to determine if the current replica is the writing replica or not. This property is required, otherwise the plugin will be disabled.
  • URL of the writing replica : This is the URL that will be used to redirect workers if they logs in, this URL is usually a direct URL to the writing replica cluster's node (e.g. "http://replica1.mysite.com/"). This property is required, otherwise the plugin will be disabled.
  • Base URL regexp of the frontal server : This is a regular expression used to determine if the current user request is made through the frontal URL or is a direct access to a replica. (e.g. http://www.mysite.com/). Warning : if left empty, direct connexions from administrators to any replica will be redirected to the writing replica. Make sure you fill this value to be able to administer all your replicas.

An optionnal property defines the time of validity of the login ticket used to reauthenticate members on the writing replica after the redirection.

2. Advanced Configuration

2.1. Writing replica availability

If the writing replica is not available due to maintenance, crash or anything else, the member must not be redirected.

To that extent, the Ping URL of writing replica can be specified in the properties of the plugin to regularly check availability of the writing replica. You must specify an URL which is directly attainable from the replica without any proxy or authentication (authkey excepted). The specified URL must return a 200 HTTP status code.
If the URL cannot be reached, the redirection will be disabled until a new check is performed and the connexion is restored.

The default settings of the plugin is to check this URL every minute, it can be modified by changing the schedule property jcmsplugin.centralized-writes.writing-replica-ping.schedule using a JDring CRON syntax.

2.2. Custom Redirection Rule

If the default check on the worker status of the member does not suit your need to redirect members, you can provide your custom redirection rule by creating a custom Java class implementing thecom.jalios.jcmsplugin.centralizedwrites.CentralizedWritesRule interface and then declaring this class using property jcmsplugin.centralized-writes.custom-rule.class.

Below is a sample custom redirection rule class providing systematic redirect for members belonging to a predefined group, and never redirecting for member belonging to an exclusion group.

  public class CustomCentralizedWritesRule implements CentralizedWritesRule {

  private static Logger logger = PluginManager.getPluginManager().getPlugin("CustomPlugin").getLogger();
  private static Channel channel = Channel.getChannel();

  public CustomCentralizedWritesRule() {
  }
  
  public boolean isEligibleForRedirection(AuthenticationContext ctxt, boolean computedValue) {
    Member mbr = ctxt.getLoggedMember();
    if (mbr != null) {
      
      Group forcedGroup = channel.getGroup(channel.getProperty("jcmsplugin.Custom.centralized-writes-rule.forced-group-id", ""));
      if (forcedGroup != null && mbr.belongsToGroup(forcedGroup)) {
        if (logger.isTraceEnabled()) {
          logger.trace("Custom CentralizedWritesRule : DO redirect of Member '" + mbr + "' ("+mbr.getId()+") as it belongs to forced group '" + forcedGroup + "' ("+forcedGroup.getId()+")");
        }
        return true;
      }
      
      Group excludedGroup = channel.getGroup(channel.getProperty("jcmsplugin.Custom.centralized-writes-rule.excluded-group-id", ""));
      if (excludedGroup != null && mbr.belongsToGroup(excludedGroup)) {
        if (logger.isTraceEnabled()) {
          logger.trace("Custom CentralizedWritesRule : DO NOT redirect of Member '" + mbr + "' ("+mbr.getId()+") as it belongs to excluded group '" + excludedGroup + "' ("+excludedGroup.getId()+")");
        }
        return false;
      }
      
    }
    
    if (logger.isTraceEnabled()) {
      logger.trace("Custom CentralizedWritesRule : Apply default rule of CentralizedWritesPlugin.");
    }
    return computedValue;
  }

}
  

This example is just a demonstration of the capabilities provided by the plugin and MUST be improved, mainly regarding performance, by reading group properties in a dedicated PropertiesListener.


Information

Version
  • 2.1
Stability
  • Stable
Compatibility
  • JCMS 8
    JCMS 9
    JPlatform 10
Certified by Jalios
  • Yes
Price
  • Module payant
Support
  • Jalios Support
Author
  • Jalios SA
License
  • Jalios
Size
  • 93.42 KB
Updated
  • 11/10/17
Download
  • 15