Fatal error данные от локатора не пришли locator data not loaded https info live

Ok, first, when you started the GemFire Locator (i.e. «GemFireLocator» using Gfsh), you used the following Gfsh command…

gfsh> start locator —name=GemFireLocator —log-level=config

This resulted in starting the Locator on the default port, 10334, which is not the port you stated previously, 40001, but that is fine; it is easier to run the sample this way.

This is also apparent from the describe member command…

gfsh>describe member —name=GemFireLocator

Which resulted in…

Name        : GemFireLocator
Id          : 192.168.1.106(GemFireLocator:7256:locator):1024
Host        : ADMINIB-CI3Q48M
Regions     :
PID         : 7256
Groups      :
Used Heap   : 90M
Max Heap    : 1755M
Working Dir : C:UsersIBM_ADMINGemFireLocator
Log file    : C:UsersIBM_ADMINGemFireLocatorGemFireLocator.log
Locators    : 192.168.1.106[10334]

The last line…

Locators    : 192.168.1.106[10334]

… reveals that the Locator is listening on port 10334 bound to address 192.168.1.106.

Then, you proceed in starting the GemFire Server using my sample. I suspect not only did you run $ gradlew bootRun from the command-line, but that you followed the instructions to conclusion, including «Running with an Embedded GemFire/Geode Locator»… yes?

It is actually apparent from the new Stack Trace you posted…

...
...
Caused by: java.net.BindException: Failed to create server socket on  localhost/127.0.0.1[10,334]
        at com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:829)
        at com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:789)
        at com.gemstone.org.jgroups.stack.tcpserver.TcpServer.startServerThread(TcpServer.java:179)
        at com.gemstone.org.jgroups.stack.tcpserver.TcpServer.start(TcpServer.java:168)
        at com.gemstone.gemfire.distributed.internal.InternalLocator.startTcpServer(InternalLocator.java:629)
        at com.gemstone.gemfire.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:698)
        at com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.startInitLocator(InternalDistributedSyst
m.java:832)
        ... 37 more
Caused by: java.net.BindException: Address already in use: JVM_Bind
        at java.net.DualStackPlainSocketImpl.bind0(Native Method)
        at java.net.DualStackPlainSocketImpl.socketBind(DualStackPlainSocketImpl.java:106)
        at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
        at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:190)
        at java.net.ServerSocket.bind(ServerSocket.java:375)
        at com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:826)
        ... 43 more

Hence…

Caused by: java.net.BindException: Failed to create server socket on  localhost/127.0.0.1[10,334]

And…

Caused by: java.net.BindException: Address already in use: JVM_Bind

Do not confuse «creating a server socket» with starting a GemFire Server. In Java (as you may already know), whenever you bind an address/port for a «client» application to connect, you use a java.net.ServerSocket.

In this case, a Locator is a «server» and creates a java.net.ServerSocket for any clients (e.g. Gfsh, or other peer members like GemFire (Cache) Servers) that want to connect to the GemFire «cluster» defined by the Locator.

And, as you can see when you stopped the first Locator («GemFireLocator») you started in Gfsh initially, and then ran the sample by itself (and it started successfully!), when you «described» the member, using…

gfsh> describe member —name=SpringBootGemFireServer

     Name           | Id
----------------------- | --------------------------------------------------
SpringBootGemFireServer | ADMINIB-CI3Q48M(SpringBootGemFireServer):37651
gfsh>describe member --name=SpringBootGemFireServer
Name        : SpringBootGemFireServer
Id          : ADMINIB-CI3Q48M(SpringBootGemFireServer):37651
Host        : ADMINIB-CI3Q48M
Regions     : Factorials

PID         : 0
Groups      :
Used Heap   : 117M
Max Heap    : 1755M
Working Dir : C:UsersIBM_ADMINDocumentsWorkspace - ShirleyWorkspace_SpringBootspring-boot-gemfire-server-example
Log file    : C:UsersIBM_ADMINDocumentsWorkspace - ShirleyWorkspace_SpringBootspring-boot-gemfire-server-example
Locators    : localhost[10334]

Cache Server Information
Server Bind              : localhost
Server Port              : 40404
Running                  : true
Client Connections       : 0

You can see several bits of interesting information from the describe member command.

1. First, and most importantly, you see…

   Locators    : localhost[10334]
   

This is the «embedded» Locator. It is listening on port 10334, which is why you encountered the j.n.BindException when your «GemFireLocator» was running the first time.

This means the spring.gemfire.start-locator application property was set, and by default, I see that it is. This in turn sets the GemFire property, start-locator (from the application property), which then causes GemFire to start an «embedded» Locator.

