Ну, это загруженный вопрос.
Есть много вещей, которые происходят как до, так и после того, как клиент (кеш) подключается к кластеру (или серверу). Многие вопросы приходят на ум, так как ваше описание в данном случае не является описательным.
Вы упоминаете, что подключаетесь к серверу, что подразумевает использование Spring Boot, Spring Data для Pivotal GemFire ( SDG) приложение является клиентом, а конкретно ClientCache
? Если да, то какую сеть вы используете (localhost, частная внутренняя сеть, VPN, облачная сеть и т. Д. c)?
Есть ли межсетевой экран, прокси, NAT ( например, маршрутизатор, коммутатор или другое сетевое устройство? Если вы заметили задержку, то есть большая вероятность проблем с сетью.
Как вы настроили пул между клиентом и сервером? Например, вы подключаетесь к одному или нескольким локаторам или к одному локатору. Вы подключаетесь напрямую к серверу?
Насколько велик ваш кластер? Существует ли более 1 сервера? У вас включен один прыжок?
Какую операцию доступа к данным вы выполняете? Насколько велик набор результатов (т. Е. Сколько объектов)? Насколько велики объекты?
Какую форму сериализации вы используете (например, вы используете типы моделей предметной области java.io.Serializable
? Вы случайно используете PDX? Вы используете GemFire Дельты и DataSerialization?
Вы пытались запустить одно и то же приложение в разных контекстах?
Есть ли ваше приложение общедоступным где-нибудь, например, в GitHub?
Можете ли вы поделиться своей конфигурацией, полными файлами журнала для клиента и сервера, дампами потоков для клиента и сервера и т. д. c?
Является ли регион, в котором вы осуществляете доступ к данным из вашего приложения, регионом PARTITION? Включено ли сохранение? Если кластер состоит из нескольких узлов (сервер), все ли участники размещают PR?
et c, et c, et c ...
Небольшой фрагмент содержимого журнала, которым вы поделились ...
2020-Mar-13 09:00:42 | TRACE | internal.ClassPathLoader | getResource(gemfire.properties)
2020-Mar-13 09:00:42 | TRACE | internal.ClassPathLoader | getResource trying: sun.misc.Launcher$AppClassLoader@73d16e93
2020-Mar-13 09:00:42 | TRACE | internal.ClassPathLoader | getResource trying: java.net.Launcher$AppClassLoader@73d16e93
Похоже, он пытается разрешить файл gemfire.properties
е. Вы настроили gemfire.properties
? Если это так, то лучше определить ресурс Spring Boot application.properties
и использовать вместо него соответствующие эквивалентные свойства spring.data.gemfire.*
.
Если ваша файловая система в добром здравии?
The ClassPathLoader
class является внутренним классом Pivotal GemFire, поэтому, что бы ни происходило, он находится вне контроля Spring (Data GemFire) и полностью связан с самим GemFire.
Вы также должны знать, что только потому, что GemFireCache
(например, ClientCache
) экземпляр был создан, это не обязательно означает, что кэш или система GemFire в целом полностью инициализированы. Существует много асинхронных задач (например, создание минимального размера пула), которые выполняются в фоновом режиме после создания определенных объектов GemFire (например, кэш, затем регионы, затем индексы и дисковые хранилища и т. Д. c).
Также созданный экземпляр кэша (например, ClientCache
) - это просто контейнер для хранения всех других объектов GemFire, таких как Regions, которые фактически содержат данные. Области должны быть созданы и инициализированы, прежде чем могут произойти какие-либо операции доступа к данным. Однако для создания регионов вам необходим кеш (т. Е. Экземпляр ClientCache
в первую очередь).
Какого типа ваши клиентские регионы (например, ClientRegionShortcut.PROXY
или ClientRegionShortcut.CACHING_PROXY
)?
В ваших данных слишком много пробелов, чтобы дать вам более точный ответ.