activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Holzmann (JIRA)" <>
Subject [jira] [Commented] (AMQ-5018) LockFile unlock method not reliable in case of network issues
Date Tue, 04 Feb 2014 08:56:10 GMT


Oliver Holzmann commented on AMQ-5018:

I solved this issue by ensuring that the system property is removed during shutdown:

public class CustomFileLocker extends SharedFileLocker {

  private String vmLockKey;

  public void doStart() throws Exception {
    vmLockKey = LockFile.class.getName() + ".lock."
        + new File(directory, "lock").getCanonicalPath();

  public void doStop(ServiceStopper stopper) throws Exception {
    try {
    } finally {

> LockFile unlock method not reliable in case of network issues
> -------------------------------------------------------------
>                 Key: AMQ-5018
>                 URL:
>             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 " 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

View raw message