[
https://issues.apache.org/jira/browse/QPID-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16343277#comment-16343277
]
Alex Rudyy commented on QPID-8086:
----------------------------------
The changes in commit
[039f79b5388dd9bfd21a6b1e1bad8ac9c9065361|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=039f79b]
look reasonable to me. Please, merge them into necessary branches
> [Broker-J] Create tool to permit recovery from QPID-8066
> --------------------------------------------------------
>
> Key: QPID-8086
> URL: https://issues.apache.org/jira/browse/QPID-8086
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Keith Wall
> Assignee: Keith Wall
> Priority: Major
> Fix For: qpid-java-broker-7.0.1, qpid-java-6.1.6
>
>
> Defect QPID-8066 has the potential to leave the Broker in a state where it
> cannot be restarted. The recovery phase, on encountering the orphan records,
> throws an exception and this puts the virtualhost into an {{ERROR}} state.
> There is no facility in Broker-J to recover from this short of recreation of
> the virtualhost.
> If the configuration store is backed by JDBC, then a workaround is to connect
> to the database and remove the offending rows. Unfortunately if the
> virtualhost is backed by BDB (for configuration) or BDB HA, the user has no
> convenient way to recover the situation. BDB JE has no command line
> interface so a Java program would have to be written with knowledge of the
> store's structure. The HA case is further complicated by the fact that
> sufficient nodes would have to be available to provide quorum within the
> group.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