As result, this causes a port conflict when «GemFireLocator» is running since you started the «GemFireLocator» on the default port, 10334.

If you had started the «GemFireLocator» or the «embedded» Locator on a different port, you would not have had this problem.

You can start a Locator on a different port using Gfsh with…

gfsh> start locator —name=GemFireLocator —port=11235 —log-level=config

However, if you then want to connect the «SpringBootGemFireServer» to the «existing» Locator (i.e. «GemFireLocator» started in Gfsh), then you must change the spring.gemfire.locators application property to match (e.g. localhost[11235]). This in turn is captured here and set here.

Alternatively, you could have changed the value for spring.gemfire.start-locator application property to, say… localhost[12480], or just simply comment it out. This would have also avoided the j.n.BindException since the external Locator («GemFireLocator») and the «embedded» Locator would then not conflict on port.

Technically, the spring.gemfire.start-locator should have been commented out by default in my sample. My apologies.

1. Other interesting tidbits about «SpringBootGemFireServer»… you have a CacheSever available for cache clients (i.e. ClientCache) applications to connect, hence…

   Cache Server Information
   Server Bind              : localhost
   Server Port              : 40404
   Running                  : true
   Client Connections       : 0
   

This comes from here.

1. And of course, you see the «Factorials» Region…

   Regions     : Factorials
   

So, regarding (which is probably apparent by now)…

Unbelievable, it succeed.

It seems like that your example is to start a new Gemfire locator and a server, not connect to a exist locator.

The SpringBootGemFireServer succeeded to start because you 1) stopped your «GemFireLocator» and 2) the SpringBootGemFireServer was running an «embedded» Locator, apparent from this.

If the SpringBootGemFireServer was not running the «embedded» Locator (service), then you would not have been able to connect (after you stopped your «GemFireLocator»), but you did…

gfsh>stop locator --name GemFireLocator
Stopping Locator running in C:UsersIBM_ADMINGemFireLocator on ADMINIB-CI3Q48M[10334] as GemFireLocator...
Process ID: 7256
Log File: C:UsersIBM_ADMINGemFireLocatorGemFireLocator.log
....

No longer connected to ADMINIB-CI3Q48M[1099].

gfsh>gfsh>list members
"list members" is not available. Reason: Requires connection.

gfsh>connect
Connecting to Locator at [host=localhost, port=10334] ..
Connecting to Manager at [host=ADMINIB-CI3Q48M, port=1199] ..
Successfully connected to: [host=ADMINIB-CI3Q48M, port=1199]

The «SpringBootGemFireServer» is also a «Manager», which is actually the reason you can connect in Gfsh.

When you use Gfsh’s connect without an options, by default, connect tries to find a Locator on «localhost» listening on port 10334, hence this…

Connecting to Locator at [host=localhost, port=10334]

However, the Locator’s responsibility is to find an existing Manager in the cluster and tell the client (i.e. Gfsh) where to find it (i.e. IP address/port). That is why you see the subsequent connect…

Connecting to Manager at [host=ADMINIB-CI3Q48M, port=1199] ..

All of that was made possible by this. If there is not already an existing «Manager» in the cluster, then the Locator is programmed/configured to become the «Manager». The jmx-manager GemFire property enables any member in the cluster to «become» a Manager. However, that does not mean it will startup as a Manager by default. To force the member to be a Manager at start, you must also set the jmx-manager-start GemFire property, as I have done with the SpringBootGemFireServer (of course, I default the value to false by default so it won’t start as a Manager on startup). Anyway…

If you want to connect to an external, «existing» Locator (e.g. «GemFireLocator») started with Gfsh, then…

1. Run…

gfsh> start locator —name=GemFireLocator —log-level=config.

NOTE: keep in mind that GemFireLocator will be listening on the default port (10334) unless you specify the —port option to the start locator command.

1. Make sure you comment out line 8 in the application.properties file picked up by the «SpringBootGemFireServer» application. Alternatively, you can change the embedded Locators port by setting the spring.gemfire.start-locator application property to, say… localhost[11235].

2. (optional) If you set a port for your «external» / «existing» Locator (i.e. «GemFireLocator» started from Gfsh), then be sure to set the spring.gemfire.locators application property to match.

Hope this helps!

Regards,
-John

Ok, first, when you started the GemFire Locator (i.e. «GemFireLocator» using Gfsh), you used the following Gfsh command…

gfsh> start locator —name=GemFireLocator —log-level=config

