activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arthur Naseef (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-5018) LockFile unlock method not reliable in case of network issues
Date Thu, 13 Mar 2014 12:23:46 GMT

    [ https://issues.apache.org/jira/browse/AMQ-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933168#comment-13933168
] 

Arthur Naseef commented on AMQ-5018:
------------------------------------

That workaround only makes sense if the JVM is not fully shutting down.  Is that the case?

With that said, it's a good fix to add.

> 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.2#6252)

Mime
View raw message