geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-2732) after auto-reconnect a server is restarted on the default port of 40404
Date Fri, 07 Apr 2017 19:50:41 GMT


ASF subversion and git services commented on GEODE-2732:

Commit 391502a2615dbc80cde0b9a111fa967f4d76c39a in geode's branch refs/heads/feature/GEODE-2632
from [~bschuchardt]
[;h=391502a ]

GEODE-2732 after auto-reconnect a server is restarted on the default port

Gfsh command line parameters were put into ThreadLocals to make them
available to the XML parser.  These are now held in non-thread-local
variables so that all threads, including the auto-reconnect thread,
can see them when building the cache.

> after auto-reconnect a server is restarted on the default port of 40404
> -----------------------------------------------------------------------
>                 Key: GEODE-2732
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: membership
>            Reporter: Bruce Schuchardt
>             Fix For: 1.2.0
> If you start a server using gfsh with the server defined in a cache.xml and you specify
the server's port Geode will ignore this setting in the event of an auto-reconnect.  I observed
this in a GemFire deployment and the code in this area hasn't changed in Apache Geode.  By
chance port 40404 was already in use when the auto-reconnect occurred and an exception was
> {noformat}
> com.gemstone.gemfire.GemFireIOException: While starting bridge server  CacheServer on
port=40404 client subscription config policy=none client subscription config capacity=1 client
subscription config overflow directory=.
> 	at com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(
> 	at com.gemstone.gemfire.internal.cache.xmlcache.CacheXmlParser.create(
> 	at com.gemstone.gemfire.internal.cache.GemFireCacheImpl.loadCacheXml(
> 	at com.gemstone.gemfire.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(
> 	at com.gemstone.gemfire.internal.cache.GemFireCacheImpl.init(
> 	at com.gemstone.gemfire.internal.cache.GemFireCacheImpl.create(
> 	at com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.reconnect(
> 	at com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.tryReconnect(
> 	at com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.disconnect(
> 	at com.gemstone.gemfire.distributed.internal.DistributionManager$MyListener.membershipFailure(
> 	at com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager.uncleanShutdown(
> 	at com.gemstone.gemfire.distributed.internal.membership.jgroup.JGroupMembershipManager$Puller.channelClosing(
> 	at$
> Caused by: Address already in use
> 	at Method)
> 	at
> 	at
> 	at
> 	at
> 	at com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl.<init>(
> 	at com.gemstone.gemfire.internal.cache.BridgeServerImpl.start(
> 	at com.gemstone.gemfire.internal.cache.xmlcache.CacheCreation.create(
> 	... 12 more
> {noformat}
> I think the fix is to get rid of the ThreadLocal storage of the port and bind address
in CacheServerLauncher.  These variables are used by the XML parser to configure a server.
 Gfsh sets them in its thread but they aren't available in the auto-reconnect thread that
rebuilds the cache.

This message was sent by Atlassian JIRA

View raw message