[
https://issues.apache.org/jira/browse/AMQ-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933257#comment-13933257
]
Gary Tully commented on AMQ-5018:
---------------------------------
the reastartAllowed=false broker attribute should cause the jvm to exit in this
case. The related issue is https://issues.apache.org/jira/browse/AMQ-4526
The stop should clear that property, the use case for the jvm lock is really
just testing - to easily validate master/slave in a single jvm for failover etc.
> 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)