This resulted in starting the Locator on the default port, 10334, which is not the port you stated previously, 40001, but that is fine; it is easier to run the sample this way.

This is also apparent from the describe member command…

gfsh>describe member —name=GemFireLocator

Which resulted in…

Name        : GemFireLocator
Id          : 192.168.1.106(GemFireLocator:7256:locator):1024
Host        : ADMINIB-CI3Q48M
Regions     :
PID         : 7256
Groups      :
Used Heap   : 90M
Max Heap    : 1755M
Working Dir : C:UsersIBM_ADMINGemFireLocator
Log file    : C:UsersIBM_ADMINGemFireLocatorGemFireLocator.log
Locators    : 192.168.1.106[10334]

The last line…

Locators    : 192.168.1.106[10334]

… reveals that the Locator is listening on port 10334 bound to address 192.168.1.106.

Then, you proceed in starting the GemFire Server using my sample. I suspect not only did you run $ gradlew bootRun from the command-line, but that you followed the instructions to conclusion, including «Running with an Embedded GemFire/Geode Locator»… yes?

It is actually apparent from the new Stack Trace you posted…

...
...
Caused by: java.net.BindException: Failed to create server socket on  localhost/127.0.0.1[10,334]
        at com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:829)
        at com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:789)
        at com.gemstone.org.jgroups.stack.tcpserver.TcpServer.startServerThread(TcpServer.java:179)
        at com.gemstone.org.jgroups.stack.tcpserver.TcpServer.start(TcpServer.java:168)
        at com.gemstone.gemfire.distributed.internal.InternalLocator.startTcpServer(InternalLocator.java:629)
        at com.gemstone.gemfire.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:698)
        at com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.startInitLocator(InternalDistributedSyst
m.java:832)
        ... 37 more
Caused by: java.net.BindException: Address already in use: JVM_Bind
        at java.net.DualStackPlainSocketImpl.bind0(Native Method)
        at java.net.DualStackPlainSocketImpl.socketBind(DualStackPlainSocketImpl.java:106)
        at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
        at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:190)
        at java.net.ServerSocket.bind(ServerSocket.java:375)
        at com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:826)
        ... 43 more

Hence…

Caused by: java.net.BindException: Failed to create server socket on  localhost/127.0.0.1[10,334]

And…

Caused by: java.net.BindException: Address already in use: JVM_Bind

Do not confuse «creating a server socket» with starting a GemFire Server. In Java (as you may already know), whenever you bind an address/port for a «client» application to connect, you use a java.net.ServerSocket.

In this case, a Locator is a «server» and creates a java.net.ServerSocket for any clients (e.g. Gfsh, or other peer members like GemFire (Cache) Servers) that want to connect to the GemFire «cluster» defined by the Locator.

And, as you can see when you stopped the first Locator («GemFireLocator») you started in Gfsh initially, and then ran the sample by itself (and it started successfully!), when you «described» the member, using…

gfsh> describe member —name=SpringBootGemFireServer

     Name           | Id
----------------------- | --------------------------------------------------
SpringBootGemFireServer | ADMINIB-CI3Q48M(SpringBootGemFireServer):37651
gfsh>describe member --name=SpringBootGemFireServer
Name        : SpringBootGemFireServer
Id          : ADMINIB-CI3Q48M(SpringBootGemFireServer):37651
Host        : ADMINIB-CI3Q48M
Regions     : Factorials

PID         : 0
Groups      :
Used Heap   : 117M
Max Heap    : 1755M
Working Dir : C:UsersIBM_ADMINDocumentsWorkspace - ShirleyWorkspace_SpringBootspring-boot-gemfire-server-example
Log file    : C:UsersIBM_ADMINDocumentsWorkspace - ShirleyWorkspace_SpringBootspring-boot-gemfire-server-example
Locators    : localhost[10334]

Cache Server Information
Server Bind              : localhost
Server Port              : 40404
Running                  : true
Client Connections       : 0

You can see several bits of interesting information from the describe member command.

1. First, and most importantly, you see…

   Locators    : localhost[10334]
   

This is the «embedded» Locator. It is listening on port 10334, which is why you encountered the j.n.BindException when your «GemFireLocator» was running the first time.

This means the spring.gemfire.start-locator application property was set, and by default, I see that it is. This in turn sets the GemFire property, start-locator (from the application property), which then causes GemFire to start an «embedded» Locator.

As result, this causes a port conflict when «GemFireLocator» is running since you started the «GemFireLocator» on the default port, 10334.

If you had started the «GemFireLocator» or the «embedded» Locator on a different port, you would not have had this problem.

