[CONF] Apache ActiveMQ > KahaDB

[Paul Gale (Confluence)]

Title: Message Title

Paul Gale edited a page

KahaDB ... You can configure ActiveMQ to use KahaDB for its persistence adapter - like below: Code Block language xml <broker brokerName="broker" ... > <persistenceAdapter> <kahaDB directory="activemq-data" journalMaxFileLength="32mb"/> </persistenceAdapter> ... </broker> ... (as of 5 12.0) This setting configures how the broker will try to preallocate the journal files when a new journal file is needed. The default allocation strategy sets the file length, but does not populate it with any data. The 'os_kernel_copy' strategy delegates the preallocation to the Operating System. The 'zeros' strategy configures ActiveMQ to do the preallocation by writing 0x00 to all of the positions in the journal file. (as of ) This the broker will preallocate the in ' ' ' ' using ' ' note , stick with property name default value Comments directory activemq-data the path to the directory to use to store the message store data and log files indexDirectory   If set, configures where the KahaDB index files (db.data and db.redo) will be stored. If not set, the index files are stored in the directory specified by the 'directory' attribute. Note Available as of ActiveMQ 5.10 storeOpenWireVersion 11 Determines the version of OpenWire commands that are marshalled to the KahaDB journal.  In versions prior to 5.12.0 this value defaulted to v6.  Some features of the broker depend on information stored in the OpenWire commands from newer protocol revisions and these may not work correctly if the store version is set to a lower value.  KahaDB stores from broker versions greater than 5.9.0 will in many cases still be readable by the broker but will cause the broker to continue using the older store version meaning newer features may not work as intended.  For KahaDB stores that were created in versions prior to v5.9.0 it will be necessary to manually set the store version to v6 in order to start a broker without error. indexWriteBatchSize 1000 number of indexes written in a batch indexCacheSize 10000 number of index pages cached in memory enableIndexWriteAsync false if set, will asynchronously write indexes journalMaxFileLength 32mb a hint to set the maximum size of the message data logs enableJournalDiskSyncs true ensure archiveCorruptedIndex false If enabled, corrupted indexes found at startup will be archived (not deleted). archiveDataLogs false If enabled, will move a message data log to the archive directory instead of deleting it. checkForCorruptJournalFiles false If enabled, will check for corrupted Journal files on startup and try and recover them. checkpointInterval 5000 Time (ms) before check-pointing the journal. checksumJournalFiles true Create a checksum for a journal file - to enable checking for corrupted journals. Before ActiveMQ 5.9.0: the default is false. cleanupInterval 30000 Time (ms) before checking for a discarding/moving message data logs that are no longer used. compactAcksAfterNoGC 10 From ActiveMQ 5.14.0: when the acknowledgement compaction feature is enabled this value controls how many store GC cycles must be completed with no other files being cleaned up before the compaction logic is triggered to possibly compact older acknowledgements spread across journal files into a new log file.  The lower the value set the faster the compaction may occur which can impact performance if it runs to often. compactAcksIgnoresStoreGrowth false From ActiveMQ 5.14.0: when the acknowledgement compaction feature is enabled this value controls whether compaction is run when the store is still growing or if it should only occur when the store has stopped growing (either due to idle or store limits reached).  If enabled the compaction runs regardless of the store still having room or being active which can decrease overall performance but reclaim space faster.  concurrentStoreAndDispatchQueues true Enable the dispatching of Queue messages to interested clients to happen concurrently with message storage. concurrentStoreAndDispatchTopics false Enable the dispatching of Topic messages to interested clients to happen concurrently with message storage Warning Enabling this property is not recommended. directory activemq-data The path to the directory to use to store the message store data and log files. directoryArchive null Define the directory to move data logs to when they all the messages they contain have been consumed. enableAckCompaction true From ActiveMQ 5.14.0: this setting controls whether the store will perform periodic compaction of older journal log files that contain only Message acknowledgements.  By compacting these older acknowledgements into new journal log files the older files can be removed freeing space and allowing the message store to continue to operate without hitting store size limits. enableIndexWriteAsync false If set, will asynchronously write indexes. enableJournalDiskSyncs true Ensure every journal write is followed by a disk sync (JMS durability requirement) cleanupInterval 30000 time (ms) before checking for a discarding/moving message data logs that are no longer used checkpointInterval 5000 time (ms) before checkpointing the journal . ignoreMissingJournalfiles false If enabled, will ignore a missing message log file. checkForCorruptJournalFilesindexCacheSize false If enabled, will check for corrupted Journal files on startup and try and recover them checksumJournalFiles false true v5.9 create a checksum for a journal file - to enable checking for corrupted journals archiveDataLogs false If enabled, will move a message data log to the archive directory instead of deleting it. directoryArchive null Define the directory to move data logs to when they all the messages they contain have been consumed10000 Number of index pages cached in memory. indexDirectory   From ActiveMQ 5.10.0: If set, configures where the KahaDB index files (db.data and db.redo) will be stored. If not set, the index files are stored in the directory specified by the directory attribute. indexWriteBatchSize 1000 Number of indexes written in a batch. journalMaxFileLength 32mb A hint to set the maximum size of the message data logs. maxAsyncJobs 10000 the The maximum number of asynchronous messages that will be queued awaiting storage (should be the same as the number of concurrent MessageProducers) concurrentStoreAndDispatchTopics false enable the dispatching of Topic messages to interested clients to happen concurrently with message storage (Warning: Enabling this property is not recommended) concurrentStoreAndDispatchQueues true enable the dispatching of Queue messages to interested clients to happen concurrently with message storage archiveCorruptedIndex false If enabled, corrupted indexes found at startup will be archived (not deleted) preallocationStrategy sparse_file . preallocationScope entire_journal From ActiveMQ 5.14.0 : this setting configures how journal data files are preallocated. The default strategy preallocates the journal file on first use using the appender thread.   entire_journal_async will use preallocate ahead of time in a separate thread. none disables preallocation. On SSD, using entire_journal_async avoids delaying writes pending preallocation on first use. Note: on HDD the additional thread contention for disk has a negative impact . Therefore use the default. enableAckCompactionpreallocationStrategy true (as of sparse_file From ActiveMQ 5.1412.0) This setting controls whether the store will perform periodic compaction of older journal log files that contain only Message acknowledgements.  By compacting these older acknowledgements into new journal log files the older files can be removed freeing space and allowing the message store to continue to operate without hitting store size limits. compactAcksAfterNoGC 10 (as of 5.14.0) when the acknowledgement compaction feature is enabled this value controls how many store GC cycles must be completed with no other files being cleaned up before the compaction logic is triggered to possibly compact older acknowledgements spread across journal files into a new log file.  The lower the value set the faster the compaction may occur which can impact performance if it runs to often. compactAcksIgnoresStoreGrowth false (as of 5.14.0) when the acknowledgement compaction feature is enabled this value controls whether compaction is run when the store is still growing or if it should only occur when the store has stopped growing (either due to idle or store limits reached).  If enabled the compaction runs regardless of the store still having room or being active which can decrease overall performance but reclaim space faster.  ... : This setting configures how the broker will try to preallocate the journal files when a new journal file is needed. sparse_file - sets the file length, but does not populate it with any data. os_kernel_copy - delegates the preallocation to the Operating System. zeros  - configures ActiveMQ to do the preallocation by writing 0x00 to all of the positions in the journal file. storeOpenWireVersion 11 Determines the version of OpenWire commands that are marshaled to the KahaDB journal.  Before ActiveMQ 5.12.0: the default value is 6. Some features of the broker depend on information stored in the OpenWire commands from newer protocol revisions and these may not work correctly if the store version is set to a lower value.  KahaDB stores from broker versions greater than 5.9.0 will in many cases still be readable by the broker but will cause the broker to continue using the older store version meaning newer features may not work as intended.  For KahaDB stores that were created in versions prior to ActiveMQ 5.9.0 it will be necessary to manually set storeOpenWireVersion="6" in order to start a broker without error. For tuning locking properties please take a look at Pluggable storage lockers ... You can configure a non zero threshold in mili seconds milliseconds for database updates. If database operation is slower than that threshold (for example if you set it to 500), you may see messages like ... From 5.6, it is possible to distribute destinations stores across multiple kahdb persistence adapters. When would you do this? If you have one fast producer/consumer destination and another periodic producer destination that has irregular batch consumption, you disk usage can grow out of hand because unconsumed messages get dotted across journal files. Having a separate journal for each ensures minimal journal usage. Also, some destination may be critical and require disk synchronisation synchronization while others may not. In these cases you can use the mKahaDB persistence adapter and filter destinations using wildcards, just like with destination policy entries. ... Each instance of kahaDB can be configured independently. If no destination is supplied to a filteredKahaDB, the implicit default value will match any destination, queue or topic. This is a handy catch all. If no matching persistence adapter can be found, destination creation will fail with an exception. The filteredKahaDB shares its wildcard matching rules with Per Destination Policies. ... View page • Like

Stop watching space • Manage notifications This message was sent by Atlassian Confluence 5.8.4