версия клиентского сервера geode не поддерживается - одноранговая или клиентская версия с порядковым номером 100 не поддерживается

У меня есть приложение springboot, размещенное на PCF, которое пытается подключиться к PCC (основной облачный кеш). Я развернул экземпляр PCC, привязал его к своему приложению и отправил приложение в облачную фабрику. Я добавил все необходимые зависимости для запуска gemfire в springboot, и похоже, что он смог прочитать информацию о локаторе и сервере из VCAP_SERVICES. Но при запуске приложения весенней загрузки я вижу следующую ошибку.

org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120) - Could not create a new connection to server: XXX.XXX.XX.XXX(cacheserver-c3a291d1-9664-40d5-b20c-ad8dca8cd19e:1)<v3>:56152(version:GEODE 1.7.0) refused connection: 
Peer or client version with ordinal 100 not supported. Highest known version is 1.7.0 Client: /XXX.XXX.XX.XXX:39192.

at org.apache.geode.internal.cache.tier.sockets.Handshake.readMessage(Handshake.java:330) ~[geode-core-1.9.2.jar!/:?]

Я не уверен, что здесь означают порядковые номера, а также какие зависимости необходимо обновить.

Вот мои зависимости от maven ..

        <dependency>
            <groupId>org.springframework.data</groupId>
            <artifactId>spring-data-gemfire</artifactId>
            <version>2.2.1.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.geode</groupId>
            <artifactId>spring-geode</artifactId>
            <version>1.2.6.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>io.pivotal.gemfire</groupId>
            <artifactId>geode-core</artifactId>
            <version>9.8.4</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.data</groupId>
            <artifactId>spring-data-geode</artifactId>
            <version>2.2.6.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.geode</groupId>
            <artifactId>spring-geode-starter</artifactId>
            <version>1.2.6.RELEASE</version>
        </dependency>

Это мой файл конфигурации ..

@Configuration
@ClientCacheApplication(name = "Test", logLevel = "info")
@EnableCachingDefinedRegions(
    clientRegionShortcut = ClientRegionShortcut.PROXY,
    serverRegionShortcut = RegionShortcut.REPLICATE_HEAP_LRU)
@EnableClusterAware
@EnablePdx
public class CloudConfiguration {}

Любая помощь?

Madmax 08.04.2020 источник

comment

Spring, похоже, использует Geode Apache, поэтому, поскольку ваша ошибка кажется проблемой несовместимости, возможно, попробуйте изменить основную версию geode-core на apache one? - Jorge Campos 08.04.2020

comment

Привет, Хорхе, я не могу обновить основные зависимости, размещенные на корпоративном сервере. Попытка найти основную причину в клиентском приложении Spring Boot App и посмотреть, можно ли ее устранить. Это может быть версия зависимости от geode / gemfire. На данный момент не уверен. - Madmax 09.04.2020

comment

Достаточно справедливо ... Таким образом, ваша ошибка также может означать, что ваша версия слишком обновлена для любого сервера, поскольку он говорит, что знает только самую высокую версию 1.7.0 ... может быть, вы понижаете вашу зависимость до основной? - Jorge Campos 09.04.2020

comment

Согласившись с другими ответами, это, вероятно, проблема совместимости между вашими серверами и клиентами. Я бы посоветовал дважды проверить используемую версию PCC (вместе с версией GemFire, поставляемой с PCC) и убедиться, что версия GemFire в клиентском приложении не выше. - Juan Ramos 09.04.2020

Ответы (2)

arrow_upward
2
arrow_downward

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

Начнем с самого начала:

Во-первых, зависимости вашего приложения, как показано в Maven POM выше, очень запутаны!

Вы объявляете прямые "версионные" зависимости от Spring Data GemFire  (т.е. org.springframework.data:spring-data-gemfire:2.2.1.RELEASE) вместе с Spring Data Geode (т.е. org.springframework.data:spring-data-geode:2.2.6.RELEASE, которые не совпадают; SD GemFire 2.2.1 ! = SD Geode 2.2.6) вместе с Spring Boot для Apache Geode и Pivotal GemFire  (SBDG) (org.springframework.geode:spring-geode-starter:1.2.6.RELEASE), а затем без надобности втягивать модуль spring-geode (core) SBDG, который транзитивно втягивается в любом случае spring-geode-starter, а также объявление модуля org.apache.geode:geode-core, уф! :)

Единственная зависимость, которую вам нужно объявить в этом случае, - это 1 из стартеров SBDG, либо org.springframework.geode:spring-geode-starter при использовании Apache Geode, либо org.springframework.geode:spring-gemfire-starter при использовании Pivotal GemFire, либо, альтернативно, при развертывании приложения Spring Boot в PCF с помощью PCC (в В этом случае рекомендуется spring-gemfire-starter зависимость, хотя и не является абсолютно необходимой, поскольку можно смешивать одноранговые узлы GemFire / Geode и заставить клиентов Geode взаимодействовать с серверами GemFire или наоборот).

