[jira] [Commented] (AMQ-3692) ActiveMQ OSGi bundle should be stopped when broker stops itself
[
https://issues.apache.org/jira/browse/AMQ-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278518#comment-14278518
]
metatech commented on AMQ-3692:
---
Here is a workaround that allows to use the Blueprint XBean syntax, with
blueprint.aries.xml-validation:=false.
I did not find how to enhance the validator to allow it yet.
{code}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:cm=http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0;
xmlns:ext=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0;
xmlns:amq=http://activemq.apache.org/schema/core;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core-5.5.0.xsd;
manifest
Bundle-SymbolicName: activemq-broker.xml;
blueprint.aries.xml-validation:=false
/manifest
broker
shutdownHooks
bean class=org.apache.activemq.util.osgi.BrokerBundleWatcher
xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
property name=bundleContext ref=blueprintBundleContext/
/bean
/shutdownHooks
/broker
/blueprint
{code}
Without it, the error is the following in ServiceMix 4.5.3 :
{code}
Unable to start blueprint container for bundle activemq-broker.xml
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
validate xml
at org.apache.aries.blueprint.container.Parser.validate(Parser.java:288)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:281)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:230)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching
wildcard is strict, but no declaration can be found for element 'bean'.
{code}
ActiveMQ OSGi bundle should be stopped when broker stops itself
---
Key: AMQ-3692
URL: https://issues.apache.org/jira/browse/AMQ-3692
Project: ActiveMQ
Issue Type: New Feature
Components: Broker
Affects Versions: 5.4.2
Environment: ServiceMix 4.3
Reporter: metatech
Assignee: Hiram Chirino
Fix For: 5.9.0
Attachments: BrokerBundleWatcher.patch, BrokerBundleWatcher_v2.patch,
BrokerBundleWatcher_v3.patch, BrokerService.patch, activemq-broker.xml
In case of error, the ActiveMQ broker can stop itself.
In an OSGi/Blueprint environment, the bundle is however still in
Active/Created state, which misleads an external monitoring software into
thinking that the broker is running fine.
This patch stops the bundle when the broker stops itself.
This patch can also auto-restart the bundle, which will restart the broker.
This is critical in an Master/Slave configuration : when the connection to
the database is lost, the broker cannot maintain the DB exclusive lock, and
it stops itself. The bundle should be stopped and started again, so that it
enters again the Creating state, in which it waits to obtain the DB lock
again.
The class BrokerBundleWatcher needs to be registered with the
shutdownHooks property of the ActiveMQ BrokerService. However, there is
a limitation with the XBean syntax in a Blueprint XML, which does not allow
to define inner beans. The workaround is to define the activemq-broker.xml
in full native Blueprint syntax (no XBean).
The patch also provides a modified version of the BrokerService, that injects
its own reference into the ShutdownHook's which implement the
BrokerServiceAware interface.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-3692) ActiveMQ OSGi bundle should be stopped when broker stops itself
[ https://issues.apache.org/jira/browse/AMQ-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756105#comment-13756105 ] metatech commented on AMQ-3692: --- For the record, this design choice has the following impact : in a cluster of 2 nodes with a common database (using the DefaultDatabaseLocker), it means that when both nodes have at some point lost their connection to the database, none of the 2 ActiveMQ broker nodes is not restarted anymore and therefore all JMS routes are in error until a manual restart of the ActiveMQ broker bundle is launched. For our mission-critical usage of ServiceMix, this was not considered as acceptable and this is the reason why we created the BrokerBundleWatcher. Another (less elegant) solution would be to write a script that monitors the broker and restarts the ActiveMQ broker in case of error. ActiveMQ OSGi bundle should be stopped when broker stops itself --- Key: AMQ-3692 URL: https://issues.apache.org/jira/browse/AMQ-3692 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.4.2 Environment: ServiceMix 4.3 Reporter: metatech Assignee: Hiram Chirino Fix For: 5.9.0 Attachments: activemq-broker.xml, BrokerBundleWatcher.patch, BrokerBundleWatcher_v2.patch, BrokerBundleWatcher_v3.patch, BrokerService.patch In case of error, the ActiveMQ broker can stop itself. In an OSGi/Blueprint environment, the bundle is however still in Active/Created state, which misleads an external monitoring software into thinking that the broker is running fine. This patch stops the bundle when the broker stops itself. This patch can also auto-restart the bundle, which will restart the broker. This is critical in an Master/Slave configuration : when the connection to the database is lost, the broker cannot maintain the DB exclusive lock, and it stops itself. The bundle should be stopped and started again, so that it enters again the Creating state, in which it waits to obtain the DB lock again. The class BrokerBundleWatcher needs to be registered with the shutdownHooks property of the ActiveMQ BrokerService. However, there is a limitation with the XBean syntax in a Blueprint XML, which does not allow to define inner beans. The workaround is to define the activemq-broker.xml in full native Blueprint syntax (no XBean). The patch also provides a modified version of the BrokerService, that injects its own reference into the ShutdownHook's which implement the BrokerServiceAware interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3692) ActiveMQ OSGi bundle should be stopped when broker stops itself
[ https://issues.apache.org/jira/browse/AMQ-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13467613#comment-13467613 ] Gary Tully commented on AMQ-3692: - there is also some overlap with http://svn.apache.org/viewvc/activemq/trunk/activemq-spring/src/main/java/org/apache/activemq/hooks/SpringOsgiContextHook.java?view=markup which is referenced, to implement simple bundle shutdown, with bean id=hook in http://svn.apache.org/viewvc/activemq/trunk/activemq-karaf/src/main/resources/org/apache/activemq/karaf/commands/spring.xml?view=corevision=1390204content-type=text%2Fplain The objective seems to be the same, but you have some extra restart smarts in your patch. I wonder can we combine the two in some way? ActiveMQ OSGi bundle should be stopped when broker stops itself --- Key: AMQ-3692 URL: https://issues.apache.org/jira/browse/AMQ-3692 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.4.2 Environment: ServiceMix 4.3 Reporter: metatech Fix For: 5.8.0 Attachments: activemq-broker.xml, BrokerBundleWatcher.patch, BrokerBundleWatcher_v2.patch, BrokerService.patch In case of error, the ActiveMQ broker can stop itself. In an OSGi/Blueprint environment, the bundle is however still in Active/Created state, which misleads an external monitoring software into thinking that the broker is running fine. This patch stops the bundle when the broker stops itself. This patch can also auto-restart the bundle, which will restart the broker. This is critical in an Master/Slave configuration : when the connection to the database is lost, the broker cannot maintain the DB exclusive lock, and it stops itself. The bundle should be stopped and started again, so that it enters again the Creating state, in which it waits to obtain the DB lock again. The class BrokerBundleWatcher needs to be registered with the shutdownHooks property of the ActiveMQ BrokerService. However, there is a limitation with the XBean syntax in a Blueprint XML, which does not allow to define inner beans. The workaround is to define the activemq-broker.xml in full native Blueprint syntax (no XBean). The patch also provides a modified version of the BrokerService, that injects its own reference into the ShutdownHook's which implement the BrokerServiceAware interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3692) ActiveMQ OSGi bundle should be stopped when broker stops itself
[ https://issues.apache.org/jira/browse/AMQ-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13467970#comment-13467970 ] metatech commented on AMQ-3692: --- Gary: the SpringOsgiContextHook uses Spring DM-specific API, where the BrokerBundleWatcher only uses generic OSGi API, and is therefore also compatible with Blueprint. There is one minor modification to BrokerBundleWatcher which would be required to be compatible with Spring DM : Blueprint provides a blueprintBundle built-in variable, for which I did not find an equivalent for Spring DM. However, Spring DM provides a bundleContext built-in variable (see 6.6. Accessing the BundleContext), from which the bundle can easily be obtained with the getBundle() method. A new method setBundleContext would need to be added to the class. The BrokerBundleWatcher could then supersede the SpringOsgiContextHook, I think. ActiveMQ OSGi bundle should be stopped when broker stops itself --- Key: AMQ-3692 URL: https://issues.apache.org/jira/browse/AMQ-3692 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.4.2 Environment: ServiceMix 4.3 Reporter: metatech Fix For: 5.8.0 Attachments: activemq-broker.xml, BrokerBundleWatcher.patch, BrokerBundleWatcher_v2.patch, BrokerService.patch In case of error, the ActiveMQ broker can stop itself. In an OSGi/Blueprint environment, the bundle is however still in Active/Created state, which misleads an external monitoring software into thinking that the broker is running fine. This patch stops the bundle when the broker stops itself. This patch can also auto-restart the bundle, which will restart the broker. This is critical in an Master/Slave configuration : when the connection to the database is lost, the broker cannot maintain the DB exclusive lock, and it stops itself. The bundle should be stopped and started again, so that it enters again the Creating state, in which it waits to obtain the DB lock again. The class BrokerBundleWatcher needs to be registered with the shutdownHooks property of the ActiveMQ BrokerService. However, there is a limitation with the XBean syntax in a Blueprint XML, which does not allow to define inner beans. The workaround is to define the activemq-broker.xml in full native Blueprint syntax (no XBean). The patch also provides a modified version of the BrokerService, that injects its own reference into the ShutdownHook's which implement the BrokerServiceAware interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3692) ActiveMQ OSGi bundle should be stopped when broker stops itself
[ https://issues.apache.org/jira/browse/AMQ-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461113#comment-13461113 ] metatech commented on AMQ-3692: --- Claus: it is a normal ShutdownHook : the object is created during broker creation, but the run method is only executed when the shutdown is triggered. The thread started within the run has no loop : it only runs once and then terminates. So I think there should be no additional thread termination mechanism. ActiveMQ OSGi bundle should be stopped when broker stops itself --- Key: AMQ-3692 URL: https://issues.apache.org/jira/browse/AMQ-3692 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.4.2 Environment: ServiceMix 4.3 Reporter: metatech Fix For: 5.8.0 Attachments: activemq-broker.xml, BrokerBundleWatcher.patch, BrokerBundleWatcher_v2.patch, BrokerService.patch In case of error, the ActiveMQ broker can stop itself. In an OSGi/Blueprint environment, the bundle is however still in Active/Created state, which misleads an external monitoring software into thinking that the broker is running fine. This patch stops the bundle when the broker stops itself. This patch can also auto-restart the bundle, which will restart the broker. This is critical in an Master/Slave configuration : when the connection to the database is lost, the broker cannot maintain the DB exclusive lock, and it stops itself. The bundle should be stopped and started again, so that it enters again the Creating state, in which it waits to obtain the DB lock again. The class BrokerBundleWatcher needs to be registered with the shutdownHooks property of the ActiveMQ BrokerService. However, there is a limitation with the XBean syntax in a Blueprint XML, which does not allow to define inner beans. The workaround is to define the activemq-broker.xml in full native Blueprint syntax (no XBean). The patch also provides a modified version of the BrokerService, that injects its own reference into the ShutdownHook's which implement the BrokerServiceAware interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3692) ActiveMQ OSGi bundle should be stopped when broker stops itself
[ https://issues.apache.org/jira/browse/AMQ-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459427#comment-13459427 ] Claus Ibsen commented on AMQ-3692: -- The thread should be daemon, and we should also look into stopping that thread properly when the broker shutdown nicely. ActiveMQ OSGi bundle should be stopped when broker stops itself --- Key: AMQ-3692 URL: https://issues.apache.org/jira/browse/AMQ-3692 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.4.2 Environment: ServiceMix 4.3 Reporter: metatech Fix For: 5.8.0 Attachments: activemq-broker.xml, BrokerBundleWatcher.patch, BrokerBundleWatcher_v2.patch, BrokerService.patch In case of error, the ActiveMQ broker can stop itself. In an OSGi/Blueprint environment, the bundle is however still in Active/Created state, which misleads an external monitoring software into thinking that the broker is running fine. This patch stops the bundle when the broker stops itself. This patch can also auto-restart the bundle, which will restart the broker. This is critical in an Master/Slave configuration : when the connection to the database is lost, the broker cannot maintain the DB exclusive lock, and it stops itself. The bundle should be stopped and started again, so that it enters again the Creating state, in which it waits to obtain the DB lock again. The class BrokerBundleWatcher needs to be registered with the shutdownHooks property of the ActiveMQ BrokerService. However, there is a limitation with the XBean syntax in a Blueprint XML, which does not allow to define inner beans. The workaround is to define the activemq-broker.xml in full native Blueprint syntax (no XBean). The patch also provides a modified version of the BrokerService, that injects its own reference into the ShutdownHook's which implement the BrokerServiceAware interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3692) ActiveMQ OSGi bundle should be stopped when broker stops itself
[ https://issues.apache.org/jira/browse/AMQ-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458658#comment-13458658 ] Claus Ibsen commented on AMQ-3692: -- Can you provide a bit more documentation how you would use this?, eg how you would configure this in the broker XML file. ActiveMQ OSGi bundle should be stopped when broker stops itself --- Key: AMQ-3692 URL: https://issues.apache.org/jira/browse/AMQ-3692 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.4.2 Environment: ServiceMix 4.3 Reporter: metatech Attachments: activemq-broker.xml, BrokerBundleWatcher.patch, BrokerBundleWatcher_v2.patch, BrokerService.patch Original Estimate: 1h Remaining Estimate: 1h In case of error, the ActiveMQ broker can stop itself. In an OSGi/Blueprint environment, the bundle is however still in Active/Created state, which misleads an external monitoring software into thinking that the broker is running fine. This patch stops the bundle when the broker stops itself. This patch can also auto-restart the bundle, which will restart the broker. This is critical in an Master/Slave configuration : when the connection to the database is lost, the broker cannot maintain the DB exclusive lock, and it stops itself. The bundle should be stopped and started again, so that it enters again the Creating state, in which it waits to obtain the DB lock again. The class BrokerBundleWatcher needs to be registered with the shutdownHooks property of the ActiveMQ BrokerService. However, there is a limitation with the XBean syntax in a Blueprint XML, which does not allow to define inner beans. The workaround is to define the activemq-broker.xml in full native Blueprint syntax (no XBean). The patch also provides a modified version of the BrokerService, that injects its own reference into the ShutdownHook's which implement the BrokerServiceAware interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3692) ActiveMQ OSGi bundle should be stopped when broker stops itself
[ https://issues.apache.org/jira/browse/AMQ-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458659#comment-13458659 ] Claus Ibsen commented on AMQ-3692: -- ActiveMQ provides karaf commands to check the status of brokers etc. Can you not use that as well? I would assume these commands can tell you that the broker is not available as well. ActiveMQ OSGi bundle should be stopped when broker stops itself --- Key: AMQ-3692 URL: https://issues.apache.org/jira/browse/AMQ-3692 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.4.2 Environment: ServiceMix 4.3 Reporter: metatech Attachments: activemq-broker.xml, BrokerBundleWatcher.patch, BrokerBundleWatcher_v2.patch, BrokerService.patch Original Estimate: 1h Remaining Estimate: 1h In case of error, the ActiveMQ broker can stop itself. In an OSGi/Blueprint environment, the bundle is however still in Active/Created state, which misleads an external monitoring software into thinking that the broker is running fine. This patch stops the bundle when the broker stops itself. This patch can also auto-restart the bundle, which will restart the broker. This is critical in an Master/Slave configuration : when the connection to the database is lost, the broker cannot maintain the DB exclusive lock, and it stops itself. The bundle should be stopped and started again, so that it enters again the Creating state, in which it waits to obtain the DB lock again. The class BrokerBundleWatcher needs to be registered with the shutdownHooks property of the ActiveMQ BrokerService. However, there is a limitation with the XBean syntax in a Blueprint XML, which does not allow to define inner beans. The workaround is to define the activemq-broker.xml in full native Blueprint syntax (no XBean). The patch also provides a modified version of the BrokerService, that injects its own reference into the ShutdownHook's which implement the BrokerServiceAware interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3692) ActiveMQ OSGi bundle should be stopped when broker stops itself
[ https://issues.apache.org/jira/browse/AMQ-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458946#comment-13458946 ] metatech commented on AMQ-3692: --- Claus, the attached activemq-broker.xml shows how the class is registered as a shutdown hook of the broker. The ActiveMQ Karaf commands must be run manually : the idea of the patch is that the broker is monitored and auto-restarted automatically, without human intervention nor polling script. ActiveMQ OSGi bundle should be stopped when broker stops itself --- Key: AMQ-3692 URL: https://issues.apache.org/jira/browse/AMQ-3692 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 5.4.2 Environment: ServiceMix 4.3 Reporter: metatech Fix For: NEEDS_REVIEWED Attachments: activemq-broker.xml, BrokerBundleWatcher.patch, BrokerBundleWatcher_v2.patch, BrokerService.patch Original Estimate: 1h Remaining Estimate: 1h In case of error, the ActiveMQ broker can stop itself. In an OSGi/Blueprint environment, the bundle is however still in Active/Created state, which misleads an external monitoring software into thinking that the broker is running fine. This patch stops the bundle when the broker stops itself. This patch can also auto-restart the bundle, which will restart the broker. This is critical in an Master/Slave configuration : when the connection to the database is lost, the broker cannot maintain the DB exclusive lock, and it stops itself. The bundle should be stopped and started again, so that it enters again the Creating state, in which it waits to obtain the DB lock again. The class BrokerBundleWatcher needs to be registered with the shutdownHooks property of the ActiveMQ BrokerService. However, there is a limitation with the XBean syntax in a Blueprint XML, which does not allow to define inner beans. The workaround is to define the activemq-broker.xml in full native Blueprint syntax (no XBean). The patch also provides a modified version of the BrokerService, that injects its own reference into the ShutdownHook's which implement the BrokerServiceAware interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3692) ActiveMQ OSGi bundle should be stopped when broker stops itself
[ https://issues.apache.org/jira/browse/AMQ-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199638#comment-13199638 ] metatech commented on AMQ-3692: --- Here is a new version of the patch, that prevents self-deadlock and also adds two properties (minUptime and restartDelay). ActiveMQ OSGi bundle should be stopped when broker stops itself --- Key: AMQ-3692 URL: https://issues.apache.org/jira/browse/AMQ-3692 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.4.2 Environment: ServiceMix 4.3 Reporter: metatech Attachments: BrokerBundleWatcher.patch, BrokerBundleWatcher_v2.patch, BrokerService.patch, activemq-broker.xml Original Estimate: 1h Remaining Estimate: 1h In case of error, the ActiveMQ broker can stop itself. In an OSGi/Blueprint environment, the bundle is however still in Active/Created state, which misleads an external monitoring software into thinking that the broker is running fine. This patch stops the bundle when the broker stops itself. This patch can also auto-restart the bundle, which will restart the broker. This is critical in an Master/Slave configuration : when the connection to the database is lost, the broker cannot maintain the DB exclusive lock, and it stops itself. The bundle should be stopped and started again, so that it enters again the Creating state, in which it waits to obtain the DB lock again. The class BrokerBundleWatcher needs to be registered with the shutdownHooks property of the ActiveMQ BrokerService. However, there is a limitation with the XBean syntax in a Blueprint XML, which does not allow to define inner beans. The workaround is to define the activemq-broker.xml in full native Blueprint syntax (no XBean). The patch also provides a modified version of the BrokerService, that injects its own reference into the ShutdownHook's which implement the BrokerServiceAware interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
