Vue d’ensemble des silos hétérogènes

Sur un cluster donné, les silos peuvent prendre en charge un ensemble différent de types de grain :

Dans cet exemple, le cluster prend en charge les grains de type A, B, C, D et E :

• Les types de grain A et B peuvent être placés dans les silos 1 et 2.
• Le type de grain C peut être placé dans le silo 1, 2 ou 3.
• Le type de grain D peut être placé uniquement dans le silo 3.
• Le type de grain E peut être placé uniquement dans le silo 4

Tous les silos doivent référencer les interfaces de tous les types de grain du cluster, mais les classes de grain ne doivent être référencées que par les silos qui les hébergeront. Le client ne sait pas quel silo prend en charge un type de grain donné.

Important

Une implémentation de type de grain donnée doit être la même sur chaque silo qui la prend en charge.

Le scénario suivant n’est pas valide :

Dans les silos 1 et 2 :

public class C: Grain, IMyGrainInterface
{
   public Task SomeMethod() { /* ... */ }
}

Dans le silo 3 :

public class C: Grain, IMyGrainInterface, IMyOtherGrainInterface
{
   public Task SomeMethod() { /* ... */ }
   public Task SomeOtherMethod() { /* ... */ }
}

Configuration

Aucune configuration n’est nécessaire, vous pouvez déployer différents fichiers binaires dans chaque silo de votre cluster. Toutefois, si nécessaire, vous pouvez modifier l’intervalle selon lequel les silos et les clients recherchent des modifications dans les types pris en charge avec la propriété TypeManagementOptions.TypeMapRefreshInterval.

À des fins de test, vous pouvez utiliser la propriété GrainClassOptions.ExcludedGrainTypes, qui est une liste de noms des types que vous souhaitez exclure sur les silos.

Limites

• Les clients connectés ne seront pas avertis si l’ensemble des types de grain pris en charge a changé. Dans l’exemple précédent :
  • Si le silo 4 quitte le cluster, le client continuera d’essayer d’effectuer des appels au grain de type E. Il échouera au moment de l’exécution avec une exception OrleansException.
  • Si le client était connecté au cluster avant que le silo 4 l’ait rejoint, le client ne pourra pas effectuer d’appels au grain de type E. Il échouera avec une exception ArgumentException.
• Les grains sans état ne sont pas pris en charge : tous les silos du cluster doivent prendre en charge le même ensemble de grains sans état.
• ImplicitStreamSubscriptionAttribute n’est pas pris en charge et donc seuls les abonnements explicites peuvent être utilisés dans les flux Orleans.