----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/47254/#review132773 -----------------------------------------------------------
Why would a single client want both its primary and secondary queue to be from the same JVM? The server JVM becomes a single point of failure for the client who think the queue will be HA. In this case I don't see the secondary queue on the same JVM having any benefit, and it will consume extra memory on that server JVM. I think the client should be made smart enough to not create a secondary to the same JVM as the primary. It is also questionable for it to create a secondary to a server on the same machine as the primary. Seems similiar to the canonical host stuff we have for redundant PR buckets. - Darrel Schneider On May 11, 2016, 2:29 p.m., xiaojian zhou wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/47254/ > ----------------------------------------------------------- > > (Updated May 11, 2016, 2:29 p.m.) > > > Review request for geode, anilkumar gingade, Barry Oglesby, and Bruce > Schuchardt. > > > Bugs: geode-1183 > https://issues.apache.org/jira/browse/geode-1183 > > > Repository: geode > > > Description > ------- > > I found this bug in my test using 2 cache servers in one JVM. Our API allows > user to do that. > > We had a lot of dicussion with anil and barry. However, we think it's better > to invite people from jgroup team to review the fix too. > > When created 2 cache servers (server1 and server2) on the same JVM and turned > on subscription, the client handshake will try to create a secondary on > server1 then primary on server2. > > However, when creating primary proxy on server2, it found the proxy already > exists (i.e. the one for secondary). So our current code will delete the > existing proxy and create a new one (if it's durable client, it will > reinitialize). > > But the deletion will trigger the handshake thread to retry, recreate and > delete the exiting one. It will keep doing that endlessly. According to my > test, within one minute, there're hundreds of recreating. > > The fix is not to delete the "stale proxy" for normal client if its socket is > still connecting. > Not to reinitialize the proxy if it's primary in case of durable client. > > > Diffs > ----- > > > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CacheClientNotifier.java > 1ba2294 > > geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/CacheClientNotifierDUnitTest.java > 9557f0d > > geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/Simple2CacheServerDUnitTest.java > PRE-CREATION > > Diff: https://reviews.apache.org/r/47254/diff/ > > > Testing > ------- > > > Thanks, > > xiaojian zhou > >