Стартер извлекает Spring Data Geode (или Spring Data GemFire , в зависимости от стартера), который извлекает биты Geode (или GemFire) для ты. Это в первую очередь суть управления зависимостями Maven / Gradle, и лучше максимально минимизировать объявления зависимостей вашего приложения и просто позволить фреймворку / стартеру решать за вас версии транзитивных зависимостей, особенно если вы этого не сделаете. т забота.

Проект Spring Boot в целом идет на многое, чтобы курировать и согласовывать все версии зависимостей (как Spring, так и сторонние библиотеки / включены транзитивные зависимости) для вас. Вам нужно только выбрать версию Spring Boot на основе версий зависимостей приложения (например, Apache Geode или Pivotal GemFire), которые вам требуются.

Мы постараемся подытожить их здесь:

https://github.com/spring-projects/spring-boot-data-geode/wiki/Spring-Boot-for-Apache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix < / а>

В частности, см .:

https://github.com/spring-projects/spring-boot-data-geode/wiki/Spring-Boot-for-Apache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix#version-compatibility-matrix

Чтобы быть очень прозрачным, эта матрица / таблица совместимости версий примерно переводится как:

Как разработчик я использую или выбираю SBDG 1.2.6.RELEASE.
SBDG 1.2.6.RELEASE основан на на Spring Boot 2.2.6.RELEASE.
Spring Boot 2.2.6.RELEASE извлекает данные Spring Moore-SR6.
Spring Data Moore-SR6 (this) включает Spring Data GemFire / Geode 2.2.6.RELEASE.
Spring Data Geode (SDG) Moore-SR6/2.2.6.RELEASE - это на основе Apache Geode 1.9.x.
Spring Data GemFire  (SDG) Moore-SR6/2.2.6.RELEASE - это на основе Pivotal GemFire  9.8.x.
Spring Data Geode включает необходимые (по SDG) и правильные биты Apache Geode (зависимости).
Spring Data GemFire  включает необходимые (по SDG) и правильные биты Pivotal GemFire (зависимости).

Следовательно, становится вопросом, какую версию SBDG (т.е. какую spring-[geode|gemfire]-starter версию) вам нужно использовать с PCC в PCF?

Для этого вы должны иметь общее представление о том, что клиенты GemFire / Geode могут подключаться и взаимодействовать с серверами GemFire / Geode только той же версии, что и клиент, или более поздней. Новый клиент НЕ МОЖЕТ взаимодействовать со старым сервером GemFire / Geode. Это не ограничение Spring, а само ограничение GemFire / Geode. Есть много факторов, объясняющих, почему это так, и я не буду это здесь объяснять (но это примерно сводится к протоколам, распределенным алгоритмам и прочему).

В качестве примера вы можете подключить клиент GemFire 9.8 к серверу GemFire 9.8.x, и все будет в порядке. Тот же самый клиент GemFire 9.8 может также подключаться и взаимодействовать с серверами GeFire 9.9.x и 9.10.x. Однако клиент GemFire 9.8 не может подключаться или разговаривать с сервером GemFire 9.7, 9.6, 9.5 или более ранней версии. Версии исправлений или обслуживания не имеют значения AFAIR, это означает, что клиент GemFire 9.8.7 должен иметь возможность подключаться и разговаривать с сервером GemFire 9.8.4, например, если совпадают major.minor версии.

Итак, теперь все сводится к тому, какая версия Pivotal GemFire является версией PCC в PCF, в которой вы развертываете свое приложение Spring Boot (Data Geode) на основе на?

Для этого вам нужно посмотреть документацию PCF / PCC.

Например, PCC для PCF (теперь известная как VMware Tanzue GemFire для виртуальных машин) версии 1.11 основана на Pivotal GemFire 9.9.1. См. здесь.

Это означает, что вы можете использовать SBDG 1.2.6.RELEASE, который основан на Spring Boot 2.2.6.RELEASE, который использует Spring Data Moore-SR6, который включает SDG 2.2.6.RELEASE, основанный на Apache Geode 1.9.2 / Pivotal GemFire 9.8.7. Эта комбинация хороша, потому что старый клиент (например, GemFire 9.8.7) может подключаться и взаимодействовать с GemFire 9.9.1, который является базовым для PCC / VMware Tanzu GemFire для VMS 1.11.

Есть смысл?

Если мы посмотрим на PCC 1.10, мы снова увидим, что основан на Pivotal GemFire 9.9.1.

Если мы посмотрим на PCC 1.9, он основан на Pivotal GemFire 9.8.6. Опять же, у нас здесь все в порядке.

Если мы вернемся к PCC 1.7, мы увидим, что PCC 1.7 был на основе Pivotal GemFire 9.7.2.

