Pipeline results can be found at:
Concourse:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/639
---
Spring Data GemFire > Nightly-ApacheGeode > #906 was successful.
---
Scheduled
2380 tests in total.
https://build.spring.io/browse/SGF-NAG-906/
--
This
Thanks John!
On Thu, May 3, 2018 at 11:28 AM, John Blum wrote:
> Kirk-
>
> Follow this logic...
>
>
> [1]
> https://github.com/spring-projects/spring-session-data-
> geode/blob/master/samples/boot/gemfire/src/main/java/sample/client/
> IntegrationTestConfiguration.java#L70-L71
>
> Which is based
The serverSocket is bound to an address in AcceptorImpl's constructor.
If you want to wait until accept() is invoked you'll need to add some
other state that can be checked.
On 5/3/18 12:03 PM, John Blum wrote:
Kirk-
Please see your other email thread and my response [1] to that as 1
potent
Kirk-
Please see your other email thread and my response [1] to that as 1
potential way to handle this situation. As I mentioned, I use this in the
Spring Session client/server integration tests as a way to mitigate the
NoSubscriptionsServersAvailableException.
-j
[1] http://markmail.org/messag
That smells like a bug to me. We don't have to be in accept() though -
we just need to have the serversocket open and with sufficient backlog
to queue the connection requests. Adding a check for whether the socket
is open in isRunning() might be good enough.
On 5/3/18 11:26 AM, Kirk Lund wr
Looks like the problem is in QueueManagerImpl initialization so my
suggestions won't fix the problem.
Caused by:
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not
initialize a primary queue on startup. No queue servers available.
at
org.apache.geode.cache.client.interna
Kirk-
Follow this logic...
[1]
https://github.com/spring-projects/spring-session-data-geode/blob/master/samples/boot/gemfire/src/main/java/sample/client/IntegrationTestConfiguration.java#L70-L71
Which is based on the Registration of a ClientMembershipListener...
[2]
https://github.com/spring-p
The method CacheServer.isRunning() is actually invoked from within the
AcceptorImpl.accept():
while (isRunning()) {
...
try {
socket = serverSock.accept();
So we can't modify isRunning() to check serverSock.isBound(). We would have
to introduce a new User API on CacheServe
Right now every single IntegrationTest or DistributedTest that starts a
server and then starts a client is at risk of hitting this risk and
flickering because the CacheServer isn't truly ready after the invocation
to CacheServer.start() returns. And you can see these failing
intermittently on https
Anil and I were hoping that adding line 4 below would remove the race, but
it doesn't. CacheServer.isRunning() returns true as soon as AcceptorImpl is
non-null which is still before ServerSocket.accept() has been invoked. The
race still exists with this...
1: CacheServer cacheServer = getCache().a
I have a test which starts a server and then starts a client. But the
client intermittently fails with NoSubscriptionServersAvailableException
(see full stack below).
Seems like there must be something asynchronous in the startup of a
CacheServer that I need to wait for. Any ideas what I need to t
12 matches
Mail list logo
