You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Jens Deppe (JIRA)" <ji...@apache.org> on 2016/01/06 23:40:40 UTC
[jira] [Created] (GEODE-733) Cluster Config service can throw a
spurious exception
Jens Deppe created GEODE-733:
--------------------------------
Summary: Cluster Config service can throw a spurious exception
Key: GEODE-733
URL: https://issues.apache.org/jira/browse/GEODE-733
Project: Geode
Issue Type: Bug
Components: management
Reporter: Jens Deppe
Occasionally this exception has been seen:
{noformat}
info 2015/04/07 19:08:34.129 UTC locator0 <locator request thread[44]> tid=0x135a0] Attempting to unlock <DLockService@55d6956e named __CLUSTER_CONFIG_LS de
stroyed=false grantorId=[LockGrantorId: lockGrantorMember=10.138.46.164(locator0:1522:locator)<ec><v0>:55053, lockGrantorVersion=1, lockGrantorSerialNumber=3]
grantor=<DLockGrantor@41c8af04 state=READY name=__CLUSTER_CONFIG_LS version=1>> : __CLUSTER_CONFIG_LOCK , but this thread does not own the lock.
com.gemstone.gemfire.distributed.LockNotHeldException: Attempting to unlock <DLockService@55d6956e named __CLUSTER_CONFIG_LS destroyed=false grantorId=[LockG
rantorId: lockGrantorMember=10.138.46.164(locator0:1522:locator)<ec><v0>:55053, lockGrantorVersion=1, lockGrantorSerialNumber=3] grantor=<DLockGrantor@41c8af0
4 state=READY name=__CLUSTER_CONFIG_LS version=1>> : __CLUSTER_CONFIG_LOCK , but this thread does not own the lock.
at com.gemstone.gemfire.distributed.internal.locks.DLockService.unlock(DLockService.java:1941)
at com.gemstone.gemfire.distributed.internal.SharedConfiguration.createConfigurationReponse(SharedConfiguration.java:376)
at com.gemstone.gemfire.management.internal.configuration.handlers.ConfigurationRequestHandler.processRequest(ConfigurationRequestHandler.java:44)
at com.gemstone.gemfire.distributed.internal.InternalLocator$LocatorHandler.processRequest(InternalLocator.java:1394)
at com.gemstone.org.jgroups.stack.tcpserver.TcpServer$3.run(TcpServer.java:373)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
The problem is that there is an unlock in a finally block but no check to determine if the lock is actually being held.
This was looked at previously and the proposed solution was:
{noformat}
--- a/src/com/gemstone/gemfire/distributed/internal/SharedConfiguration.java
+++ b/src/com/gemstone/gemfire/distributed/internal/SharedConfiguration.java
@@ -362,8 +362,9 @@ public class SharedConfiguration {
for (int i=0; i<configRequest.getNumAttempts(); i++) {
boolean isLocked = sharedConfigLockingService.lock(SHARED_CONFIG_LOCK_NAME, 5000, 5000);
- try {
- if (isLocked) {
+
+ if (isLocked) {
+ try {
logger.info("Building up configuration response with following configurations");
Set<String> groups = configRequest.getGroups();
groups.add(SharedConfiguration.CLUSTER_CONFIG);
@@ -381,10 +382,10 @@ public class SharedConfiguration {
}
configResponse.setFailedToGetSharedConfig(false);
return configResponse;
+ }finally {
+ sharedConfigLockingService.unlock(SHARED_CONFIG_LOCK_NAME);
}
- } finally {
- sharedConfigLockingService.unlock(SHARED_CONFIG_LOCK_NAME);
- }
+ }
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)