Od pewnego czasu zgłębiam tajniki projektu Velocity, czyli rozproszonego cache osadzonego w pamięci oferowanego przez Microsoft. Po tym jak przyjżymy się aplikacji (np webowej) zauważymy jeden bardzo dotkliwy problem. Wyobraźmy sobie dobrze zaprojektowany klaster serwerów obsługujących Velocity z wysoką dostępnością danych, regionami, odpowiednio ustalonymi politykami zarządzania obiektami w cache. Połączenie do klastra odbywa się poprzez leading host, który jest odpowiedzialny za komunikację pomiędzy klientem i klasterm. Jednakże co w przypadku, gdy taki host przestaje odpowiadać?
Pierwsze co robimy to wystartowanie hosta w klastrze, który będzie odpowiadał za komunikację.
W tym momencie możemy bez żadnych przeszkód uruchomić aplikację, w której host nie jest pobierany z pliku konfiguracyjnego, tylko ustawiany w kodzie jak widać poniżej:
Uruchomienie przebiega pomyslnie – czyli tak jak powinien. Zobaczmy zatem co dzieje się w przypadku niedostępności hosta. Aby móc to przetestować trzeba zasymulować padnięcie serwera.
Próba skorzystania z polecenia Stop-CacheHost w przypadku pojedynczego hosta w klastrze powoduje błąd kworum klastra – bo nie może on istnieć bez żadnego hosta… Oczywiste. Pozostaje zatem zatrzymanie całego klastra i zbadanie jak zachowa się aplikacja.
Jak to rozwiązać? W projekcie dodajemy klasę EndpointsProvider będącą definicją providera odczytującego informacje o endpointach czy to z bazy, czy nawet ze źródla RSS.
Przy użyciu powyższego kodu proces inicjacji fabryki trwa tak długo, aż utworzenie istancji cache nie spowoduje zrzucenia błędu typu DataCacheException (lub wyczerpania puli hostów, lecz uznaję to za przypadek mało prawdopodobny w momencie utworzenia klastra z kilkoma serwerami i leading hostami…)
Mam nadzieję, że ten prosty workaround pomoże wam w rozwiązaniu problemu dynamicznej konfiguracji aplikacji bez konieczności zmian w plikach konfiguracyjnych.
