Mailing-List: contact issues-help@geode.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geode.incubator.apache.org
Date: Thu, 25 Aug 2016 00:04:20 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: issues@geode.incubator.apache.org
Message-ID: <JIRA.12999858.1472083003000.403758.1472083460529@Atlassian.JIRA>
In-Reply-To: <JIRA.12999858.1472083003000@Atlassian.JIRA>
References: <JIRA.12999858.1472083003000@Atlassian.JIRA> <JIRA.12999858.1472083003584@arcas>
Subject: [jira] [Commented] (GEODE-1816) CacheServerLauncher uses static
 threadlocals to launch server
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 25 Aug 2016 00:04:25 -0000


    [ https://issues.apache.org/jira/browse/GEODE-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15435975#comment-15435975 ] 

ASF subversion and git services commented on GEODE-1816:
--------------------------------------------------------

Commit 98531a16f8844a1028e2e6de293eb080d8ea7a1d in incubator-geode's branch refs/heads/develop from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=98531a1 ]

GEODE-1816: Workaround to clear statics in CacheCreationJUnitTest

Working around the fact that other tests are leaving static thread
locals set, causing this test to fail. The actual fix is to remove the
static thread locals from the product.


> CacheServerLauncher uses static threadlocals to launch server
> -------------------------------------------------------------
>
>                 Key: GEODE-1816
>                 URL: https://issues.apache.org/jira/browse/GEODE-1816
>             Project: Geode
>          Issue Type: Bug
>          Components: management
>            Reporter: Dan Smith
>
> The CacheServerLauncher class has 3 static threadlocals 
> {code}
>   public static ThreadLocal<Integer> serverPort = new ThreadLocal<Integer>();
>   public static ThreadLocal<String> serverBindAddress = new ThreadLocal<String>();
>   public static ThreadLocal<Boolean> disableDefaultServer = new ThreadLocal<Boolean>();
> {code}
> These get set when a server is launched. Then down in CacheCreation.create, it reads these thread locals and uses them to add a cache server.
> Unfortunately this causes lots of pain writing unit tests, because tests can end up setting these thread locals and they are never cleared. Statics and thread locals should pretty much never be used. Especially in this case it seems like there are several easy ways to create a cache server after the cache is created, or pass properties in while creating the cache.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)