You can start a Locator on a different port using Gfsh with…

gfsh> start locator —name=GemFireLocator —port=11235 —log-level=config

However, if you then want to connect the «SpringBootGemFireServer» to the «existing» Locator (i.e. «GemFireLocator» started in Gfsh), then you must change the spring.gemfire.locators application property to match (e.g. localhost[11235]). This in turn is captured here and set here.

Alternatively, you could have changed the value for spring.gemfire.start-locator application property to, say… localhost[12480], or just simply comment it out. This would have also avoided the j.n.BindException since the external Locator («GemFireLocator») and the «embedded» Locator would then not conflict on port.

Technically, the spring.gemfire.start-locator should have been commented out by default in my sample. My apologies.

1. Other interesting tidbits about «SpringBootGemFireServer»… you have a CacheSever available for cache clients (i.e. ClientCache) applications to connect, hence…

   Cache Server Information
   Server Bind              : localhost
   Server Port              : 40404
   Running                  : true
   Client Connections       : 0
   

This comes from here.

1. And of course, you see the «Factorials» Region…

   Regions     : Factorials
   

So, regarding (which is probably apparent by now)…

Unbelievable, it succeed.

It seems like that your example is to start a new Gemfire locator and a server, not connect to a exist locator.

The SpringBootGemFireServer succeeded to start because you 1) stopped your «GemFireLocator» and 2) the SpringBootGemFireServer was running an «embedded» Locator, apparent from this.

If the SpringBootGemFireServer was not running the «embedded» Locator (service), then you would not have been able to connect (after you stopped your «GemFireLocator»), but you did…

gfsh>stop locator --name GemFireLocator
Stopping Locator running in C:UsersIBM_ADMINGemFireLocator on ADMINIB-CI3Q48M[10334] as GemFireLocator...
Process ID: 7256
Log File: C:UsersIBM_ADMINGemFireLocatorGemFireLocator.log
....

No longer connected to ADMINIB-CI3Q48M[1099].

gfsh>gfsh>list members
"list members" is not available. Reason: Requires connection.

gfsh>connect
Connecting to Locator at [host=localhost, port=10334] ..
Connecting to Manager at [host=ADMINIB-CI3Q48M, port=1199] ..
Successfully connected to: [host=ADMINIB-CI3Q48M, port=1199]

The «SpringBootGemFireServer» is also a «Manager», which is actually the reason you can connect in Gfsh.

When you use Gfsh’s connect without an options, by default, connect tries to find a Locator on «localhost» listening on port 10334, hence this…

Connecting to Locator at [host=localhost, port=10334]

However, the Locator’s responsibility is to find an existing Manager in the cluster and tell the client (i.e. Gfsh) where to find it (i.e. IP address/port). That is why you see the subsequent connect…

Connecting to Manager at [host=ADMINIB-CI3Q48M, port=1199] ..

All of that was made possible by this. If there is not already an existing «Manager» in the cluster, then the Locator is programmed/configured to become the «Manager». The jmx-manager GemFire property enables any member in the cluster to «become» a Manager. However, that does not mean it will startup as a Manager by default. To force the member to be a Manager at start, you must also set the jmx-manager-start GemFire property, as I have done with the SpringBootGemFireServer (of course, I default the value to false by default so it won’t start as a Manager on startup). Anyway…

If you want to connect to an external, «existing» Locator (e.g. «GemFireLocator») started with Gfsh, then…

1. Run…

gfsh> start locator —name=GemFireLocator —log-level=config.

NOTE: keep in mind that GemFireLocator will be listening on the default port (10334) unless you specify the —port option to the start locator command.

1. Make sure you comment out line 8 in the application.properties file picked up by the «SpringBootGemFireServer» application. Alternatively, you can change the embedded Locators port by setting the spring.gemfire.start-locator application property to, say… localhost[11235].

2. (optional) If you set a port for your «external» / «existing» Locator (i.e. «GemFireLocator» started from Gfsh), then be sure to set the spring.gemfire.locators application property to match.

Hope this helps!

Regards,
-John

Начиная с версии операционной системы iOS 13, для пользователей iPhone стала доступна функция “Локатор”. Она заменила собой два доступных ранее приложения “Найти iPhone” и “Найти друзей”. Преимуществом данного приложения — в возможности не только определить местоположение своих гаджетов, если они потеряны, но и помочь друзьям в аналогичной ситуации.

Рассказываем, как настроить доступные функции приложения “Локатор” на своем iPhone, и как устранить ошибки при использовании данной функции.

