I think you'll get the behavior you want with Option 2, but only if there
aren't enough pending messages to fill the dispatch queues of each
connected consumer within the data center, with additional messages left
over. If the consumers' dispatch queues are full (or if there are no
connected
KahaDB's data files are not compacted, so a tiny message can keep alive a
32-MB (or whatever size you're using) log file. It's not that the messages
are larger, it's just that lots of clutter gets kept along with the actual
content you're keeping. And if you're not using 5.14.0, then chains of
Sorry, please don't respond to that message on-list; please provide any
response to secur...@activemq.apache.org.
On Sep 27, 2016 9:31 PM, "Tim Bain" wrote:
> Benjamin, did your comment indicate that you have reproduced the
> vulnerability in 5.14.0, even though it
Benjamin, did your comment indicate that you have reproduced the
vulnerability in 5.14.0, even though it includes a version of Jetty that
Chris indicates should be unaffected?
Tim
On Sep 27, 2016 9:52 AM, "Christopher Shannon" <
christopher.l.shan...@gmail.com> wrote:
> First, for security
Tim , Thank you for your suggestion. But i have tried different way now to
see the result. It worked out. I have created a new maven project with only
producer and consumer and the old project contains unnecessary dependencies
which might have caused the issue. As soon as i have tried with the new
First, for security vulnerabilities please follow this guide in the future
http://www.apache.org/security/committers.html
Second, the version that is bundled with ActiveMQ 5.14.0 is version
9.2.13.v20150730 and the vulnerability was fixed in version 9.2.9 so there
should not be an issue.
On Tue,
Hi everybody,
it seems the Jetty server bundled with the latest activemq release (5.14.0)
is prone to the jetleak vulnerability mentioned in CVE-2015-2080 and here:
https://blog.gdssecurity.com/labs/2015/2/25/jetleak-vulnerability-remote-leakage-of-shared-buffers-in-je.html
When exploiting the
Thanks for your reply.
> On 27 Sep 2016, at 14:59, Tim Bain wrote:
>
> Do the stats you see in JConsole line up with KahaDBJournalReader (what's
> that?), or with the web console? And do you see an open XA transaction in
> JConsole, like Steve did?
No traces of XA
Thanks. Good info.
> On Sep 27, 2016, at 7:49 AM, Christopher Shannon
> wrote:
>
> Running different versions should be ok because OpenWire (the protocol
> used) goes through a negotiation process. The client/sever will negotiate
> the highest common protocol
Running different versions should be ok because OpenWire (the protocol
used) goes through a negotiation process. The client/sever will negotiate
the highest common protocol version it can so you can use an old client to
talk to a newer server. That being said there might be some bug fixes in
the
How important is it to have the exact same client and server jar versions.
We are running 5.14.0 server but our clients have 5.13.2 jars.
Everything seems ok - but we have had a few weird issues in our network of
brokers.
Thanks for any insight.
The issue has been reopened and will be fixed when someone gets time. This
would be a relatively easy fix to implement if anyone wants to attempt a
pull request to get it fixed faster. Version 5.14.1 is being voted on now
but this fix could go into 5.14.2 and 5.15.0.
On Tue, Sep 27, 2016 at
We have 2 data centres with 2 brokers on each side.
Producers and consumers are initiated by different applications as well,
application also are deployed in the same 2 data centres but in different
servers, given this we also have added the priorityURI and priorityBackup
since order is
Do the stats you see in JConsole line up with KahaDBJournalReader (what's
that?), or with the web console? And do you see an open XA transaction in
JConsole, like Steve did?
I'd guess that the negative values indicate that whatever code you
hacked'n'slashed has a bug, either in the code you
This issue got closed by Chris Shannon, but I think it would be easy enough
to add a flag that tells the broker to bypass the total space check that's
causing problems, so I think we should reopen it.
Tim
On Fri, Sep 23, 2016 at 11:42 AM, wcrowell
wrote:
> Please
15 matches
Mail list logo