spring-session: Travis CI fails occasionally due to GemFire sample integration test failure

Hi @shou1dwe -

My apologies for the delayed response.

Regarding 1 - LATCH logic and ClientMembershipListener.memberJoined(..)…

The logic here and here (or rather here) ONLY signifies that the “cache client” successfully established a “Pool connection” to the server.

It DOES NOT signify “the connection” between the cache client and the server’s subscription queue (manager) for the client, from which events based on the cache clients (registered) “Interests” will be delivered, has been established.

I.e. when a client connects to a server (via the Pool) and the initial handshake is complete, the server will establish a subscription queue from which to send events of “interests” to the client. Well, when the client first connects, this queue will obviously not exist yet and so takes sometime to initialize. Only after this queue has been established by the server will the client be able to register (express) interests and receive events, and the client receives those events on this “separate, non-Pool” connection. If this connection has not been established yet, then any registerInterests call initiated by the client will fail until then.

Regarding 2…

Your following logic is confused…

PoolImpl.getAll().forEach p -> p.isPrimaryUpdaterAlive

It does not do this for each connection in the Pool, as my logic here clearly shows. I.e. I am not iterating over any Pool connections.

Basically, I am simply asking “the Pool” whether the subscription queue has been established (on the server) and whether the client has opened and connected to the subscription queue manager in order to be able to receive events.

In fact, that connection, between the client and the subscription queue on the server from which events of interests are delivered, is NOT even a Pool connection; it is separate, which also means this logic DOES NOT determine “there is one minimum connection available in the pool.”

Anyway, in summary…

1. A client connects to a server via a Pool of connections.

2. A client will send data access operations (e.g. Region.get(key) / Region.puts(key, value)) performed on the client to the server via Pool connections.

3. A client will registerInterests using a Pool connection. However, a client is not permitted to register interests until the corresponding subscription queue has been established on the server and the client has separately opened a connection from which it will receive queue events.

The reason for all of this logic in my Spring Session Data GemFire (and Boot) samples is that this code is ran through automated integration tests and so “timing” this correctly is tricky.

You typically do not want nor even need to do this in your own application logic and you certainly do no want your application to depend on GemFire internal classes to figure this sort of thing out. This was only necessary for the automated nature of the tests.

However, it would be nice if GemFire provided additional hooks (or callbacks) for this sort of automated integration testing, which may not be that uncommon, especially in a client/server topology where a developer may be testing different UCs and interests.

Hope this helps to clear the muddy water a bit more.

Cheers! -John