Объединив два приложения в одном, производитель предложил своим пользователям удобное и простое в использование решение, позволяющее получить широкий функционал на основе данных о местоположении. Среди основных функций “Локатора” стоит выделить:

Использовать данные о местоположении доступно не только на устройствах с приложением, либо при получении разрешения от других пользователей, но и отследить свои гаджеты, а также личные вещи.

Для примера, можно создать пары для своего смартфона с беспроводными наушниками AirPods и умными часами Apple Watch. А вот найти потерянную вещь, либо отследить местонахождение своего багажа, доступно при прикреплении брелока AirTag.

Однако, чтобы воспользоваться всеми полезными функциями, важно правильно настроить “Локатор”. Рассказываем об этом подробнее.

Для получения данных о местонахождении своего смартфона, других гаджетов, а также делиться своими координатами с близкими, необходимо активировать в приложении функцию “Найти”. Для этого нужно зайти в настройки своего iPhone, и далее выбрать приложение “Локатор”.

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

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

Если же необходимо добавить AirTag, либо настроить поиск девайсов других производителей, поддерживаемых “Локатором”. Необходимо включить устройство, и расположить его рядом с вашим iPhone. После определения, нужно нажать на кнопку “Подключить”, а также выбрать из списка имя, или настроить его в ручном режиме.

Для максимально точного определения местоположения брелока, рекомендуется активировать функцию “Точное геопозиция”. Для этого нужно в настройках “Конфиденциальности” перейти в “Локатор”, и включить нужный режим.

Особенностью продуктов американского производителя, является надежность и точность работы предлагаемых сервисов, что является важным при выборе продукта любым пользователем. Это относится и к сервису “Локатор”.

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

Большинство проблем у пользователей “Локатора”, возникают из-за программного сбоя. Поэтому, если заметили ошибки в работе, или возникли сложности с использованием функций, перезагрузите свой девайс. Это относится не только к смартфону или планшету, являющимися главным устройством, но и привязанные к профилю.

Как показываю отзывы, такое простое действие помогает устранить ошибку менее чем за минуту.

Не стоит забывать, что проблемы могут возникнуть и при использовании новой версии операционной системы. Если говорить про ошибки в работе “Локатора”, то это крайне редкая проблема, если речь идет о версии ПО. Если такие ситуации и возникают, то устраняются производителем в обновлениях очень оперативно.

Еще одной распространенной ошибкой является невозможность определения местоположения друзей и близких, хоть ими предоставлено разрешение, и ранее все работало исправно. В данной ситуации есть два основных пути решения, и исправления неисправности.

Для начало стоит учитывать, что теперь “Локатор” это единое приложение, заменившее собой два доступных ранее. Возможно что добавленный контакт не обновил приложение, что и приводит к возникновению ошибки.

Также может произойти системная ошибка, и в этом случае необходимо обратиться к своим контактам, и попросить их сделать следующее. Для начала необходимо удалить разрешение на определение, и выполнить повторное подключения разрешения на доступ к своему местоположению.

Что ж, в этом случае Stack Trace довольно показательно.

По сути, контейнер Spring не смог создать экземпляр «однорангового узла» GemFire ​​cache (который основан на элементе <gfe:cache> в вашем Spring XML config), потому что GemFire ​​не смог найти локатор, который вы запустили из Gfsh …

Caused by: com.gemstone.gemfire.GemFireConfigException: Unable to contact a Locator service.  Operation either timed out or Locator does not exist.  Configured list of locators is "[localhost(null):40001]".
        at com.gemstone.org.jgroups.protocols.TCPGOSSIP.sendGetMembersRequest(TCPGOSSIP.java:222) ~[gemfire-8.2.4.jar:na]
        at com.gemstone.org.jgroups.protocols.PingSender.run(PingSender.java:85) ~[gemfire-8.2.4.jar:na]
        at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_111]

Следовательно …

c.g.g.GemFireConfigException: Невозможно связаться со службой локатора. Истекло время ожидания операции или локатор не существует.

Далее говорится, что …

Настроенный список локаторов: «[localhost (null): 40001]».

Свойство locators в определении вашего bean-компонента gemfireProperties (которое определяет » Свойства GemFire ​​») — это то, что ожидающий одноранговый узел GemFire, желающий присоединиться к кластеру, использует для поиска локатора GemFire ​​(и, соответственно, кластера, к которому нужно присоединиться). Действительно, одна или несколько конечных точек Locator (например, host1[port1],host2[port2],...,hostN[portN]) определяют кластер, к которому присоединится ожидающий одноранговый член.

