activemq-dev mailing list archives

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

    [ 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)

Mime
View raw message