Теперь SBDG 1.2.6.RELEASE НЕ будет работать с PCC 1.7, поскольку SBDG 1.2.6.RELEASE основан на GemFire 9.8 (новее), а PCC 1.7 основан на GemFire 9.7 (более раннем). Клиент 9.8 не может подключиться и поговорить с сервером 9.7, поэтому мы должны вернуться с версии SBDG major.minor к SBDG 1.1.x, где SBDG 1.1.x основан на Spring Boot 2.1, который втягивает Spring Data Lovelace/2.1, который включает SDG 2.1.x, основанный на Apache Geode 1.6 и Pivotal GemFire 9.5 соответственно.

ПРИМЕЧАНИЕ. Хотя SDG «совместима» с более новыми, не имеющими «базовых» версий GemFire / Geode, мы не «поддерживаем» эту комбинацию. Например, SDG Lovelace / 2.1 "основана" только на GemFire 9.5 / Geode 1.6, но "совместима" с GemFire 9.6 / 9.7 и Geode 1.7 / 1.8. Если вы перейдете с GemFire 9.7 на, например, 9.8 и Geode 1.8 до 1.9, то, конечно, вам следует перейти на SDG Moore / 2.2, поскольку он «основан на» GemFire 9.8 / Geode 1.9. Совместимость! = Поддержка. В любом случае, это означает, что вы можете обновить версию своего клиентского драйвера (то есть версию клиента GemFire / Geode, если необходимо). См. здесь для получения дополнительных сведений. Эта страница Wiki является WIP.

Разработчик облачного кэша Веб-сайт также содержит подробную информацию, которая поможет вам начать работу.

Наконец, я также создал этот пример для начала работы (с Руководство и Исходный код) в самом проекте SBDG, который поможет вам приступить к работе быстро, начав с start.spring.io.

Теперь по поводу вашей конфигурации ...

@Configuration
@ClientCacheApplication(name = "Test", logLevel = "info")
@EnableCachingDefinedRegions(
    clientRegionShortcut = ClientRegionShortcut.PROXY,
    serverRegionShortcut = RegionShortcut.REPLICATE_HEAP_LRU)
@EnableClusterAware
@EnablePdx
public class CloudConfiguration {}

Это можно упростить до:

@Configuration
@EnableCachingDefinedRegions(
  serverRegionShortcut = RegionShortcut.REPLICATE_HEAP_LRU
)
@EnableClusterAware
public class CloudConfiguration {}

SBDG "автоматически настраивает" ClientCache экземпляр по умолчанию. См. здесь < / а>.

Фактически, вы должны быть осторожны при явном объявлении аннотаций, поскольку в этом случае вы переопределяете автоконфигурацию (т.е. вы переопределяете "соглашение", применяя явное "< em> configuration ", который сообщает Boot, что вы знаете, что делаете; убедитесь, что это действительно так!) См. здесь и здесь и здесь и здесь и здесь.

Многие из атрибутов аннотации (например, ClientCacheApplication.name или ClientCacheApplication.logLevel) могут быть выражены как свойства SDG в файле Spring Boot applications.properties, что делает конфигурацию более «настраиваемой».

Например:

# Spring Boot application.properties.
spring.data.gemfire.name=Test
spring.data.gmefire.cache.log-level=INFO

См. здесь и здесь для получения более подробной информации.

Вам также не нужно явно включать PDX, поскольку SBDG снова автоматически настраивает PDX за вас. См. здесь < / а>.

По умолчанию ClientRegionShortcut - ПРОКСИ, хотя я тоже не против "откровенно" об этом сказать. Вам просто нужно быть осторожным в контексте Spring Boot с автоконфигурацией, поскольку вы можете "переопределить" автоконфигурацию и поместить ответственность за правильное управление конфигурацией на себе. Итак, декларируйте конфигурацию намеренно, а не вслепую.

Надеюсь это поможет!

John Blum 21.04.2020

comment

Давайте также запомним еще одну вещь ... эта проблема графа зависимостей / управления не является эксклюзивной для Spring. Это почти то же самое для всех приложений Java, которые вы бы отправили в производственную среду. Если ваше приложение использует Hibernate, Jackson или что-то еще, что упрощает функциональность вашего приложения, вы найдете аналогичные переходные графики зависимостей. Это проблема Java, и почему Maven / Gradle вместе с другими инструментами управления зависимостями (например, Ivy) существуют в первую очередь. - John Blum; 22.04.2020

arrow_upward
1
arrow_downward

Решение: я понизил версию клиента SpringBoot до версии v1.7, и она работала нормально. Хотя сейчас я вижу проблему с аутентификацией.

Madmax 09.04.2020

версия клиентского сервера geode не поддерживается - одноранговая или клиентская версия с порядковым номером 100 не поддерживается

Ответы (2)

Вопросы по теме