Даже с вашей конфигурацией Java выше, ваше расположение все еще немного неясно / неоднозначно для меня. Тем не менее, давайте начнем с того, что мы знаем.
Во-первых, из приведенной выше конфигурации Java ясно, что вы создаете приложение ClientCache, Spring для подключения и отправки / получения данных в / из автономного кластера GemFire.
Вы также заявляете, что запускаете Локатор и Сервер (ы) , используя Gfsh . Пока все хорошо.
Однако у вас есть ...
1) Аннотируйте класс своего клиентского приложения с помощью @EnableEntityDefinedRegions (это нормально) без указания альтернативной политики данных с использованием атрибута clientRegionShortcut. По умолчанию для clientRegionShortcut установлено значение PROXY (см. здесь ), что означает , что ваше клиентское приложение НЕ поддерживает локальное состояние.
2) Затем вы определяете DiskStore (то есть «disk_store») на клиенте с аннотацией @EnableDiskStore, что, вероятно, не то, что вам нужно, поскольку в настоящее время в клиентских регионах нет локальных состояний.
ПРИМЕЧАНИЕ: @EnableClusterConfiguration не передает метаданные конфигурации для DiskStores на сервер с клиента. В настоящее время он только передает метаданные конфигурации Region и Index на серверы, как определено на клиенте.
В остальном, остальная часть конфигурации Spring (для GemFire) (с использованием аннотаций) выглядит просто отлично.
ПРИМЕЧАНИЕ. Также имейте в виду, что аннотация @EnableClusterConfiguration старается не растоптать существующие регионы на стороне сервера. Если такие же Регионы по названию уже существуют, то сервер не будет применять определение, отправленное клиентом при объявлении аннотации @EnableClusterConfiguration (то есть аннотация не будет "разряжена и проложена"). Это сделано специально для защиты от потери данных.
ПРИМЕЧАНИЕ. Я также рекомендую использовать безопасную по типу альтернативу атрибуту basePackages в аннотациях @EnableEntityDefinedRegions и @EnableGemfireRepositories, атрибут basePackageClasses. Он может ссылаться на 1 или более классов, но этот тип класса используется только для определения пакета, с которого начинается сканирование. Например, вы можете установить @EnableEntityDefinedRegions, basePackageClasses на example.app.customers.model.Customer.class и example.app.products.model.Product.class, как в @EnableEntityDefinedRegions(basePackageClasses = { Customer.class, Product.class }), и SDG будет использовать объявление пакета этих классов, чтобы начать классы Scan for Entity (включая подпакеты) , Вам не нужно перечислять все (или несколько) классов из пакета; Достаточно будет 1 пакет (на верхнем уровне), с которого вы хотите сканировать. Хорошо ограничить сканирование.
Итак, в вашем случае вы, вероятно, захотите сделать следующее:
На клиенте:
@EnablePdx
@ClientCacheApplication
@EnableClusterConfiguration(useHttp = true)
@EnableEntityDefinedRegions(basePackageClasses = EntityType.class)
@EnableGemfireRepositories(basePackageClasses = RepositoryType.class)
public class GeodeClientConfiguration {
}
А затем на сервере для «сохранения» данных вы хотите создать «ПЕРСИСТЕНТНЫЕ» Области. Вы можете сделать это одним из 2 способов:
1) Во-первых, вы можете настроить клиент, используя аннотацию @EnableClusterConfiguration, чтобы сообщить серверу при создании соответствующего региона (по имени), как это определено клиентом, для создания «ПРОСТОГО» региона. По умолчанию клиентская аннотация @EnableClusterConfiguration указывает серверу создать непостоянный регион PARTITION (см. здесь ). Таким образом, вы бы изменили аннотацию @EnableClusterConfiguration в конфигурации вашего клиента на:
@ClientCacheApplication
@EnableClusterConfiguration(useHttp = true, serverRegionShortcut = RegionShortcut.PARTITION_PERSISTENT)
...
class GeodeClientConfiguration { ... }
Вы можете использовать любой из не-МЕСТНЫХ, "PERSISTENT", RegionShortcut, Region (политика данных) типов (см. здесь ) ... в основном [PARTITION_PERSISTENT * и REPLICATE_PERSISTENT *].
Затем, когда клиент передает метаданные конфигурации региона на сервер, сервер создает регион с тем же именем и назначенным типом (политики данных) (как определено атрибутом @EnableClusterConfiguration аннотации serverRegionShortcut) .
Опять же, имейте в виду, что если Регион уже существует, он не будет воссоздавать Регион. Если вы хотите, чтобы клиент создавал регион при перезапуске (каждого приложения), вам нужно уничтожить регион, используя Gfsh .
2) Кроме того, вы можете использовать Gfsh для создания региона, используя:
gfsh> create region --name=Example --type=PARTITION_PERSISTENT
Наконец, когда дело доходит до DiskStore, так как у вас НЕТ локального состояния Region, и даже если вы это сделали, вы, вероятно, хотите, чтобы данные «сохранялись» на стороне сервера, а затем, если вы ничего не делаете и просто объявляетеРегион (ы) на стороне сервера с политикой данных «PERSISTENT», использующей один из двух указанных выше методов, GemFire по умолчанию записывает в «DEFAULT» DiskStore.
Если вы хотите связать«определенное» DiskStore (по имени) с регионом (например, «Пример»), затем вы должны сначала создать DiskStore, используя Gfsh :
gfsh> create disk-store --name=disk_store ...
См. здесь .
А затем создайте регион с помощью Gfsh :
gfsh> create region --name=Example --type=PARTITION_PERSISTENT --disk-store=disk_store ...
См. здесь .
DiskStore используется как для «сохранения» данных, так и для переполнения данных на диск, если Eviction настроен на «OVERFLOW_TO_DISK» (см. здесь ).
From #2 (создание региона) и далее (с созданием DiskStore), все на стороне сервера.
В любом случае, я надеюсь, что все это имеет смысл и поможет.
Если выесть дополнительные вопросы или проблемы, не стесняйтесь следить в комментариях.
Спасибо.