Вне вашего искаженного XML для определения bean-компонента gemfireProperties в конфигурации XML Spring значение свойства locators кажется правильным. У вас есть «Локатор», работающий локально, прослушивающий порт 40001, по крайней мере, согласно вашим утверждениям. Однако это НЕ очевидно из команды list members.

Так…

1. Кулак, я полагаю, «test1» — это ваш локатор?

2. И вы запустили свой локатор с помощью … gfsh> start locator --name=tests1 --port=40001 ... (я также предлагаю повысить уровень журнала с помощью --log-level=config)

3. Наконец, я предполагаю, что «server1» действительно является «сервером GemFire»?

Если, например, «‘test1 " is indeed your Locator, then you can get the runtime information for the Locator using status locator` …

gfsh>status locator --name=test1
Locator in /Users/jblum/pivdev/lab/test1 on 10.99.199.10[40001] as test1 is currently online.
Process ID: 89632
Uptime: 1 minute 15 seconds
GemFire Version: 9.0.4
Java Version: 1.8.0_121
Log File: /Users/jblum/pivdev/lab/test1/test1.log
JVM Arguments: -Dgemfire.enable-cluster-configuration=true -Dgemfire.load-cluster-configuration-from-dir=false -Dgemfire.log-level=config -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path: /Users/jblum/Downloads/Pivotal/GemStone/Products/PivotalGemFire/pivotal-gemfire-9.0.4/lib/geode-core-9.0.4.jar:/Users/jblum/Downloads/Pivotal/GemStone/Products/PivotalGemFire/pivotal-gemfire-9.0.4/lib/geode-dependencies.jar

Cluster configuration service is up and running.

Теперь у меня есть проект с документацией / инструкциями, который вы можете использовать для подключения GemFire ​​CacheServer, приложения однорангового кеширования, настроенного с помощью Spring (Data GemFire) и загруженного с помощью Spring Загрузочный , доступен здесь.

Мой локатор «tests1» уже запущен, как показано выше с помощью команды status locator --name=test1 Gfsh . Если я перечислю участников перед запуском моего приложения Spring Boot GemFire ​​peer cache, CacheServer, вы увидите это …

gfsh>list members
Name  | Id
----- | ----------------------------------------------
test1 | 10.99.199.10(test1:89632:locator)<ec><v0>:1024

Затем, когда я запускаю свой встроенный сервер, вы видите это …

gfsh>list members
         Name           | Id
----------------------- | --------------------------------------------------------
test1                   | 10.99.199.10(test1:89632:locator)<ec><v0>:1024
SpringBootGemFireServer | 10.99.199.10(SpringBootGemFireServer:89790)<ec><v1>:1025

ПРИМЕЧАНИЕ. Я запустил сервер из своей среды IDE (IntelliJ IDEA). Конечно, это будет работать и из командной строки.

ПРИМЕЧАНИЕ. Поскольку локатор НЕ работает на порте по умолчанию (например, 10334), он работает на 40001 , вам необходимо настроить пользовательское приложение spring.gemfire.locators Системное свойство JVM перед запуском сервера на «localhost [40001]». Это свойство переводится в свойство GemFire ​​locators здесь и здесь.

Поскольку list members показывает оба процесса GemFire ​​(локатор + сервер), вы знаете, что сервер присоединился к кластеру на основе локатора.

Опять же, не стесняйтесь ссылаться на мой пример.

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

-John

Хорошо, во-первых, когда вы запустили GemFire ​​Locator (т.е. «GemFireLocator» с использованием Gfsh ), вы использовали следующую команду Gfsh …

gfsh> начальный локатор —name = GemFireLocator —log-level = config

Это привело к запуску локатора на порту по умолчанию, 10334 , который не является портом, который вы указали ранее, 40001, но это нормально; таким образом проще запустить образец.

Это также видно из команды describe member …

gfsh> описать член —name = GemFireLocator

Что привело к …

Name        : GemFireLocator
Id          : 192.168.1.106(GemFireLocator:7256:locator):1024
Host        : ADMINIB-CI3Q48M
Regions     :
PID         : 7256
Groups      :
Used Heap   : 90M
Max Heap    : 1755M
Working Dir : C:UsersIBM_ADMINGemFireLocator
Log file    : C:UsersIBM_ADMINGemFireLocatorGemFireLocator.log
Locators    : 192.168.1.106[10334]

Последняя строчка …

Locators    : 192.168.1.106[10334]

… показывает, что локатор прослушивает порт 10334 , связанный с адресом 192.168.1.106 .

