WSO2: AM: заполнение организации меняется без Hazelcast - PullRequest
Новая
       17

WSO2: AM: заполнение организации меняется без Hazelcast

1 голос
/ 28 марта 2019

Мы используем мультитенантный кластер WSO2-AM 2.6 с двумя типами узлов

  • Полный профиль узла (издатель, магазин, км и т. Д.)
  • Рабочие узлы шлюза

Обмен информацией с ч / б издателем и шлюзами осуществляется с использованием EFS.

До сих пор мы работали с включенной Hazelcast, но мы предпочитаем отключать Hazelcast, так как это доставляет нам много боли при работе, и мы понимаем, что в WSO2 2.x его включение не обязательно.

Мы протестировали нашу систему со следующими настройками: 

<clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent" enable="false">

Все работало нормально, за исключением одного побочного эффекта, который мы заметили: это занимает много времени (может быть даже 15 минут), пока деактивация или повторная активация арендатора не будет заполнена на рабочий узел.

При создании совершенно новой организации с помощью вновь созданного API, можно практически мгновенно запустить API на рабочем месте. Но если вы отключите организацию, API все равно будет работать. Пройдет много времени, пока работник сообщит, что арендатор больше не активен.

То же самое для повторной активации арендатора. Потребуется много времени, чтобы работник перестал жаловаться на неактивную организацию и разрешил запуск API.

Нужно ли изменить настройки конфигурации? Или это ожидаемое поведение? Кто должен сообщать работникам об изменениях в организации в отсутствие Hazelcast?

Ответы [ 2 ]

0 голосов
/ 01 апреля 2019

Честно говоря, я думаю, вам следует больше узнать, как настроить Hazelcast.Hazelcast встроен во множество очень часто используемых стеков проектов (JHipster, Atlassian, Apache Camel, SunGard и т. Д.). Он очень полезен для выполнения того, что вы хотите здесь, но он также легко настраивается, поэтому вы, вероятно, захотите настроить его в соответствии ствои нужды.Если вы просто отключите его, вы удалите всю кластеризованную масштабируемость, которую он приносит.Конфигурация - это просто файл XML, и вы можете найти всю документацию здесь:

https://docs.hazelcast.org/docs/3.11.2/manual/html-single/index.html#understanding-configuration

Это легко понять и определенно стоит вашего времени.

0 голосов
/ 29 марта 2019

Существует кэш арендатора [1], который содержит информацию об арендаторе.TTL по умолчанию для кэша (и любого кэша) составляет 15 минут.Когда вы деактивируете арендатора, этот распределенный кеш очищается с помощью Hazelcast.Вот почему вы наблюдаете выше при отключении кластеризации Hazelcast.

Как правило, в производственной среде очень маловероятно, что вам нужно будет активировать и деактивировать арендаторов очень часто.Так что я не думаю, что задержка в 15 минут является проблемой.

Однако, если это действительно так, вы должны оставить кластеризацию Hazelcast включенной.Когда вы сказали, что столкнулись с большой болью из-за Hazelcast, я полагаю, что это из-за распределенной природы этих кэшей.В качестве решения вы можете включить локальный кеш, а не распределенный кеш.Здесь кластеризация Hazelcast используется только для вызовов аннулирования кэша.Это может сработать для вас.(Отказ от ответственности: я еще не пробовал.)

Для этого вам нужно установить ForceLocalCache на true в carbon.xml

<Cache>
    <!-- Default cache timeout in minutes -->
    <DefaultCacheTimeout>15</DefaultCacheTimeout>
    <!-- Force all caches to act as local -->
    <ForceLocalCache>true</ForceLocalCache>
</Cache>

[1] https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/tenant/JDBCTenantManager.java#L303

...