[jira] [Commented] (AMQ-5172) Race conditions in ActiveMQ broker
[ https://issues.apache.org/jira/browse/AMQ-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990353#comment-13990353 ] Anuj Khandelwal commented on AMQ-5172: -- Tim, I don't have a particular test case for this but in my broker setup, I usually saw this behavior: When I run broker for long time (~20 days) and then restart it without clearing kahaDB. If I clear the kahaDB, I see every mbean is getting registered and working properly. Thanks, Anuj Race conditions in ActiveMQ broker -- Key: AMQ-5172 URL: https://issues.apache.org/jira/browse/AMQ-5172 Project: ActiveMQ Issue Type: Bug Components: Broker, JMX Affects Versions: 5.8.0 Reporter: Anuj Khandelwal Hi, It is coming from http://activemq.2283324.n4.nabble.com/PageFile-is-not-loaded-when-recreating-queue-td4679066.html#a4680470 Problem: Race conditions between creation and removal of queues and consumers. queue/topic mbeans are not able to register properly. For complete details and snapshots please visit http://activemq.2283324.n4.nabble.com/PageFile-is-not-loaded-when-recreating-queue-td4679066.html#a4680470 Thanks, Anuj -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-5172) Race conditions in ActiveMQ broker
[ https://issues.apache.org/jira/browse/AMQ-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuj Khandelwal updated AMQ-5172: - Priority: Minor (was: Major) Race conditions in ActiveMQ broker -- Key: AMQ-5172 URL: https://issues.apache.org/jira/browse/AMQ-5172 Project: ActiveMQ Issue Type: Bug Components: Broker, JMX Affects Versions: 5.8.0 Reporter: Anuj Khandelwal Priority: Minor Hi, It is coming from http://activemq.2283324.n4.nabble.com/PageFile-is-not-loaded-when-recreating-queue-td4679066.html#a4680470 Problem: Race conditions between creation and removal of queues and consumers. queue/topic mbeans are not able to register properly. For complete details and snapshots please visit http://activemq.2283324.n4.nabble.com/PageFile-is-not-loaded-when-recreating-queue-td4679066.html#a4680470 Thanks, Anuj -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5160) Wildcard subscriptions bypass Authentication / Authorization
[ https://issues.apache.org/jira/browse/AMQ-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990487#comment-13990487 ] Dejan Bosanac commented on AMQ-5160: Added a test for the remaining retained messages issue https://fisheye6.atlassian.com/changelog/activemq-git?cs=64baf092f073f8c2256a2f2ed704f708562d65a5 Wildcard subscriptions bypass Authentication / Authorization Key: AMQ-5160 URL: https://issues.apache.org/jira/browse/AMQ-5160 Project: ActiveMQ Issue Type: Bug Components: MQTT Affects Versions: 5.9.1 Reporter: Surf Priority: Critical Labels: authentication, authorization, mqtt, security Fix For: 5.10.0 Attachments: activemq.xml, groups.properties, login.config, users.properties I am using MQTT on AMQ 5.9.1 After latest MQTT hardening from [~dhirajsb] , there is an issue of MQTT retained messages. Simple case: Set Authentication / Authorization for two different TOPICS. Send retained message to one topic. Try to subscribe # with other second user. It will show retained messages published by TOPIC 1. here i have attached test configurations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (AMQ-5160) Wildcard subscriptions bypass Authentication / Authorization
[ https://issues.apache.org/jira/browse/AMQ-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990531#comment-13990531 ] Dejan Bosanac edited comment on AMQ-5160 at 5/6/14 10:54 AM: - I was looking a bit more into this. The problem is that we're managing these retained messages in the mqtt filter and sending it directly to the subscription. So it buy-passes all broker interceptors (including security ones). I think the better option would be to reuse subscription recovery policy mechanism http://activemq.apache.org/subscription-recovery-policy.html and adapt it for mqtt use-cases. I'll take a stub at refactoring this. was (Author: dejanb): I was looking a bit more in this. The problem is that we're managing these retained messages in the mqtt filter and sending it directly to the subscription. So it buy-passes all broker interceptors (including security ones). I think the better option would be to reuse subscription recovery policy mechanism http://activemq.apache.org/subscription-recovery-policy.html and adapt it for mqtt use-cases. I'll take a stub at refactoring this. Wildcard subscriptions bypass Authentication / Authorization Key: AMQ-5160 URL: https://issues.apache.org/jira/browse/AMQ-5160 Project: ActiveMQ Issue Type: Bug Components: MQTT Affects Versions: 5.9.1 Reporter: Surf Priority: Critical Labels: authentication, authorization, mqtt, security Fix For: 5.10.0 Attachments: activemq.xml, groups.properties, login.config, users.properties I am using MQTT on AMQ 5.9.1 After latest MQTT hardening from [~dhirajsb] , there is an issue of MQTT retained messages. Simple case: Set Authentication / Authorization for two different TOPICS. Send retained message to one topic. Try to subscribe # with other second user. It will show retained messages published by TOPIC 1. here i have attached test configurations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5160) Wildcard subscriptions bypass Authentication / Authorization
[ https://issues.apache.org/jira/browse/AMQ-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990531#comment-13990531 ] Dejan Bosanac commented on AMQ-5160: I was looking a bit more in this. The problem is that we're managing these retained messages in the mqtt filter and sending it directly to the subscription. So it buy-passes all broker interceptors (including security ones). I think the better option would be to reuse subscription recovery policy mechanism http://activemq.apache.org/subscription-recovery-policy.html and adapt it for mqtt use-cases. I'll take a stub at refactoring this. Wildcard subscriptions bypass Authentication / Authorization Key: AMQ-5160 URL: https://issues.apache.org/jira/browse/AMQ-5160 Project: ActiveMQ Issue Type: Bug Components: MQTT Affects Versions: 5.9.1 Reporter: Surf Priority: Critical Labels: authentication, authorization, mqtt, security Fix For: 5.10.0 Attachments: activemq.xml, groups.properties, login.config, users.properties I am using MQTT on AMQ 5.9.1 After latest MQTT hardening from [~dhirajsb] , there is an issue of MQTT retained messages. Simple case: Set Authentication / Authorization for two different TOPICS. Send retained message to one topic. Try to subscribe # with other second user. It will show retained messages published by TOPIC 1. here i have attached test configurations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQ-5173) Kaha DB cleanup fails to reclaim disk space after some time
Imran created AMQ-5173:
--
Summary: Kaha DB cleanup fails to reclaim disk space after some
time
Key: AMQ-5173
URL: https://issues.apache.org/jira/browse/AMQ-5173
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.6.0
Reporter: Imran
We are seeing an issue where a broker using Kaha DB will gradually increase its
footprint on disk over time and never shrink back down again even when all
queues are empty.
The default cleanup settings will reclaim space at first but over time it seems
the size of the data directory will grow and never shrink back down to its
original size.
I can reproduce this with a test that sends and consumes a large number of
messages to a single queue (.net client, broker hosted on windows). The data
file grows and will never shrink back down again.
{code}
[Test]
public void ButLoadOfMessagesOnASingleQueue()
{
const int messagesPerProducerThread = 100;
const int numberProducers = 1;
const int numberConsumers = 3;
var producersConsumers = new ListTask();
var factory = new ConnectionFactory
{
AcknowledgementMode = AcknowledgementMode.Transactional,
AsyncSend = true
};
for (var i = 0; i numberProducers; i++)
{
var producer = Task.Factory.StartNew(() = Send(factory,
messagesPerProducerThread));
producersConsumers.Add(producer);
}
for (var i = 0; i numberConsumers; i++)
{
var consumer = Task.Factory.StartNew(() = Consume(factory));
producersConsumers.Add(consumer);
}
Task.WaitAll(producersConsumers.ToArray());
}
private void Send(IConnectionFactory connectionFactory, int noMessages)
{
var connection = connectionFactory.CreateConnection();
connection.Start();
var session = connection.CreateSession();
var destination = SessionUtil.GetDestination(session,
GetQueueName(1));
var producer = session.CreateProducer(destination);
for (var i = 0; i noMessages; i++)
{
producer.Send(new ActiveMQTextMessage(i.ToString()));
if (i%100 == 0)
session.Commit();
}
session.Commit();
connection.Close();
}
private void Consume(IConnectionFactory connectionFactory)
{
var connection = connectionFactory.CreateConnection();
connection.Start();
var session = connection.CreateSession();
var destination = SessionUtil.GetDestination(session,
GetQueueName(1));
var consumer = session.CreateConsumer(destination);
var count = 0;
while (true)
{
if (consumer.Receive(TimeSpan.FromSeconds(5)) == null)
break;
count++;
if (count%100 == 0)
session.Commit();
}
session.Commit();
connection.Close();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (AMQ-5174) Cannot use the JDBCIOExceptionHandler when kahadb is configured with lease-database-locker
Paul Gale created AMQ-5174:
--
Summary: Cannot use the JDBCIOExceptionHandler when kahadb is
configured with lease-database-locker
Key: AMQ-5174
URL: https://issues.apache.org/jira/browse/AMQ-5174
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.9.1, 5.9.0
Reporter: Paul Gale
Priority: Critical
Fix For: 5.10.0
The {{JDBCIOExceptionHandler}} is limited to operating with the
{{JDBCPersistenceAdapter}}.
It should be allowed to work in combination with the
{{KahaDBPersistenceAdapter}} if it's configured to use a
{{LeaseDatabaseLocker}} as a locker.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Jolokia URL Path for Apache Apollo 1.7
Try /jmx/ or /hawtio/jolokia On Mon, May 5, 2014 at 12:56 PM, rdevaraj rdeva...@adobe.com wrote: I am using my HawtIo chrome plugin to manage the current ActiveMQ 5.9.1 by using the Jolokia path /api/jolokia. I am now evaluating Apache Apollo 1.7. I don't see the Jolokia URL listed anywhere. Can someone please let me know the URL Path? Regards, Ramki. -- View this message in context: http://activemq.2283324.n4.nabble.com/Jolokia-URL-Path-for-Apache-Apollo-1-7-tp4680875.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
[jira] [Created] (AMQ-5175) exclude bouncycastle dependency from unit tests run
Timothy Bish created AMQ-5175: - Summary: exclude bouncycastle dependency from unit tests run Key: AMQ-5175 URL: https://issues.apache.org/jira/browse/AMQ-5175 Project: ActiveMQ Issue Type: Improvement Components: Test Cases Affects Versions: 5.9.1, 5.9.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 5.10.0 The ApacheDS dependency used in the AMQ unit tests pulls in an old bouncycastle lib that creates errors in JDK 1.7 releases. Exclude this jar from the tests. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5173) Kaha DB cleanup fails to reclaim disk space after some time
[
https://issues.apache.org/jira/browse/AMQ-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990976#comment-13990976
]
Timothy Bish commented on AMQ-5173:
---
Have you tested with a current release of ActiveMQ? The latest release is
v5.9.1
Kaha DB cleanup fails to reclaim disk space after some time
---
Key: AMQ-5173
URL: https://issues.apache.org/jira/browse/AMQ-5173
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.6.0
Reporter: Imran
We are seeing an issue where a broker using Kaha DB will gradually increase
its footprint on disk over time and never shrink back down again even when
all queues are empty.
The default cleanup settings will reclaim space at first but over time it
seems the size of the data directory will grow and never shrink back down to
its original size.
I can reproduce this with a test that sends and consumes a large number of
messages to a single queue (.net client, broker hosted on windows). The data
file grows and will never shrink back down again.
{code}
[Test]
public void ButLoadOfMessagesOnASingleQueue()
{
const int messagesPerProducerThread = 100;
const int numberProducers = 1;
const int numberConsumers = 3;
var producersConsumers = new ListTask();
var factory = new ConnectionFactory
{
AcknowledgementMode = AcknowledgementMode.Transactional,
AsyncSend = true
};
for (var i = 0; i numberProducers; i++)
{
var producer = Task.Factory.StartNew(() = Send(factory,
messagesPerProducerThread));
producersConsumers.Add(producer);
}
for (var i = 0; i numberConsumers; i++)
{
var consumer = Task.Factory.StartNew(() = Consume(factory));
producersConsumers.Add(consumer);
}
Task.WaitAll(producersConsumers.ToArray());
}
private void Send(IConnectionFactory connectionFactory, int
noMessages)
{
var connection = connectionFactory.CreateConnection();
connection.Start();
var session = connection.CreateSession();
var destination = SessionUtil.GetDestination(session,
GetQueueName(1));
var producer = session.CreateProducer(destination);
for (var i = 0; i noMessages; i++)
{
producer.Send(new ActiveMQTextMessage(i.ToString()));
if (i%100 == 0)
session.Commit();
}
session.Commit();
connection.Close();
}
private void Consume(IConnectionFactory connectionFactory)
{
var connection = connectionFactory.CreateConnection();
connection.Start();
var session = connection.CreateSession();
var destination = SessionUtil.GetDestination(session,
GetQueueName(1));
var consumer = session.CreateConsumer(destination);
var count = 0;
while (true)
{
if (consumer.Receive(TimeSpan.FromSeconds(5)) == null)
break;
count++;
if (count%100 == 0)
session.Commit();
}
session.Commit();
connection.Close();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Compiling with Java 8
I took a stab at trying to compile ActiveMQ /w Java 8 and quickly ran into problems /w Scala. Upgrading to Scala 2.11 seems to resolve the problem. Any objections to moving up to Scala 2.11? -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
[jira] [Updated] (AMQ-5166) MessageDatabase does not consistently apply tracker settings
[ https://issues.apache.org/jira/browse/AMQ-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-5166: -- Fix Version/s: 5.10.0 MessageDatabase does not consistently apply tracker settings Key: AMQ-5166 URL: https://issues.apache.org/jira/browse/AMQ-5166 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 5.9.1 Reporter: james Priority: Minor Fix For: 5.10.0 Attachments: aq_patch.txt The failoverProducersAuditDepth and maxFailoverProducersToTrack settings for MessageDatabase are actually used by the underlying MetaData's ActiveMQMessageAuditNoSync instance. However, the MetaData instance and ActiveMQMessageAuditNoSync may change over the life of the MessageDatabase, and these settings are not perpetuated to the new instances (or restored instances). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-5166) MessageDatabase does not consistently apply tracker settings
[ https://issues.apache.org/jira/browse/AMQ-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-5166. --- Resolution: Fixed Tested against trunk and doesn't seem to break any tests locally. Patch applied with thanks. MessageDatabase does not consistently apply tracker settings Key: AMQ-5166 URL: https://issues.apache.org/jira/browse/AMQ-5166 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 5.9.1 Reporter: james Priority: Minor Attachments: aq_patch.txt The failoverProducersAuditDepth and maxFailoverProducersToTrack settings for MessageDatabase are actually used by the underlying MetaData's ActiveMQMessageAuditNoSync instance. However, the MetaData instance and ActiveMQMessageAuditNoSync may change over the life of the MessageDatabase, and these settings are not perpetuated to the new instances (or restored instances). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5160) Wildcard subscriptions bypass Authentication / Authorization
[ https://issues.apache.org/jira/browse/AMQ-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13991105#comment-13991105 ] Dhiraj Bokde commented on AMQ-5160: --- [~dejanb] How are you planning on adding the MQTT retained message recovery policy? In theory it should be added on the fly from the MQTT protocol converter when an MQTT client sends a message to a Topic. Also, if another recovery policy exists on the Topic, then the MQTT policy should act in parallel with it. What do you think? In general I like the idea of the recovery policy, since it would allow non-MQTT connections to receive retained messages too. Meanwhile, I opened a pull request https://github.com/apache/activemq/pull/21 to add authorization for retained messages with the current approach. Wildcard subscriptions bypass Authentication / Authorization Key: AMQ-5160 URL: https://issues.apache.org/jira/browse/AMQ-5160 Project: ActiveMQ Issue Type: Bug Components: MQTT Affects Versions: 5.9.1 Reporter: Surf Priority: Critical Labels: authentication, authorization, mqtt, security Fix For: 5.10.0 Attachments: activemq.xml, groups.properties, login.config, users.properties I am using MQTT on AMQ 5.9.1 After latest MQTT hardening from [~dhirajsb] , there is an issue of MQTT retained messages. Simple case: Set Authentication / Authorization for two different TOPICS. Send retained message to one topic. Try to subscribe # with other second user. It will show retained messages published by TOPIC 1. here i have attached test configurations. -- This message was sent by Atlassian JIRA (v6.2#6252)