Затем вы продолжаете запускать сервер GemFire ​​, используя мой образец. Я подозреваю, что вы не только запустили $ gradlew bootRun из командной строки, но и полностью выполнили инструкции, включая «Запуск со встроенным локатором GemFire ​​/ Geode» … да?

На самом деле это очевидно из размещенного вами нового Stack Trace …

...
...
Caused by: java.net.BindException: Failed to create server socket on  localhost/127.0.0.1[10,334]
        at com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:829)
        at com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:789)
        at com.gemstone.org.jgroups.stack.tcpserver.TcpServer.startServerThread(TcpServer.java:179)
        at com.gemstone.org.jgroups.stack.tcpserver.TcpServer.start(TcpServer.java:168)
        at com.gemstone.gemfire.distributed.internal.InternalLocator.startTcpServer(InternalLocator.java:629)
        at com.gemstone.gemfire.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:698)
        at com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.startInitLocator(InternalDistributedSyst
m.java:832)
        ... 37 more
Caused by: java.net.BindException: Address already in use: JVM_Bind
        at java.net.DualStackPlainSocketImpl.bind0(Native Method)
        at java.net.DualStackPlainSocketImpl.socketBind(DualStackPlainSocketImpl.java:106)
        at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
        at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:190)
        at java.net.ServerSocket.bind(ServerSocket.java:375)
        at com.gemstone.gemfire.internal.SocketCreator.createServerSocket(SocketCreator.java:826)
        ... 43 more

Следовательно …

Caused by: java.net.BindException: Failed to create server socket on  localhost/127.0.0.1[10,334]

А также…

Caused by: java.net.BindException: Address already in use: JVM_Bind

Не путайте «создание серверного сокета» с запуском сервера GemFire. В Java (как вы, возможно, уже знаете) всякий раз, когда вы привязываете адрес / порт для «клиентского» приложения для подключения, вы используете java.net.ServerSocket.

В этом случае локатор является «сервером» и создает java.net.ServerSocket для любых клиентов (например, Gfsh или других одноранговых участников, таких как серверы GemFire ​​(Cache)), которые хотят подключиться к «Кластер» GemFire, определенный локатором.

И, как вы можете видеть, когда вы остановили первый локатор («GemFireLocator»), вы сначала запустили его в Gfsh , а затем запустили образец отдельно (и он запустился успешно!), Когда вы «описали» член, использующий …

gfsh> описать член —name = SpringBootGemFireServer

     Name           | Id
----------------------- | --------------------------------------------------
SpringBootGemFireServer | ADMINIB-CI3Q48M(SpringBootGemFireServer):37651
gfsh>describe member --name=SpringBootGemFireServer
Name        : SpringBootGemFireServer
Id          : ADMINIB-CI3Q48M(SpringBootGemFireServer):37651
Host        : ADMINIB-CI3Q48M
Regions     : Factorials

PID         : 0
Groups      :
Used Heap   : 117M
Max Heap    : 1755M
Working Dir : C:UsersIBM_ADMINDocumentsWorkspace - ShirleyWorkspace_SpringBootspring-boot-gemfire-server-example
Log file    : C:UsersIBM_ADMINDocumentsWorkspace - ShirleyWorkspace_SpringBootspring-boot-gemfire-server-example
Locators    : localhost[10334]

Cache Server Information
Server Bind              : localhost
Server Port              : 40404
Running                  : true
Client Connections       : 0

Вы можете увидеть несколько фрагментов интересной информации из команды describe member.

1. Во-первых, и самое главное, видите ли …

   Locators    : localhost[10334]
   

Это «встроенный» локатор. Он прослушивает порт 10334 , поэтому вы столкнулись с j.n.BindException, когда ваш «GemFireLocator» работал в первый раз.

Это означает, что свойство приложения spring.gemfire.start-locator было установлено, и по умолчанию, я вижу, что это. Это, в свою очередь, устанавливает свойство GemFire ​​, start-locator ( из свойства приложения), что затем заставляет GemFire ​​запускать« встроенный »локатор.

В результате это вызывает конфликт портов, когда «GemFireLocator» работает, так как вы запустили «GemFireLocator» на порту по умолчанию, 10334 .

Если бы вы запустили «GemFireLocator» или «встроенный» локатор на другом порту, у вас бы не было этой проблемы.

Вы можете запустить локатор на другом порту, используя Gfsh с …

gfsh> начальный локатор —name = GemFireLocator —port = 11235 —log-level = config

