[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-tabpanel&focusedCommentId=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] [Updated] (AMQ-4068) Job Scheduler Store Growth is Unrestricted
[ https://issues.apache.org/jira/browse/AMQ-4068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated AMQ-4068: - Fix Version/s: NEEDS_REVIEWED Issue Type: Improvement (was: Bug) > Job Scheduler Store Growth is Unrestricted > -- > > Key: AMQ-4068 > URL: https://issues.apache.org/jira/browse/AMQ-4068 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.6.0 >Reporter: David Valeri > Fix For: NEEDS_REVIEWED > > Attachments: > 0001-AMQ-4068-Added-configuration-option-enforcement-and-.patch > > > When using scheduled delivery, it is possible to grow the job scheduler store > indefinitely. As no quota can be set on the size of this store, a > malfunctioning, malicious, or prodigious producer can easily consume all > available storage with scheduled messages without any alerts being raised by > the broker. If the operators do not have disk space monitoring in place > outside of the broker, the broker can become innoperable without warning. > Provide a mechanism to set a usage quota for the job scheduler store. The > mechanism should conform to the current resource quota model provided by > SystemUsage as well as provide monitoring through JMX. > I have attached a basic patch to add management, enforcement, and > configurability to the size of the job scheduler data store. Any guidance on > things I missed or did not account for would be greatly appreciated. > While testing the size reporting in JMX, I noticed that the he Kaha > persistence adapter seems to calculate its size differently than the job > scheduler store. It appears that the job scheduler store is reporting the > size of the data files and index while the Kaha persistence adapter is only > reporting the size of the data files. What is the reason for this > difference? I noticed the difference because the broker was reporting a 33% > usage of the job scheduler store (100MB limit) immediately on a clean broker > startup. -- 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] [Updated] (AMQ-3024) Scheduler should support non-Kaha persistence
[ https://issues.apache.org/jira/browse/AMQ-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated AMQ-3024: - Issue Type: New Feature (was: Improvement) > Scheduler should support non-Kaha persistence > - > > Key: AMQ-3024 > URL: https://issues.apache.org/jira/browse/AMQ-3024 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.4.1 >Reporter: I D > > Currently, the persistence adapter attached to the broker service is simply > ignored by the scheduler. The scheduler always uses KahaDB, instead. > I see two ways to go about this: > # Creating a SchedulerPersistenceAdapter akin to (and possibly extending > from) PersistenceAdapter, as well as a corresponding factory class and > BrokerService property. This seems clumsy, but is in line with the approach > currently taken, separating scheduler-related data from non-scheduler-related > data - see BrokerService.setDataDirectoryFile() vs. > BrokerService.setSchedulerDirectoryFile(). This approach is probably > unnecessary, since the scheduler can clearly use existing PersistenceAdapters > (or at least the KahaDB adapeter). > # Depracating or removing the BrokerService.schedulerDirectoryFile property > and having the scheduler use the one and only persistence adapter attached to > the BrokerService (if it's a journaling adapter - > BrokerService.dataDirectoryFile will be used, rather than > BrokerService.schedulerDirectoryFile). This seems like the reasonable > approach. -- 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
