This issue was also fixed in 5.18.5, see
https://issues.apache.org/jira/browse/AMQ-9330
On Mon, Jul 15, 2024 at 5:35 PM Mau, I-Min
wrote:
> And it did work. Thanks all!
>
> From: Mau, I-Min
> Sent: Monday, July 15, 2024 4:11 PM
> To: Matt Pavlovich ; users@activemq.apache.org
> Cc: Bhattacharj
This mailing list is correct, CVEs are sent to the users list and also
should be sent to the dev list.
On Wed, Feb 8, 2023 at 11:12 AM Jonathan Card <
jonathan.c...@intersystems.com> wrote:
> Is there a mailing list to subscribe to potential CVE notices? It looks
> like I can’t/shouldn’t subscrib
I would think the HTML pages for Artemis/5.x are really the only versions
used but I am curious to see if any users here chime in and say otherwise.
HTML is pretty nice as you can just link to the latest docs and is standard
for most projects. I don't know of too many other Open source projects tha
No, JMS 2 is a work in progress and is going to take a while. It will be
done in stages with client side updates first over a couple releases
probably. There won't be any server side support for a while as that is
much more difficult and more work so there won't be shared subscription
support, etc
If you don't want want to use Artemis you can also just look into virtual
topics or composite queues. https://activemq.apache.org/virtual-destinations
On Fri, Jul 2, 2021 at 11:17 AM Justin Bertram wrote:
> The ability to share a JMS subscription like you want was added in JMS 2.0.
> However, Ac
LevelDB has been long deprecated and is being removed from 5.17.0
https://activemq.apache.org/leveldb-store
On Mon, Jun 28, 2021 at 2:40 AM ヤ艾枫o.-- <1169114...@qq.com.invalid> wrote:
> Hi
> activemq.log is
> " Too many cluster members are connected. Expected at most 3 members but
> there arr 4
> > > that other thread.
> > >
> > > On Tue, May 18, 2021 at 12:04 PM Jean-Baptiste Onofre >
> > > wrote:
> > >
> > >> It’s something that we already discussed and I moved forward on the
> PR.
> > >>
> > >> I pr
egards
> JB
>
> > Le 18 mai 2021 à 17:36, Christopher Shannon <
> christopher.l.shan...@gmail.com> a écrit :
> >
> > Since when is JMS 2.0 supposed to be supported by 5.17.0?
> >
> > None of the features are implemented on the server side for the new API
> >
Since when is JMS 2.0 supposed to be supported by 5.17.0?
None of the features are implemented on the server side for the new API
calls. This was brought up in a dev discussion that there won't be JMS 2.0
support on the server side in this release.
On Tue, May 18, 2021 at 11:29 AM Jean-Baptiste O
, and we are trying to get this
> > team
> > > to move to Artemis. However we still need this broker to run while the
> > > migration is going on.
> > >
> > > On Fri, Aug 7, 2020 at 5:48 AM Christopher Shannon <
> > > christopher.l.shan...@gmail
LevelDB support has been deprecated for many years now and is going to be
removed in the next version of ActiveMQ (5.17.0) so I would suggest trying
to migrate over to KahaDB.
On Fri, Aug 7, 2020 at 4:08 AM Ramesh Venkitaswaran
wrote:
> Hello
> We have a 3 node activemq 5.15 cluster with zookeep
I am coming from a 5.x background as well with heavy usage of duplex
network connectors for the same reason as you (such as firewall
configurations) so I definitely understand it being a deal breaker. I'm
not sure when I will get time to work on it more but I'm hoping to soon as
it will make Feder
There is currently no duplex option but it is on the list of things in the
future. Originally there was only upstream connections but I recently added
downstream configuration but it still requires creating a connection in
each direction.
The main issue is there is no current support for duplex co
Take a look at the plugin API for Artemis:
https://activemq.apache.org/components/artemis/documentation/latest/broker-plugins.html
Specifically you can implement your own ActiveMQServerPlugin (which extends
many other plugin interfaces) and has a ton of hooks into the broker to do
what you need.
ActiveMQ 5.x does not support any part of JMS 2.0. There has been talk of
it but it would require a lot of work to get there and isn't close.
For JMS 2.0 support I would recommend looking at Artemis which is the next
generation broker and already supports it.
On Mon, Feb 10, 2020 at 3:11 AM COUR
Have you configured limits on memory usage in the broker settings? You need
to look at a heap dump and see exactly where the memory is being used (if
it's messages on a destination, in prefetch etc).
Some general info about OOM and how to prevent it:
https://activemq.apache.org/javalangoutofmemory
twork/VirtualConsumerDemandTest.java
On Mon, Nov 11, 2019 at 1:17 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> You can force durable subscriptions by setting a flag. Looks like this
> may not have made it into the documentation.
>
>
>
> useVirtualD
You can force durable subscriptions by setting a flag. Looks like this may
not have made it into the documentation.
On Mon, Nov 11, 2019 at 8:33 AM Tim Bain wrote:
> OK, thanks for sharing what you did.
>
> Tim
>
> On
There is no way that MQTT 5 is going to make it into 5.16.0. 5.16.0 is
already way passed due in my opinion and adding support for a new protocol
version is a ton of work. The only reason I haven't started a release for
5.16.0 is because of some issues with JDK 11 (specifically with OSGI/Karaf)
b
These are advisory messages, I suggest you read
https://activemq.apache.org/advisory-message.html which will explain what
they are and how to configure/disable them.
On Tue, Sep 24, 2019 at 4:52 PM Jędrzej Dudkiewicz <
jedrzej.dudkiew...@gmail.com> wrote:
> I wrote yet another certificate-based a
/java/org/eclipse/kapua/broker/core/plugin/KapuaSecurityBrokerFilter.java#L683
> [2]
> https://github.com/eclipse/kapua/blob/develop/broker-core/src/main/java/org/eclipse/kapua/broker/core/plugin/KapuaSecurityBrokerFilter.java#L557
>
>
> Il giorno 26 ago 2019, alle ore 13:43
All of the info you should need to get started should be here:
https://activemq.apache.org/components/artemis/documentation/latest/security.html
On Mon, Aug 26, 2019 at 6:24 AM Modanese, Riccardo
wrote:
> Hello,
> In our ActiveMQ 5.x security plugin code we are enforcing ACL
> programmatical
Dev list got dropped so adding back in (really this probably only belongs
the dev list anyways)
On Thu, Jul 11, 2019 at 12:08 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> Many of those pull requests are years old. Furthermore no one is saying
> there is no i
Many of those pull requests are years old. Furthermore no one is saying
there is no interest in a project. But there is a huge difference from
supporting 5.x in terms of bug fixes and small features than talking about
doing something like adding new protocols or JMS 2.0 support. For example
the
So I will preface this by saying hopefully my comments are not taken the
wrong way and turn into a big fight but instead can lead to a productive
discussion about the next steps.
First, I'm certainly not opposed to anyone who wants to work on modernizing
and adding features to existing software.
There is currently no way to shrink the index file and no plans to add
that. The index file generally grows and stabilizes with your use case
based on the max number of messages the broker will have stored at any
given time. There's not really any reason to need to worry about shrinking
the index
20k messages and 30k topics is quite a bit so I'm not surprised the CPU
usage is very high. The reason the CPU is high after stopping the
publishing is probably because you have a backlog on the broker that the
consumers need to work off. You might also have a lot of messages being
processed for
This page has some info that might help you:
https://activemq.apache.org/why-do-kahadb-log-files-remain-after-cleanup.html
On Wed, Apr 17, 2019 at 7:43 PM TC wrote:
> Hi,
>
> I have broker that runs with increasing journal logs file with mKahadb
> store
> for each destination.
>
> One of the que
I don't think there's any current fallback option for SQL right now.
Contributions are welcome though so if you wanted to take a shot at adding
a property for that you could create a PR.
On Wed, Apr 17, 2019 at 4:28 PM mikmela wrote:
> We seems to experience the same issue upgrading from 5.6.0 t
If you want help you are going to need to upgrade to a supported version.
There have been over 4200 commits since 5.6.0 so no one is going to try and
debug a version that old when the issue may have been fixed years ago.
On Thu, Apr 4, 2019 at 8:11 AM mcrandy wrote:
> I logged the size of the wr
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.9
has been released.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12344450
The Wiki page for the release is here:
http
Thanks Robbie
On Tue, Mar 26, 2019 at 8:26 AM Robbie Gemmell
wrote:
> I brought it to attention of Daniel from the infra team once he was
> around on chat and he fixed thigns up swiftly, the repo is now back in
> action.
>
> Robbie
>
> On Tue, 26 Mar 2019 at 09:46, wrote:
> >
> > Thanks Robbie
The authorization plugin has to do a lot of processing as it is tracking
and checking ACLs for all of your topics (which is a ton) for every message
going through the broker and is going to eat up a lot of CPU. Your best bet
is to try and isolate which part is causing high cpu usage using a profile
First make sure you are using the latest version of the broker.
Second, are you using a mixture of durable subscriptions and non-durable
subscriptions? If you are you might need to add a forceDurable flag to your
set up. Normally the creation of a durable subscription by S on broker B
should crea
When version 2.7.0 is released you will be able to set a default
consumerWindowSize per address so you should be able to accomplish what you
want.
See
https://github.com/apache/activemq-artemis/blob/master/docs/user-manual/en/address-model.md#configuring-addresses-and-queues-via-address-settings
A
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.8
has been released.
A list of issues resolved in this release is available here:
https://jira.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12344359
The Wiki page for the release is here:
http:/
I agree it's probably time for a 2.7.0 soon.
Clebert, any idea what the time frame is for a 2.7.0 release?
On Tue, Nov 13, 2018 at 11:48 AM jlarkin wrote:
> Hi,
>
> Is there any information on when the next Artemis release will be - 2.6.4 /
> 2.7.0?
>
> Looking to pick up some of the fixes that
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.7
has been released.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12344049
The Wiki page for the release is here:
http
Version 5.8.0 is nearly 6 years old and there have been hundreds (maybe
thousands) of commits since then and one of them could have addressed your
issue even if you didn't find an exact match in Jira. However, no one is
going to remember that far back to see if it is a known issue so you will
just
I just realized I had a typo in the announcement, the versions
affected should be:
Apache ActiveMQ 5.0.0 - 5.15.5
The file will be updated shortly.
On Mon, Sep 10, 2018 at 2:40 PM Christopher Shannon
wrote:
>
> The following security vulnerability was reported against Apache
> Active
The following security vulnerability was reported against Apache
ActiveMQ 5.15.5 and older versions.
Please check the following document and see if you’re affected by the issue.
http://activemq.apache.org/security-advisories.data/CVE-2018-11775-announcement.txt
Apache ActiveMQ 5.15.6 has been re
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.6
has been released.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12343805
The Wiki page for the release is here:
http
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.5
has been released.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12343307
The Wiki page for the release is here:
http
I can answer a few of the questions however I suggest reading the migration
guide and the Artemis documentation as I think a lot of your questions will
be answered in there.
https://activemq.apache.org/artemis/migration/
https://activemq.apache.org/artemis/docs/latest/
1) Artemis supports its own
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.4
has been released.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12342685
The Wiki page for the release is here:
http
CVE-2017-15709 - Information Leak
Severity: Low
Vendor:
The Apache Software Foundation
Versions Affected:
Apache ActiveMQ 5.14.0 - 5.15.2
Description:
When using the OpenWire protocol it was found that certain system
details (such as the OS and kernel version) are exposed as plain text.
Mitig
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.3
has been released.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12311210&version=12341947
The Wiki page for the release is here:
htt
The best approach is to use something like Maven or Gradle that supports
dependency management for your application. Using a build tool with
dependency management will allow you to pull in all the transitive
dependencies you need automatically for activemq-client (and other activemq
jars that you
Have you tried searching with bing?
On Fri, Dec 8, 2017 at 10:39 AM, Justin Bertram wrote:
> > You can imagine that such organizations who make tons of investment in
> ActiveMQ are not impressed by claims of 'better architecture' or my
> 'journaling system is faster'.
>
> Do you have a list of w
After reading the discussion and thinking about it I think I am on board
with going with ActiveMQ 6.
What's the next step with this? Do we want to propose a vote or keep the
discussion open longer?
On Thu, Nov 23, 2017 at 3:09 PM, Gary Tully wrote:
> I think ActiveMQ needs a roadmap for sure a
In 5.x it isn't quite as simple.
To trust all you'll need to extend ActiveMQSslConnectionFactory and
override the createTrustManager() method. This should work:
@Override
protected TrustManager[] createTrustManager() throws Exception {
return new TrustManager[] { new X509TrustManager() {
public X
Jeff,
I don't think anyone is proposing killing off 5.x at this point, but just
clarifying what the future is in terms of Artemis and ActiveMQ 6. I do
think we need to retire Apollo though.
Chris
On Mon, Nov 20, 2017 at 12:41 PM, jgenender wrote:
> I'll throw in my .02 on this...
>
> I think
with me as well.
On Wed, Nov 15, 2017 at 10:41 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> I think it's pretty clear at this point that Artemis is the future.
> However, I don't know that renaming it to ActiveMQ 6 makes any sense as it
> would be a
I think it's pretty clear at this point that Artemis is the future.
However, I don't know that renaming it to ActiveMQ 6 makes any sense as it
would be a lot of work and more confusion.
My opinion would be to just have the roadmap say Artemis is the future and
recommended broker and drop plans to
There is not currently any plans for more releases but if there's enough
demand for it (or critical fixes) then one could always be done. The
releases have always been community driven so if someone speaks up and has
specific fixes they wanted to be merged back then it's possible to do
another rel
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.2
has been released.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12341669
The Wiki page for the release is here:
http
Yes Artemis is being actively developed and is the primary focus while the
old ActiveMQ 5.x line is mostly just maintenance mode at this point. The
intention is that Artemis is the successor regardless of whether it keeps
the name Artemis or is renamed at some point. In my opinion if you are
sta
The KahaDB index does not drop in size after increasing. It just keeps
track of free pages and will re-use them. So the index tends to grow as
large as it needs and hits a consistent point. A large backlog of messages
will cause the index to increase to track all of the messages. There was at
on
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.15.0
has been released and includes many fixes and improvements.
Also note that this release bumps the minimum required Java version to Java
8.
A list of issues resolved in this release is available here:
https://issues
How much memory have you allocated for the broker? You might need to
simply allocate more memory or tune your memory limits. See
http://activemq.apache.org/javalangoutofmemory.html
On Fri, Jun 30, 2017 at 7:10 AM, Hidekazu wrote:
> Hi,
>
> We did a performance test for ActiveMQ and came across
As a follow up, there has been some discussion on building a web console
but no work has been done yet on it.
On Wed, Jun 7, 2017 at 5:32 PM, Brett Delle Grazie <
brett.dellegra...@gmail.com> wrote:
> You can also use HawtIO and this plugin:
> https://github.com/rh-messaging/artemis-hawtio
>
> It
Artemis supports all the same clients plus an extra one. It supports the
Core protocol (The Artemis native protocol), OpenWire(which is the ActiveMQ
5.x native protocol), AMQP, MQTT, and STOMP. So any of your existing
clients will work with the broker as long as you have enabled the protocol
supp
y synchronous and persistent use-cases will reduce
> performance, but many use-cases don't require that.
> 6) Clebert's "benchmark" (both code and operating environment) is quite
> different from the SpecJMS results I linked.
>
>
> Justin
>
> [1] https
logspot.com/2011/07/82-million-messages-
> second-with-specjms.html
>
> - Original Message -
> From: "Christopher Shannon"
> To: users@activemq.apache.org
> Sent: Monday, June 5, 2017 6:45:26 AM
> Subject: Re: why AvtiveMq is slowly than Kafka?
>
> You ca
Artemis is intended to be the follow on to ActiveMQ 5.x. It is currently
being actively developed to add new features to it with the goal that the
useful features from ActiveMQ will also be added to Artemis. Most of the
development effort is being done there and ActiveMQ 5.x is basically in
maint
You can't compare Kafka to a JMS type message broker. Kafka is completely
different.
Kafka is a system that scales horizontally and is essentially a big
write-ahead log and breaks up the topics into partitions across many
servers so they can be scanned concurrently. This allows insane message
r
You should be able to do in Java code if you have an embedded broker. You
can get access to the Broker chain from the BrokerService object, get the
RedeliveryPlugin and then update the redeliveryPolicyMap.
BrokerService brokerService = new BrokerService();
//do configuration here
RedeliveryPlugin
What kind of errors are you getting? If it's related to data marshalling
then it could be because there was an Openwire upgrade (Openwire is the
format the messages are stored in) done in the KahaDB store between those
versions which could be causing your issue. I think there was also some
schedul
This has been fixed as part of AMQ-6656 which AMQ-6685 duplicated. The fix
will be part of 5.15.0 (and 5.14.6 if a release is done)
On Wed, May 24, 2017 at 10:22 AM, Adam Whitney
wrote:
> one thing to note ... we were using the /admin/xml/queues.jsp page to get
> stats from ActiveMQ into splunk
How fast the messages get purged depend on many things such as how large
the messages are, if they are non-persistent, and if there is contention on
the Queue, and of course how fast your hardware is. The purge operation
works by paging in batches of messages at a time so if it has to go to disk
ve
Yes, memory usage should be 0 for a destination if there are no messages so
this seems like a bug. There was another memory bug fixed more recently
but that only had to do with persistent messages when using concurrent
store and dispatch. As you pointed out the best thing to do to help would
be t
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.14.4
has been released and includes over 20 fixes and improvements.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12338909
I'm not sure what caused the exception when reading the index but the
behavior of the broker on IOException is defined by the IOExceptionHandler
that is configured on the broker. Take a look at DefaultIOExceptionHandler
and all of the available options. By default on IOException it will shut
down
Can you try creating each broker in a different thread in your tests? The
issue I think is that in the SslContext class the ThreadLocal variable is
static so it is going to be shared and interfere when you try to configure
2 brokers in the same JVM and the same thread is creating transports. This
ris,
>
> What will be the behavior for anyone who doesn't delete their index after
> upgrading? Will the broker continue to function as-is in that scenario, or
> is this a required procedure during an upgrade beyond 5.14.3?
>
> Tim
>
> On Feb 2, 2017 5:02 AM, "Christ
Sorry for taking a while to get back to you.
Based on your originally message and after analyzing some index files I
have actually discovered a bug with KahaDB that causes the index file to
grow too large when things like out of memory errors occur or any unclean
shutdown. On recovery the free pa
The index grows based off the amount of data it tracks in the journal,
but doesn't shrink. This means if you had a lot of data in your
journal at some point (several gigabytes, etc) then the index would
have grown in size with enough page files to keep track of all of the
data. This is usually no
Yes, I would expect maxFileLength should only be used on file
allocation. My expectation is that the journal file length should be
able to be changed in between restarts and have everything work. In
the past I have increased the size many times before without issues so
I'm not sure if the second
Yes, that is safe to do. The journalMaxFileLength value is only used
for allocating new journal files and doesn't have any effect on
previous files. If you change the value the broker will continue to
work fine and be able to read the old files but all new allocated
files will be the new size.
O
Which version are you using? Normally on start up the broker should
not need to replay the entire journal if the index already exists. On
startup the broker tries to determine the last in doubt position from
the index and only replay from that point. With HA I would expect
this to work the same w
It's hard to say an exact time frame. Finished new features would be
the driving force behind a 5.15.0 release as bug fixes are already
backported but right now there hasn't been much done to justify a
5.15.0 release. Most work has been focused on Artemis but I would say
that mid year sounds abou
Yes if you have a ton of data on a durable subscription and delete the
durable it tends to write a large temp file because of the kahadb
index. Even though the temp file should be deleted automatically
after deletion this is certainly not ideal.
Right now there isn't really a good way to discard
Did this happen while replaying the journal? This message means that
an acknowledgement was processed in the journal that doesn't have a
matching message. This log message would typically print out if you
were replaying the journal from the beginning to rebuild the index
because it's possible tha
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.14.3
has been released and includes several fixes and improvements.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12338822
There are currently no plans to revisit KahaDB replication that I know of.
But contributions are welcome so it's always possible someone could pick it
up. At this point the main focus has become Artemis since that already
supports replication.
On Wed, Dec 21, 2016 at 12:22 PM, mlange wrote:
> A
Unfortunately it is a bit convoluted to do this right now as you need
to get access to the SSLSocket that is part of the connection which
isn't exposed through the API so you need to use reflection to get
access to the Socket. But the following is an example that should
work:
ActiveMQConn
The transaction you are referring to is a transaction on the KahaDB
index and a new one will be created by KahaDB when calling that method
so you don't need to worry about it. In terms of statefulness, you
are correct that the order index tracks state of where it left off.
But I believe it is safe
You should be able to implement your own MessageRecoveryListener and
use the recover() or recoverNextMessages() methods on the MessageStore
interface. The MessageStore object is part of the region Queue (it is
inherited from the parent BaseDestination class)
http://activemq.apache.org/maven/apidoc
Everything should resume and continue to process messages already in
KahaDB. It won't overwrite them. Essentially you should not notice
any difference switching between the two modes because there's nothing
different between a standalone version and embedded version except
that the standalone ver
You should be able to switch without an issue as long as your
configuration is the same between your XML config for standalone and
and your embedded config.
On Mon, Dec 12, 2016 at 3:42 AM, appy wrote:
> Hello,
>
> I am using activeMQ embedded currently and would like to switch to the
> standalon
Yes, it is blocking. The BrokerFilter class implements Broker and
simply delegates to the parent Broker so if whatever you are doing is
stuck then processing won't continue. If you were to print out a
stacktrace from inside one of those methods you will see that there
are many BrokerFilter implem
The following security vulnerability was reported against Apache
ActiveMQ 5.14.1 and older versions.
Please check the following document and see if you’re affected by the issue.
http://activemq.apache.org/security-advisories.data/CVE-2016-6810-announcement.txt
Apache ActiveMQ 5.14.2 has been rel
Hi everyone,
The ActiveMQ team is pleased to announce that Apache ActiveMQ 5.14.2 has
now been released and includes over 30 bug fixes and improvements.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=1
You probably figured this out but to be clear in my previous message in the
first paragraph I meant to say that LevelDB was "intended to be the follow
on to KahaDB", and not "was intended to be the follow on to ActiveMQ" as it
currently states.
On Wed, Dec 7, 2016 at 3:26 PM,
The issue with the current LevelDB implementation is that it is not
stable. There have been numerous bugs reported against it that have not
been fixed including corruption problems so it is not really usable in a
production environment. Originally it was intended to be the follow on to
ActiveMQ bu
I can update the documentation for this feature.
There is a new property on KahaDB called "journalDiskSyncStrategy" that can
be set either in XML config or with Java on the persistence adapter.
For example, if using XML:
Setting to periodic will trigger disk flushes at set intervals in
Can you post your broker configuration? This seems odd that would happen
if you removed the db.
On Wed, Nov 30, 2016 at 5:04 AM, jack patwork wrote:
> Hi,
>
>
> After upgrading a 4 node cluster from 5.9.1 to 5.14.1 I'm seeing my amq
> logs spammed with 1000's of the following warnings. This was
If you look at at destination when using JMX, there is
getStoreMessageSize() which will give you the usage of the message store
for the destination. It's part of the DestinationView interface.
On Fri, Nov 18, 2016 at 6:25 PM, Brian Cole wrote:
> I am using the statistcsBrokerPlugin to query bro
That's odd because the page file should be loaded right before the journal
is loaded in that open() method. Did you see a log message about the index
being corrupted?
On Mon, Oct 24, 2016 at 3:11 AM, RuralHunter wrote:
> I'm using 5.13.4 with mkahadb. Sometimes I saw this error:
> java.lang.Ill
As far as I know there haven't been any reports or issues having to do with
a memory leak in recent versions.
How much memory is being used is really up to the JVM in terms of how it
handles allocation and GC. The only way to really know if there is a
memory leak is to analyze the results of a he
1 - 100 of 271 matches
Mail list logo
