[
https://issues.apache.org/jira/browse/AMQ-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13890504#comment-13890504
]
Oliver Holzmann commented on AMQ-5018:
--------------------------------------
I solved this issue by ensuring that the system property is removed during
shutdown:
{code}
public class CustomFileLocker extends SharedFileLocker {
private String vmLockKey;
@Override
public void doStart() throws Exception {
super.doStart();
vmLockKey = LockFile.class.getName() + ".lock."
+ new File(directory, "lock").getCanonicalPath();
}
@Override
public void doStop(ServiceStopper stopper) throws Exception {
try {
super.doStop(stopper);
} finally {
System.getProperties().remove(vmLockKey);
}
}
{code}
> LockFile unlock method not reliable in case of network issues
> -------------------------------------------------------------
>
> Key: AMQ-5018
> URL: https://issues.apache.org/jira/browse/AMQ-5018
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.9.0
> Environment: MS Windows Server 2003 R2 SP2
> Reporter: Oliver Holzmann
>
> We run ActiveMQ cluster with kahaDB persistence. Persistence store is located
> on a shared network folder.
> In case of a network glitch we have "java.io.IOException: The specified
> network name is no longer available" and the broker performs a restart.
> During shutdown the SharedFileLocker doStop method triggers LockFile to
> unlock. But due to the io error accessing the lockfile the system property
> created from "getVmLockKey()" could not be removed.
> On restart the still set system property leads to this exception: "File ...
> could not be locked as lock is already held for this jvm" and the broker
> keeps inactive until restarting the windows service.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
