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)