Однако, если вы затем захотите подключить SpringBootGemFireServer к «существующему» локатору (например, «GemFireLocator», запущенному в Gfsh ), вы должны изменить spring.gemfire.locators свойство приложения, чтобы совпадение (например, localhost[11235]). Это, в свою очередь, записано здесь и установлено здесь.

В качестве альтернативы вы могли изменить значение для spring.gemfire.start-locator свойство приложения, скажем … localhost[12480], или просто закомментируйте . Это также позволило бы избежать j.n.BindException, поскольку внешний локатор («GemFireLocator») и «встроенный» локатор не будут конфликтовать на порте.

Технически, в моем примере spring.gemfire.start-locator должен был быть закомментирован по умолчанию. Мои извенения.

1. Другие интересные факты о «SpringBootGemFireServer» … у вас есть CacheSever, доступный для подключения к приложениям клиентов кеширования (т. Е. ClientCache), следовательно …

   Cache Server Information
   Server Bind              : localhost
   Server Port              : 40404
   Running                  : true
   Client Connections       : 0
   

Это происходит из здесь.

1. И, конечно же, вы видите регион «Факториалы» …

   Regions     : Factorials
   

Итак, что касается (что, вероятно, уже очевидно) …

Невероятно, но это удалось.

Похоже, что ваш пример — запустить новый локатор Gemfire и сервер, а не подключаться к существующему локатору.

SpringBootGemFireServer удалось запустить, потому что вы 1) остановили свой «GemFireLocator» и 2) SpringBootGemFireServer запускал «встроенный» локатор, очевидно из this.

Если на SpringBootGemFireServer не был запущен «встроенный» локатор (служба), то вы не смогли бы подключиться (после того, как остановили «GemFireLocator»), но вы делал…

gfsh>stop locator --name GemFireLocator
Stopping Locator running in C:UsersIBM_ADMINGemFireLocator on ADMINIB-CI3Q48M[10334] as GemFireLocator...
Process ID: 7256
Log File: C:UsersIBM_ADMINGemFireLocatorGemFireLocator.log
....

No longer connected to ADMINIB-CI3Q48M[1099].

gfsh>gfsh>list members
"list members" is not available. Reason: Requires connection.

gfsh>connect
Connecting to Locator at [host=localhost, port=10334] ..
Connecting to Manager at [host=ADMINIB-CI3Q48M, port=1199] ..
Successfully connected to: [host=ADMINIB-CI3Q48M, port=1199]

«SpringBootGemFireServer» также является «менеджером», и именно поэтому вы можете подключиться в Gfsh .

Когда вы используете Gfsh connect без параметров, по умолчанию connect пытается найти локатор на «localhost», прослушивающий порт 10334 , поэтому это …

Connecting to Locator at [host=localhost, port=10334]

Однако ответственность локатора заключается в том, чтобы найти существующего диспетчера в кластере и сообщить клиенту (т. Е. Gfsh ), где его найти (т. Е. IP-адрес / порт). Вот почему вы видите последующее подключение …

Connecting to Manager at [host=ADMINIB-CI3Q48M, port=1199] ..

Все это стало возможным благодаря это. Если в кластере еще нет существующего «Менеджера», тогда Локатор запрограммирован / настроен как «Менеджер». jmx-manager Свойство GemFire ​​ позволяет любому члену кластера« стать »менеджером. Однако это не означает, что по умолчанию он будет запускаться как менеджер. Чтобы заставить участника быть менеджером при запуске, вы также должны установить jmx-manager-start свойство GemFire ​​, как я сделал с SpringBootGemFireServer (конечно, я по умолчанию использую значение false по умолчанию, поэтому он не запускается как менеджер при запуске). В любом случае…

Если вы хотите подключиться к внешнему «существующему» локатору (например, «GemFireLocator»), запущенному с Gfsh , тогда …

1. Запустить…

Gfsh> начальный локатор —name = GemFireLocator —log-level = config.

ПРИМЕЧАНИЕ: имейте в виду, что GemFireLocator будет прослушивать порт по умолчанию (10334), если вы не укажете параметр —port для команды start locator.

1. Убедитесь, что вы закомментировали строка 8 в файле application.properties, полученном приложением» SpringBootGemFireServer «. Кроме того, вы можете изменить порт встроенных локаторов, установив для свойства приложения spring.gemfire.start-locator значение, скажем … localhost[11235].

2. (необязательно) Если вы устанавливаете порт для своего «внешнего» / «существующего» локатора (например, «GemFireLocator» запускается из Gfsh ), обязательно установите spring.gemfire.locators свойство приложения чтобы соответствовать.

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

С уважением, Джон