[jira] [Created] (AMQCPP-477) Can't specify empty values in URIs
Valeriy V. Argunov created AMQCPP-477:
-
Summary: Can't specify empty values in URIs
Key: AMQCPP-477
URL: https://issues.apache.org/jira/browse/AMQCPP-477
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: Transports
Affects Versions: 3.6.0
Reporter: Valeriy V. Argunov
Assignee: Timothy Bish
Can't specify empty values for wireFormat.topicPrefix, wireFormat.queuePrefix
etc in URIs because URISupport::parseQuery doesn't support this.
It can't parse such URI correctly:
tcp://10.0.0.1:333?wireFormat=stompwireFormat.topicPrefix=wireFormat.queuePrefix=
I've fixed this by the following code in URISupport::parseQuery:
int tokensCount = tokenizer.countTokens();
if (tokensCount != 2 tokensCount != 1) {
throw IllegalArgumentException(__FILE__, __LINE__, URISupport::parseQuery
- Invalid URI Option.);
}
--
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] [Created] (AMQ-4489) Newly received messages with higher priority are never consumed, until broker is restarted
metatech created AMQ-4489: - Summary: Newly received messages with higher priority are never consumed, until broker is restarted Key: AMQ-4489 URL: https://issues.apache.org/jira/browse/AMQ-4489 Project: ActiveMQ Issue Type: Bug Components: Broker, Message Store Affects Versions: 5.5.1 Environment: ServiceMix 4.4.2, using Camel producers/consumers Reporter: metatech We configured message prioritization according to the following page : http://activemq.apache.org/how-can-i-support-priority-queues.html We use a JDBC adapter for message persistence, in an Oracle database. We also specify a memory limit for the queue (24 MB) We use ActiveMQ 5.5.1 within ServiceMix 4.4.2, and use Camel JMS producers/consumers. Message can have 2 priorities : 4 (normal) for non-business hours and 9 (high) for business hours. The scenario to reproduce the problem is the following : 1. Enqueue 1000 normal and 1000 high messages. 2. All high messages are consumed first. 3. After a few low messages are consumed, enqueue additional 1000 high messages. 4. All low messages are consumed before high messages. 5. All additional 1000 messages are never consumed. 6. Restart broker. 7. All additional 1000 messages start getting consumed. In production, we have a producer with high peaks during the night (10,000-100,000 messages/hour), and 6 consumers (about 5,000-10,000 messages/hour), so the queue can reach 100,000-200,000 messages at some periods of the day. Messages are small (200 bytes). We enabled SQL query tracing on the broker (with log4jdbc), and we see that the logic with which the findNextMessagesByPriorityStatement query is called does not seem correct in the JDBCMessageStore.recoverNextMessages method : At step 2, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 200 AND PRIORITY = 9) OR PRIORITY 9) ORDER BY PRIORITY DESC, ID At step 4, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 1200 AND PRIORITY = 4) OR PRIORITY 4) ORDER BY PRIORITY DESC, ID The problem is that the value for the last priority stored in the lastRecoveredPriority variable of the JDBCMessageStore stays permanently to 4, until step 6, where it is reset to 9. We tried changing the priority to constant '9' in the query. It works OK until step 3, where only 200 messages are consumed Our understanding is that there should be one lastRecoveredSequenceId variable for each priority level, so that the last consumed message but not yet removed from the DB is memorized, and also the priority should probably also be reset to 9 every time the query is executed. Can you have a look please ? -- 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] [Commented] (AMQ-4372) WebConsole throw Java Heap Space when browse a queue with more than 100 elements
[ https://issues.apache.org/jira/browse/AMQ-4372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642714#comment-13642714 ] Subathra Jayaraman commented on AMQ-4372: - Same issue here, does not happen on 5.7. Tested on 1.6 and 1.7 JDK. If you click on 'active consumers' in the console when this is happening, you can see an enormous amount of enqueue and dequeues from the MQ host itself which seems to eat the box. WebConsole throw Java Heap Space when browse a queue with more than 100 elements Key: AMQ-4372 URL: https://issues.apache.org/jira/browse/AMQ-4372 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Linux/Ubuntu Reporter: Grégory OLIVER Labels: web-console Fix For: 5.9.0 I have a standalone installation of activemq. When I want to browse a queue with more than 100 elements, the console throw a Java Heap Space, because he try to show all elements in the queue. But when I have 40 elements, the page work well, and i can browse messages. It should be interesting to paginate this page, to only show, for example, the first 100 elements. The page : http://localhost:8161/admin/browse.jsp?JMSDestination=TestQueueOne Added : I have tested with the 5.7.0 version of activemq and this bug doesn't exist. -- 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] [Created] (AMQ-4490) JDBCMessageStore fails to retrieve message after 200 messages when cache is disabled
metatech created AMQ-4490:
-
Summary: JDBCMessageStore fails to retrieve message after 200
messages when cache is disabled
Key: AMQ-4490
URL: https://issues.apache.org/jira/browse/AMQ-4490
Project: ActiveMQ
Issue Type: Bug
Components: Message Store
Affects Versions: 5.5.1
Environment: ServiceMix 4.4.2
Reporter: metatech
When trying to reproduce bug AMQ-4489, we found that the JDBCMessageStore fails
to retrieve all messages from the store when useCache=false.
The existing unit test JDBCMessagePriorityTest reproduces it (see below).
A similar problem occurs when MemoryLimit on the queue is used (which forces
the messages to be written to and later read from the JDBC message store).
Can you please have a look ?
---
Test set: org.apache.activemq.store.jdbc.JDBCMessagePriorityTest
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 12.94 sec
FAILURE!
testQueues
{useCache=false}(org.apache.activemq.store.jdbc.JDBCMessagePriorityTest) Time
elapsed: 6.656 sec FAILURE!
junit.framework.AssertionFailedError: Message 200 was null
--
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] [Commented] (AMQ-4372) WebConsole throw Java Heap Space when browse a queue with more than 100 elements
[ https://issues.apache.org/jira/browse/AMQ-4372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642719#comment-13642719 ] Subathra Jayaraman commented on AMQ-4372: - A few more details on our setup; ActiveMQ 5.8.0, Running on Java 1.6.x Backend Storage is Multi-Master Percona 5.5.x WebConsole throw Java Heap Space when browse a queue with more than 100 elements Key: AMQ-4372 URL: https://issues.apache.org/jira/browse/AMQ-4372 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Linux/Ubuntu Reporter: Grégory OLIVER Labels: web-console Fix For: 5.9.0 I have a standalone installation of activemq. When I want to browse a queue with more than 100 elements, the console throw a Java Heap Space, because he try to show all elements in the queue. But when I have 40 elements, the page work well, and i can browse messages. It should be interesting to paginate this page, to only show, for example, the first 100 elements. The page : http://localhost:8161/admin/browse.jsp?JMSDestination=TestQueueOne Added : I have tested with the 5.7.0 version of activemq and this bug doesn't exist. -- 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-4489) Newly received messages with higher priority are never consumed, until broker is restarted
[ https://issues.apache.org/jira/browse/AMQ-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] metatech updated AMQ-4489: -- Description: We configured message prioritization according to the following page : http://activemq.apache.org/how-can-i-support-priority-queues.html We use a JDBC adapter for message persistence, in an Oracle database. Prioritisation is enabled on the queue with the prioritizeMessages option, and we also specify a memory limit for the queue (24 MB) We use ActiveMQ 5.5.1 within ServiceMix 4.4.2, and use Camel JMS producers/consumers. Message can have 2 priorities : 4 (normal) for non-business hours and 9 (high) for business hours. The scenario to reproduce the problem is the following : 1. Enqueue 1000 normal and 1000 high messages. 2. All high messages are consumed first. 3. After a few low messages are consumed, enqueue additional 1000 high messages. 4. All low messages are consumed before high messages. 5. All additional 1000 messages are never consumed. 6. Restart broker. 7. All additional 1000 messages start getting consumed. In production, we have a producer with high peaks during the night (10,000-100,000 messages/hour), and 6 consumers (about 5,000-10,000 messages/hour), so the queue can reach 100,000-200,000 messages at some periods of the day. Messages are small (200 bytes). We enabled SQL query tracing on the broker (with log4jdbc), and we see that the logic with which the findNextMessagesByPriorityStatement query is called does not seem correct in the JDBCMessageStore.recoverNextMessages method : At step 2, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 200 AND PRIORITY = 9) OR PRIORITY 9) ORDER BY PRIORITY DESC, ID At step 4, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 1200 AND PRIORITY = 4) OR PRIORITY 4) ORDER BY PRIORITY DESC, ID The problem is that the value for the last priority stored in the lastRecoveredPriority variable of the JDBCMessageStore stays permanently to 4, until step 6, where it is reset to 9. We tried changing the priority to constant '9' in the query. It works OK until step 3, where only 200 messages are consumed Our understanding is that there should be one lastRecoveredSequenceId variable for each priority level, so that the last consumed message but not yet removed from the DB is memorized, and also the priority should probably also be reset to 9 every time the query is executed. Can you have a look please ? was: We configured message prioritization according to the following page : http://activemq.apache.org/how-can-i-support-priority-queues.html We use a JDBC adapter for message persistence, in an Oracle database. We also specify a memory limit for the queue (24 MB) We use ActiveMQ 5.5.1 within ServiceMix 4.4.2, and use Camel JMS producers/consumers. Message can have 2 priorities : 4 (normal) for non-business hours and 9 (high) for business hours. The scenario to reproduce the problem is the following : 1. Enqueue 1000 normal and 1000 high messages. 2. All high messages are consumed first. 3. After a few low messages are consumed, enqueue additional 1000 high messages. 4. All low messages are consumed before high messages. 5. All additional 1000 messages are never consumed. 6. Restart broker. 7. All additional 1000 messages start getting consumed. In production, we have a producer with high peaks during the night (10,000-100,000 messages/hour), and 6 consumers (about 5,000-10,000 messages/hour), so the queue can reach 100,000-200,000 messages at some periods of the day. Messages are small (200 bytes). We enabled SQL query tracing on the broker (with log4jdbc), and we see that the logic with which the findNextMessagesByPriorityStatement query is called does not seem correct in the JDBCMessageStore.recoverNextMessages method : At step 2, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 200 AND PRIORITY = 9) OR PRIORITY 9) ORDER BY PRIORITY DESC, ID At step 4, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 1200 AND PRIORITY = 4) OR PRIORITY 4) ORDER BY PRIORITY DESC, ID The problem is that the value for the last priority stored in the lastRecoveredPriority variable of the JDBCMessageStore stays permanently to 4, until step 6, where it is reset to 9. We tried changing the priority to constant '9' in the query. It works OK until step 3, where only 200 messages are consumed Our understanding is that there should be one lastRecoveredSequenceId variable for each priority level, so that the last consumed message but not yet removed from the DB is memorized, and also the priority should probably also be reset to 9 every time the query is
[jira] [Updated] (AMQ-4489) Newly received messages with higher priority are never consumed, until broker is restarted
[ https://issues.apache.org/jira/browse/AMQ-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] metatech updated AMQ-4489: -- Description: We configured message prioritization according to the following page : http://activemq.apache.org/how-can-i-support-priority-queues.html We use a JDBC adapter for message persistence, in an Oracle database. Prioritisation is enabled on the queue with the prioritizedMessages option, and we also specify a memory limit for the queue (24 MB) We use ActiveMQ 5.5.1 within ServiceMix 4.4.2, and use Camel JMS producers/consumers. Message can have 2 priorities : 4 (normal) for non-business hours and 9 (high) for business hours. The scenario to reproduce the problem is the following : 1. Enqueue 1000 normal and 1000 high messages. 2. All high messages are consumed first. 3. After a few low messages are consumed, enqueue additional 1000 high messages. 4. All low messages are consumed before high messages. 5. All additional 1000 messages are never consumed. 6. Restart broker. 7. All additional 1000 messages start getting consumed. In production, we have a producer with high peaks during the night (10,000-100,000 messages/hour), and 6 consumers (about 5,000-10,000 messages/hour), so the queue can reach 100,000-200,000 messages at some periods of the day. Messages are small (200 bytes). We enabled SQL query tracing on the broker (with log4jdbc), and we see that the logic with which the findNextMessagesByPriorityStatement query is called does not seem correct in the JDBCMessageStore.recoverNextMessages method : At step 2, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 200 AND PRIORITY = 9) OR PRIORITY 9) ORDER BY PRIORITY DESC, ID At step 4, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 1200 AND PRIORITY = 4) OR PRIORITY 4) ORDER BY PRIORITY DESC, ID The problem is that the value for the last priority stored in the lastRecoveredPriority variable of the JDBCMessageStore stays permanently to 4, until step 6, where it is reset to 9. We tried changing the priority to constant '9' in the query. It works OK until step 3, where only 200 messages are consumed Our understanding is that there should be one lastRecoveredSequenceId variable for each priority level, so that the last consumed message but not yet removed from the DB is memorized, and also the priority should probably also be reset to 9 every time the query is executed. Can you have a look please ? was: We configured message prioritization according to the following page : http://activemq.apache.org/how-can-i-support-priority-queues.html We use a JDBC adapter for message persistence, in an Oracle database. Prioritisation is enabled on the queue with the prioritizeMessages option, and we also specify a memory limit for the queue (24 MB) We use ActiveMQ 5.5.1 within ServiceMix 4.4.2, and use Camel JMS producers/consumers. Message can have 2 priorities : 4 (normal) for non-business hours and 9 (high) for business hours. The scenario to reproduce the problem is the following : 1. Enqueue 1000 normal and 1000 high messages. 2. All high messages are consumed first. 3. After a few low messages are consumed, enqueue additional 1000 high messages. 4. All low messages are consumed before high messages. 5. All additional 1000 messages are never consumed. 6. Restart broker. 7. All additional 1000 messages start getting consumed. In production, we have a producer with high peaks during the night (10,000-100,000 messages/hour), and 6 consumers (about 5,000-10,000 messages/hour), so the queue can reach 100,000-200,000 messages at some periods of the day. Messages are small (200 bytes). We enabled SQL query tracing on the broker (with log4jdbc), and we see that the logic with which the findNextMessagesByPriorityStatement query is called does not seem correct in the JDBCMessageStore.recoverNextMessages method : At step 2, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 200 AND PRIORITY = 9) OR PRIORITY 9) ORDER BY PRIORITY DESC, ID At step 4, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 1200 AND PRIORITY = 4) OR PRIORITY 4) ORDER BY PRIORITY DESC, ID The problem is that the value for the last priority stored in the lastRecoveredPriority variable of the JDBCMessageStore stays permanently to 4, until step 6, where it is reset to 9. We tried changing the priority to constant '9' in the query. It works OK until step 3, where only 200 messages are consumed Our understanding is that there should be one lastRecoveredSequenceId variable for each priority level, so that the last consumed message but not yet removed from the DB is memorized, and
[jira] [Created] (AMQ-4491) activemq-camel component is not a bundle
Matt Brozowski created AMQ-4491: --- Summary: activemq-camel component is not a bundle Key: AMQ-4491 URL: https://issues.apache.org/jira/browse/AMQ-4491 Project: ActiveMQ Issue Type: Bug Components: activemq-camel Affects Versions: 5.8.0 Reporter: Matt Brozowski When attempting to install the activemq-camel component in karaf it fail to install because the activemq-camel jar here: http://search.maven.org/remotecontent?filepath=org/apache/activemq/activemq-camel/5.8.0/activemq-camel-5.8.0.jar is not a valid osgi bundle. It is missing most of the manifest entries in the bundle. -- 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] [Created] (AMQNET-433) Correctly rethrow exceptions without swallowing the stack trace
Daniel Marbach created AMQNET-433:
-
Summary: Correctly rethrow exceptions without swallowing the stack
trace
Key: AMQNET-433
URL: https://issues.apache.org/jira/browse/AMQNET-433
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Trivial
When looking through the code I saw a lot of the following code snippets:
try
{
}
catch(AnyException ex)
{
// do something
throw ex;
}
This WILL rewrite the stack trace and is not considered best practice. I
suggest you change the appropriate places in the code to:
try
{
}
catch(AnyException ex)
{
// do something
throw;
}
--
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] [Commented] (AMQNET-413) Message producers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642782#comment-13642782
]
Daniel Marbach commented on AMQNET-413:
---
Any timeline for this issue?
Message producers do not respect DTC Transactions correctly
---
Key: AMQNET-413
URL: https://issues.apache.org/jira/browse/AMQNET-413
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Remo Gloor
Assignee: Jim Gomes
Priority: Critical
Attachments: allDTCImprovments.patch,
AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
AMQNET-413.patch
When consuming messages in a transaction and sending new ones during
processing of that message and the transaction is rolled back and commited on
retry the number of published messages should be equal to the received one.
But the number of sent message is bigger than the number of received ones.
This means some of the message sends are not rolled back others are.
EDIT: Further analysis have shown that the TransactionContext.TransactionId
is null when sending eventhough a transaction is in progress and not yet
completed. It must incorrectly be assigned to null somewhere.
The following application demonstrates the problem when enqueuing 100+
messages to foo.bar
class Program
{
private static INetTxSession activeMqSession;
private static IMessageConsumer consumer;
private static INetTxConnection connection;
static void Main(string[] args)
{
using (connection = CreateActiveMqConnection())
using (activeMqSession = connection.CreateNetTxSession())
using (consumer =
activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
queue://foo.bar)))
{
connection.Start();
while (true)
{
try
{
using (TransactionScope scoped = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
IMessage msg = null;
while (msg == null)
{
msg = consumer.ReceiveNoWait();
}
OnMessage(msg);
scoped.Complete();
}
}
catch(Exception exception) {}
}
}
}
private static INetTxConnection CreateActiveMqConnection()
{
var connectionFactory = new
Apache.NMS.ActiveMQ.NetTxConnectionFactory(activemq:tcp://localhost:61616)
{
AcknowledgementMode = AcknowledgementMode.Transactional
};
return connectionFactory.CreateNetTxConnection();
}
private static void OnMessage(IMessage message)
{
var x = new TestSinglePhaseCommit();
Console.WriteLine(Processing message {0} in transaction {1} -
{2}, message.NMSMessageId,
Transaction.Current.TransactionInformation.LocalIdentifier,
Transaction.Current.TransactionInformation.DistributedIdentifier);
var session2 = activeMqSession;
{
Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
EnlistmentOptions.None);
using (var producer =
session2.CreateProducer(SessionUtil.GetQueue(session2, queue://foo.baz)))
{
producer.Send(new ActiveMQTextMessage(foo));
}
if (!message.NMSRedelivered) throw new Exception();
}
}
}
internal class TestSinglePhaseCommit : ISinglePhaseNotification
{
public void Prepare(PreparingEnlistment preparingEnlistment)
{
preparingEnlistment.Prepared();
}
public void Commit(Enlistment enlistment)
{
enlistment.Done();
}
public void Rollback(Enlistment enlistment)
{
enlistment.Done();
}
public void InDoubt(Enlistment enlistment)
{
enlistment.Done();
}
public void SinglePhaseCommit(SinglePhaseEnlistment
singlePhaseEnlistment)
{
singlePhaseEnlistment.Committed();
}
}
--
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] [Commented] (AMQNET-405) Messages are not dequeued when using Two Phase Commit for DTC Transaction
[
https://issues.apache.org/jira/browse/AMQNET-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642783#comment-13642783
]
Daniel Marbach commented on AMQNET-405:
---
Any timeline for this issue? 413 has patch which fixes that problem.
Messages are not dequeued when using Two Phase Commit for DTC Transaction
-
Key: AMQNET-405
URL: https://issues.apache.org/jira/browse/AMQNET-405
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Affects Versions: 1.5.6
Environment: Windows 7, AMQ 5.7
Reporter: Remo Gloor
Assignee: Jim Gomes
Messages are not removed from the queue even though they are processes
correctly in the following scenaro:
Create a NetTxConnection and NetTxSession. Create a consumer for some queue
and register the Listener event. Create a new TransactionScope in the event
handler. Inside the consumer you send a new message to some other queue using
the session of the consumer. Do now some action that uses the Distributed
Transaction from another system (e.g. writing to a database) to force that
two phase commit is used instead of Single Phase Commit. Complete the and
dispose the TransactionScope.
I'd expect that that the sent message is delivered to the queue, the database
is modified and the received message is removed from the input queue. But the
behavior is that the last expectation is not met. The message remains in the
input queue.
If you use an own session for sending the messages the problem does not
occur. But this has the disadvantage the you will always do two phase commits
even if AMQ is the only system that takes part in the Distrubuted Transaction.
Code demonstrating the problem:
namespace ConsoleApplication1
{
using System;
using System.Transactions;
using Apache.NMS;
using Apache.NMS.ActiveMQ.Commands;
using Apache.NMS.Util;
class Program
{
private static INetTxSession activeMqSession;
private static IMessageConsumer consumer;
private static INetTxConnection connection;
static void Main(string[] args)
{
using (connection = CreateActiveMqConnection())
using (activeMqSession = connection.CreateNetTxSession())
using (consumer =
activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
queue://foo.bar)))
{
consumer.Listener += OnMessage;
connection.Start();
Console.WriteLine(Started);
Console.WriteLine(Press any key to exit);
Console.ReadKey();
}
}
private static INetTxConnection CreateActiveMqConnection()
{
var connectionFactory = new
Apache.NMS.ActiveMQ.NetTxConnectionFactory(activemq:tcp://localhost:61616)
{
AcknowledgementMode = AcknowledgementMode.Transactional
};
return connectionFactory.CreateNetTxConnection();
}
private static void OnMessage(IMessage message)
{
var x = new TestSinglePhaseCommit();
using (var session2 = connection.CreateNetTxSession())
using (var tx = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
Console.WriteLine(Message Received);
// Force two phase commit, In reality this happens by using
another system that takes part in the
// distributed transaction like a database.
Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
EnlistmentOptions.None);
// The proble occurs only if a message is sent using the same
session like the receiver
using (var producer =
session2.CreateProducer(SessionUtil.GetQueue(session2, queue://foo.baz)))
{
producer.Send(new ActiveMQTextMessage(foo));
}
tx.Complete();
}
}
}
internal class TestSinglePhaseCommit : ISinglePhaseNotification
{
public void Prepare(PreparingEnlistment preparingEnlistment)
{
preparingEnlistment.Prepared();
}
public void Commit(Enlistment enlistment)
{
enlistment.Done();
}
public void Rollback(Enlistment enlistment)
{
enlistment.Done();
}
public void InDoubt(Enlistment enlistment)
{
enlistment.Done();
}
public void SinglePhaseCommit(SinglePhaseEnlistment
singlePhaseEnlistment)
{
singlePhaseEnlistment.Committed();
}
}
}
--
This message
[jira] [Commented] (AMQNET-404) ActiveMQByteMessage Content accessing multiple times wipes the property
[
https://issues.apache.org/jira/browse/AMQNET-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642786#comment-13642786
]
Daniel Marbach commented on AMQNET-404:
---
No I didn't call reset. So I close this issue if this is the defined behavior
ActiveMQByteMessage Content accessing multiple times wipes the property
---
Key: AMQNET-404
URL: https://issues.apache.org/jira/browse/AMQNET-404
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Affects Versions: 1.5.6
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Minor
If you have an IBytesMessage and for example do the following:
byte[] content = null;
if (message.Content!= null)
{
content = message.Content;
}
Accessing content the first time will return the correct data.
Accessing a second time the content property will return an empty byte array
which has the length of the data but all bytes are zero.
It is OK that the content property is evaluated lazily but it should not
return different data when accessing multiple times. So accessing the
property the first time should read the buffer and assign it to a field and
then always return that byte buffer.
--
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-4489) Newly received messages with higher priority are never consumed, until broker is restarted
[ https://issues.apache.org/jira/browse/AMQ-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] metatech updated AMQ-4489: -- Description: We configured message prioritization according to the following page : http://activemq.apache.org/how-can-i-support-priority-queues.html We use a JDBC adapter for message persistence, in an Oracle database. Prioritisation is enabled on the queue with the prioritizedMessages option, and we also specify a memory limit for the queue (24 MB) We use ActiveMQ 5.5.1 within ServiceMix 4.4.2, and use Camel JMS producers/consumers. Message can have 2 priorities : 4 (normal) for non-business hours and 9 (high) for business hours. The scenario to reproduce the problem is the following : 1. Enqueue 1000 normal and 1000 high messages. 2. All high messages are consumed first. 3. After a few normal messages are consumed, enqueue additional 1000 high messages. 4. All normal messages are consumed before high messages. 5. All additional high 1000 messages are never consumed. 6. Restart broker. 7. All additional high 1000 messages start getting consumed. In production, we have a producer with high peaks during the night (10,000-100,000 messages/hour), and 6 consumers (about 5,000-10,000 messages/hour), so the queue can reach 100,000-200,000 messages at some periods of the day. Messages are small (200 bytes). We enabled SQL query tracing on the broker (with log4jdbc), and we see that the logic with which the findNextMessagesByPriorityStatement query is called does not seem correct in the JDBCMessageStore.recoverNextMessages method : At step 2, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 200 AND PRIORITY = 9) OR PRIORITY 9) ORDER BY PRIORITY DESC, ID At step 4, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 1200 AND PRIORITY = 4) OR PRIORITY 4) ORDER BY PRIORITY DESC, ID The problem is that the value for the last priority stored in the lastRecoveredPriority variable of the JDBCMessageStore stays permanently to 4, until step 6, where it is reset to 9. We tried changing the priority to constant '9' in the query. It works OK until step 3, where only 200 messages are consumed Our understanding is that there should be one lastRecoveredSequenceId variable for each priority level, so that the last consumed message but not yet removed from the DB is memorized, and also the priority should probably also be reset to 9 every time the query is executed. Can you have a look please ? was: We configured message prioritization according to the following page : http://activemq.apache.org/how-can-i-support-priority-queues.html We use a JDBC adapter for message persistence, in an Oracle database. Prioritisation is enabled on the queue with the prioritizedMessages option, and we also specify a memory limit for the queue (24 MB) We use ActiveMQ 5.5.1 within ServiceMix 4.4.2, and use Camel JMS producers/consumers. Message can have 2 priorities : 4 (normal) for non-business hours and 9 (high) for business hours. The scenario to reproduce the problem is the following : 1. Enqueue 1000 normal and 1000 high messages. 2. All high messages are consumed first. 3. After a few low messages are consumed, enqueue additional 1000 high messages. 4. All low messages are consumed before high messages. 5. All additional 1000 messages are never consumed. 6. Restart broker. 7. All additional 1000 messages start getting consumed. In production, we have a producer with high peaks during the night (10,000-100,000 messages/hour), and 6 consumers (about 5,000-10,000 messages/hour), so the queue can reach 100,000-200,000 messages at some periods of the day. Messages are small (200 bytes). We enabled SQL query tracing on the broker (with log4jdbc), and we see that the logic with which the findNextMessagesByPriorityStatement query is called does not seem correct in the JDBCMessageStore.recoverNextMessages method : At step 2, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 200 AND PRIORITY = 9) OR PRIORITY 9) ORDER BY PRIORITY DESC, ID At step 4, we see the following query being executed : SELECT ID, MSG FROM ACTIVEMQ_MSGS WHERE CONTAINER='priorityQueue' AND ((ID 1200 AND PRIORITY = 4) OR PRIORITY 4) ORDER BY PRIORITY DESC, ID The problem is that the value for the last priority stored in the lastRecoveredPriority variable of the JDBCMessageStore stays permanently to 4, until step 6, where it is reset to 9. We tried changing the priority to constant '9' in the query. It works OK until step 3, where only 200 messages are consumed Our understanding is that there should be one lastRecoveredSequenceId variable for each priority level, so that the last consumed message but not yet removed from the DB is
[jira] [Created] (AMQNET-434) FailoverTransport Memory Leak with TransactionState
Daniel Marbach created AMQNET-434: - Summary: FailoverTransport Memory Leak with TransactionState Key: AMQNET-434 URL: https://issues.apache.org/jira/browse/AMQNET-434 Project: ActiveMQ .Net Issue Type: Bug Affects Versions: 1.5.6 Reporter: Daniel Marbach Assignee: Jim Gomes I'm hunting down a possible memory leak. We have the following problem in production: when the consumer/subscriber endpoint runs for a long time with failover transport enabled the memory grows indefinitely. I used YouTrack and AntsProfiler to hunt down the issues. The retention path I see in production is the following: The FailoverTransport nested class FailoverTask has two ConnectionStateTrackers this keeps a dictionary which links the ConnectionId to the ConnectionState. The ConnectionState itself has a dictionary which links the transactionId to the TransactionState. The TranscationState tracks commands. BUT these commands are never freed up from the transaction state and stay there forever which will blow up the memory some time. I'm currently investigation how to fix this but must first properly understand the code. I opened up this issue in the hope that it will ring a bell for you guys. Daniel -- 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] [Closed] (AMQCPP-477) Can't specify empty values in URIs
[
https://issues.apache.org/jira/browse/AMQCPP-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish closed AMQCPP-477.
---
Resolution: Not A Problem
All options require a value otherwise the URI is invalid, plus you definitely
need a topic and queue prefix or things will end badly.
Can't specify empty values in URIs
--
Key: AMQCPP-477
URL: https://issues.apache.org/jira/browse/AMQCPP-477
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: Transports
Affects Versions: 3.6.0
Reporter: Valeriy V. Argunov
Assignee: Timothy Bish
Can't specify empty values for wireFormat.topicPrefix, wireFormat.queuePrefix
etc in URIs because URISupport::parseQuery doesn't support this.
It can't parse such URI correctly:
tcp://10.0.0.1:333?wireFormat=stompwireFormat.topicPrefix=wireFormat.queuePrefix=
I've fixed this by the following code in URISupport::parseQuery:
int tokensCount = tokenizer.countTokens();
if (tokensCount != 2 tokensCount != 1) {
throw IllegalArgumentException(__FILE__, __LINE__,
URISupport::parseQuery - Invalid URI Option.);
}
--
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] [Created] (AMQ-4492) ActiveMQ does not work on Karaf 3
Christian Schneider created AMQ-4492: Summary: ActiveMQ does not work on Karaf 3 Key: AMQ-4492 URL: https://issues.apache.org/jira/browse/AMQ-4492 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Karaf 3.0.0.RC1 Reporter: Christian Schneider Fix For: 5.9.0 when I try to install activemq 5.7.0 into karaf 3.0.0.RC1 I get the following error: karaf@root() feature:install activemq-blueprint Error executing command: Could not start bundle mvn:org.apache.activemq/activemq-karaf/5.7.0 in feature(s) activemq-5.7.0: Unresolved constraint in bundle activemq-karaf [297]: Unable to resolve 297.0: missing requirement [297.0] osgi.wiring.package; ((osgi.wiring.package=org.apache.felix.gogo.commands.basic)(version=0.10.0)(!(version=1.0.0))) The exported packages in karaf look like this: exports | grep gogo org.apache.felix.gogo.api | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.commands | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.runtime.activator | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.runtime.threadio | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.runtime | 0.10.0 | 48 | org.apache.karaf.shell.console For ActiveMQ 5.8.0 the error is similar. -- 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] [Commented] (AMQ-4492) ActiveMQ does not work on Karaf 3
[ https://issues.apache.org/jira/browse/AMQ-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642883#comment-13642883 ] Christian Schneider commented on AMQ-4492: -- The package org.apache.felix.gogo.commands has been renamed in apache karaf 3 and should better not be used from other projects anyway. The good news is that there is a way of defining commands that works in karaf 2.x and karaf 3. This is already implemented in current camel and cxf versions. So the idea is to do a similar change in activemq. I can prepare a patch for this. ActiveMQ does not work on Karaf 3 - Key: AMQ-4492 URL: https://issues.apache.org/jira/browse/AMQ-4492 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Karaf 3.0.0.RC1 Reporter: Christian Schneider Fix For: 5.9.0 when I try to install activemq 5.7.0 into karaf 3.0.0.RC1 I get the following error: karaf@root() feature:install activemq-blueprint Error executing command: Could not start bundle mvn:org.apache.activemq/activemq-karaf/5.7.0 in feature(s) activemq-5.7.0: Unresolved constraint in bundle activemq-karaf [297]: Unable to resolve 297.0: missing requirement [297.0] osgi.wiring.package; ((osgi.wiring.package=org.apache.felix.gogo.commands.basic)(version=0.10.0)(!(version=1.0.0))) The exported packages in karaf look like this: exports | grep gogo org.apache.felix.gogo.api | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.commands | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.runtime.activator | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.runtime.threadio | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.runtime | 0.10.0 | 48 | org.apache.karaf.shell.console For ActiveMQ 5.8.0 the error is similar. -- 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] [Commented] (AMQ-4492) ActiveMQ does not work on Karaf 3
[ https://issues.apache.org/jira/browse/AMQ-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642927#comment-13642927 ] Christian Schneider commented on AMQ-4492: -- I have just looked into the activemq commands. It looks like they are not normal commands. Instead it seems to reflect over the internal activemq commands and create suitable karaf commands on the fly. I don't think this can be easily changed to simple commands like in cxf or camel. Any idea how we can proceed? ActiveMQ does not work on Karaf 3 - Key: AMQ-4492 URL: https://issues.apache.org/jira/browse/AMQ-4492 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: Karaf 3.0.0.RC1 Reporter: Christian Schneider Fix For: 5.9.0 when I try to install activemq 5.7.0 into karaf 3.0.0.RC1 I get the following error: karaf@root() feature:install activemq-blueprint Error executing command: Could not start bundle mvn:org.apache.activemq/activemq-karaf/5.7.0 in feature(s) activemq-5.7.0: Unresolved constraint in bundle activemq-karaf [297]: Unable to resolve 297.0: missing requirement [297.0] osgi.wiring.package; ((osgi.wiring.package=org.apache.felix.gogo.commands.basic)(version=0.10.0)(!(version=1.0.0))) The exported packages in karaf look like this: exports | grep gogo org.apache.felix.gogo.api | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.commands | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.runtime.activator | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.runtime.threadio | 0.10.0 | 48 | org.apache.karaf.shell.console org.apache.felix.gogo.runtime | 0.10.0 | 48 | org.apache.karaf.shell.console For ActiveMQ 5.8.0 the error is similar. -- 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] [Commented] (AMQCPP-477) Can't specify empty values in URIs
[
https://issues.apache.org/jira/browse/AMQCPP-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642953#comment-13642953
]
Valeriy V. Argunov commented on AMQCPP-477:
---
But all applications that use URIs allow empty values for parameters in the
query string. Also see http://en.wikipedia.org/wiki/Query_string
Can't specify empty values in URIs
--
Key: AMQCPP-477
URL: https://issues.apache.org/jira/browse/AMQCPP-477
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: Transports
Affects Versions: 3.6.0
Reporter: Valeriy V. Argunov
Assignee: Timothy Bish
Can't specify empty values for wireFormat.topicPrefix, wireFormat.queuePrefix
etc in URIs because URISupport::parseQuery doesn't support this.
It can't parse such URI correctly:
tcp://10.0.0.1:333?wireFormat=stompwireFormat.topicPrefix=wireFormat.queuePrefix=
I've fixed this by the following code in URISupport::parseQuery:
int tokensCount = tokenizer.countTokens();
if (tokensCount != 2 tokensCount != 1) {
throw IllegalArgumentException(__FILE__, __LINE__,
URISupport::parseQuery - Invalid URI Option.);
}
--
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] [Resolved] (AMQ-4472) consumer.close() on transacted session does not release prefetched messages
[ https://issues.apache.org/jira/browse/AMQ-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-4472. - Resolution: Fixed Fix Version/s: 5.9.0 Assignee: Hiram Chirino fix in http://svn.apache.org/r1471673 consumer.close() on transacted session does not release prefetched messages --- Key: AMQ-4472 URL: https://issues.apache.org/jira/browse/AMQ-4472 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.8.0 Reporter: Jason Sherman Assignee: Hiram Chirino Labels: transactions Fix For: 5.9.0 Attachments: amq-4472.zip When using transactions an issue can arise where the consumer has messages in it's prefetch and when consumer.close() is called the consumer is not closed and does not release the messages. The use case is as follows: 1) Create producer 2) Create consumer 3) Send message to queue 4) Commit session 5) Send a new message 6) Close the consumer 7) Start a new consumer 8) Try to receive the message Test case will be attached shortly. -- 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] [Reopened] (AMQCPP-477) Can't specify empty values in URIs
[
https://issues.apache.org/jira/browse/AMQCPP-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valeriy V. Argunov reopened AMQCPP-477:
---
The issue is still here.
Can't specify empty values in URIs
--
Key: AMQCPP-477
URL: https://issues.apache.org/jira/browse/AMQCPP-477
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: Transports
Affects Versions: 3.6.0
Reporter: Valeriy V. Argunov
Assignee: Timothy Bish
Can't specify empty values for wireFormat.topicPrefix, wireFormat.queuePrefix
etc in URIs because URISupport::parseQuery doesn't support this.
It can't parse such URI correctly:
tcp://10.0.0.1:333?wireFormat=stompwireFormat.topicPrefix=wireFormat.queuePrefix=
I've fixed this by the following code in URISupport::parseQuery:
int tokensCount = tokenizer.countTokens();
if (tokensCount != 2 tokensCount != 1) {
throw IllegalArgumentException(__FILE__, __LINE__,
URISupport::parseQuery - Invalid URI Option.);
}
--
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] [Reopened] (AMQ-4351) Deadlock when unsubscribing durable subscriber
[ https://issues.apache.org/jira/browse/AMQ-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reopened AMQ-4351: --- Assignee: Timothy Bish (was: Hiram Chirino) Changes for this issue have affected the destination stats for Topics depending on whether keep durable subs active is true or not. Deadlock when unsubscribing durable subscriber -- Key: AMQ-4351 URL: https://issues.apache.org/jira/browse/AMQ-4351 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.7.0, 5.8.0 Environment: Setup: Active MQ 5.7.0 with master/slave using JDBC store Approx 3 - 5 concurrent durable subscribers Approx 5 messages / sec Reporter: Tim Lammens Assignee: Timothy Bish Labels: patch Fix For: 5.9.0 Attachments: ActiveMQUnsubscribeTest.java, dispatcher.patch We started using durable subscribers a week ago, and after the 4th durable subscriber unsubscribed (due to 1 hour inactivity), the system deadlocked. If the Durable Subscriber Cleanup Timer goes of at the wrong time, your entire server locks up. Setup: Active MQ 5.7.0 with master/slave using JDBC store Approx 3 - 5 concurrent durable subscribers Approx 5 messages / sec Active MQ checks every 1 minute for subscribers which have been offline for 1 hour. Locked threads: ActiveMQ Transport: tcp:///79.125.71.104:48082@8090: at org.apache.activemq.broker.region.Topic.doMessageSend(Topic.java:446) - waiting to lock 0xc6228480 (a org.apache.activemq.broker.region.Topic) at org.apache.activemq.broker.region.Topic.send(Topic.java:427) at org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:407) at org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:503) ActiveMQ Transport: tcp:///79.125.71.104:47590@8090: at org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:142) - waiting to lock 0xc66ba050 (a java.lang.Object) at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:243) at org.apache.activemq.broker.region.policy.StrictOrderDispatchPolicy.dispatch(StrictOrderDispatchPolicy.java:58) ActiveMQ Durable Subscriber Cleanup Timer: at org.apache.activemq.broker.region.Topic.deactivate(Topic.java:288) - waiting to lock 0xc6250670 (a java.util.concurrent.CopyOnWriteArrayList) at org.apache.activemq.broker.region.DurableTopicSubscription.deactivate(DurableTopicSubscription.java:184) - locked 0xc66ba060 (a java.lang.Object) - locked 0xc66ba050 (a java.lang.Object) at org.apache.activemq.broker.region.Topic.deleteSubscription(Topic.java:195) at org.apache.activemq.broker.region.TopicRegion.removeSubscription(TopicRegion.java:199) at org.apache.activemq.broker.region.TopicRegion.doCleanup(TopicRegion.java:99) I have attached a patch which fixes the problem. Since there is only one dispatch policy per Topic, synchronisation can happen on the DispatchPolicy instead of on the consumers object which causes the deadlock. -- 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
Build failed in Jenkins: ActiveMQ-Java7 #184
See https://builds.apache.org/job/ActiveMQ-Java7/184/changes Changes: [tabish] Fix for: https://issues.apache.org/jira/browse/AMQ-4488 [gtully] https://issues.apache.org/jira/browse/AMQ-4486 - fix and test -- [...truncated 5734 lines...] [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ activemq-blueprint --- Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 [JENKINS] Recording test results [INFO] [INFO] --- maven-bundle-plugin:2.3.7:bundle (default-bundle) @ activemq-blueprint --- [WARNING] Bundle org.apache.activemq:activemq-blueprint:bundle:5.9-SNAPSHOT : Instructions in Export-Package that are never used: org\.apache\.activemq.*.* Classpath: Jar:.,Jar:org.apache.aries.blueprint,Jar:xbean-blueprint,Jar:commons-jexl,Jar:pax-logging-api [WARNING] Bundle org.apache.activemq:activemq-blueprint:bundle:5.9-SNAPSHOT : Superfluous export-package instructions: [org.apache.activemq**] [INFO] [INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @ activemq-blueprint --- [INFO] [INFO] Checking legal files in: activemq-blueprint-5.9-SNAPSHOT.jar [INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @ activemq-blueprint --- [INFO] [INFO] Installing https://builds.apache.org/job/ActiveMQ-Java7/ws/activemq-blueprint/target/activemq-blueprint-5.9-SNAPSHOT.jar to /home/jenkins/jenkins-slave/maven-repositories/1/org/apache/activemq/activemq-blueprint/5.9-SNAPSHOT/activemq-blueprint-5.9-SNAPSHOT.jar [INFO] Installing https://builds.apache.org/job/ActiveMQ-Java7/ws/activemq-blueprint/pom.xml to /home/jenkins/jenkins-slave/maven-repositories/1/org/apache/activemq/activemq-blueprint/5.9-SNAPSHOT/activemq-blueprint-5.9-SNAPSHOT.pom [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ activemq-blueprint --- [INFO] [INFO] --- maven-bundle-plugin:2.3.7:install (default-install) @ activemq-blueprint --- [INFO] Installing org/apache/activemq/activemq-blueprint/5.9-SNAPSHOT/activemq-blueprint-5.9-SNAPSHOT.jar [INFO] Writing OBR metadata [INFO] [INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ activemq-blueprint --- [INFO] [INFO] --- maven-bundle-plugin:2.3.7:cleanVersions (cleanVersions) @ activemq-blueprint --- Apr 26, 2013 5:36:51 PM hudson.maven.ExecutedMojo init WARNING: Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo [INFO] [INFO] META-INF already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO] META-INF/LICENSE already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] Building jar: https://builds.apache.org/job/ActiveMQ-Java7/ws/activemq-blueprint/target/activemq-blueprint-5.9-SNAPSHOT-sources.jar [INFO] --- maven-source-plugin:2.1.2:jar (default-cli) @ activemq-blueprint --- [INFO] META-INF already added, skipping [INFO] META-INF/NOTICE already added, skipping [INFO] META-INF/LICENSE already added, skipping [INFO] META-INF/DEPENDENCIES already added, skipping [INFO] [INFO] [INFO] Skipping ActiveMQ :: Web Demo [INFO] This project has been banned from the build due to previous failures. [INFO] [INFO] [INFO] [INFO] Skipping ActiveMQ :: Web Console [INFO] This project has been banned from the build due to previous failures. [INFO] [INFO] [INFO] [INFO] Skipping ActiveMQ :: Karaf Integration Tests [INFO] This project has been banned from the build due to previous failures. [INFO] [INFO] [INFO] [INFO] Skipping ActiveMQ :: Integration Test :: Spring 3.1 [INFO] This project has been banned from the build due to previous failures. [INFO] [INFO] [INFO] [INFO] Skipping ActiveMQ :: Assembly [INFO] This project has been banned from the build due to previous failures. [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] ActiveMQ .. SUCCESS
[jira] [Resolved] (AMQNET-410) jms.redeliveryPolicy.nonBlockingRedelivery=true not honored by NMS.ActiveMQ
[ https://issues.apache.org/jira/browse/AMQNET-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQNET-410. - Resolution: Fixed Fix Version/s: 1.6.0 Assignee: Timothy Bish (was: Jim Gomes) Fixed on trunk. jms.redeliveryPolicy.nonBlockingRedelivery=true not honored by NMS.ActiveMQ --- Key: AMQNET-410 URL: https://issues.apache.org/jira/browse/AMQNET-410 Project: ActiveMQ .Net Issue Type: New Feature Components: ActiveMQ Affects Versions: 1.5.6 Environment: Any Reporter: Rob Waite Assignee: Timothy Bish Priority: Minor Fix For: 1.6.0 Our system relies on redelivery. We realized that redelivery was performed by the client when we saw consumers appear to slow down or get stuck. With ActiveMQ 5.6.0, jms.redeliveryPolicy.nonBlockingRedelivery was added to allow the client side redelivery to move forward instead of fully handling a particular message's redelivery before moving to other messages. We realized that it was not implemented in NMS and ended up upgrading to ActiveMQ 5.7.0 which supports server-side redelivery using the Scheduler. Seems fairly minor and may take a larger effort to implement this, judging from what it would likely do. It also seems that server-side is preferable to client-side anyway so maybe the nonBlockingRedelivery option was just a stop-gap until server-side was implemented. Perhaps just logging a warning if it is used so it is easier to determine that it is not supported. -- 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] [Resolved] (AMQNET-433) Correctly rethrow exceptions without swallowing the stack trace
[
https://issues.apache.org/jira/browse/AMQNET-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQNET-433.
-
Resolution: Fixed
Fix Version/s: 1.6.0
I fixed a couple cases that I found but without real patch I won't waste to
much time combing the code for these.
Correctly rethrow exceptions without swallowing the stack trace
---
Key: AMQNET-433
URL: https://issues.apache.org/jira/browse/AMQNET-433
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Trivial
Fix For: 1.6.0
When looking through the code I saw a lot of the following code snippets:
try
{
}
catch(AnyException ex)
{
// do something
throw ex;
}
This WILL rewrite the stack trace and is not considered best practice. I
suggest you change the appropriate places in the code to:
try
{
}
catch(AnyException ex)
{
// do something
throw;
}
--
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] [Resolved] (AMQNET-431) Add Message Audit capabilites to allow for duplicate filtering on failover
[ https://issues.apache.org/jira/browse/AMQNET-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQNET-431. - Resolution: Fixed fixed on trunk Add Message Audit capabilites to allow for duplicate filtering on failover -- Key: AMQNET-431 URL: https://issues.apache.org/jira/browse/AMQNET-431 Project: ActiveMQ .Net Issue Type: Improvement Components: ActiveMQ Affects Versions: 1.5.6 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 1.6.0 For a fault tolerant transport is possible to get Message duplicates on connection restore. We can use a Message Audit with configurable window to filter out duplicates. -- 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] [Resolved] (AMQNET-430) Transaction commit/rollback through failover should throw TransactionRolledBackException if recovery redelivery dispatches to another consumer
[ https://issues.apache.org/jira/browse/AMQNET-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQNET-430. - Resolution: Fixed fixed on trunk Transaction commit/rollback through failover should throw TransactionRolledBackException if recovery redelivery dispatches to another consumer -- Key: AMQNET-430 URL: https://issues.apache.org/jira/browse/AMQNET-430 Project: ActiveMQ .Net Issue Type: Improvement Components: ActiveMQ Affects Versions: 1.5.6 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 1.6.0 Given an outstanding consumer transaction and failover transport recovery. On recovery, messages are redispatched by the broker once the connection, sessions and producers/consumers and transactions are replayed. Redispatch may not dispatch the same messages to the same consumers atm. In the case that a client transaction cannot be recreated it should fail with a TransactionRolledBackException. The failure indicates that the messages the session wants to ack have not again been redispatched so their receipt cannot be committed. The messages in question will have been redelivered to another consumer. Likewise in a rollback, in this case there is a warn message to the effect that the rolled back messages may not all be included in the rollback. It that they may not have been redispatched. The unordered redelivery semantics after a session rollback ensure that this error does not need to propagate up to the client. -- 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] [Resolved] (AMQNET-424) Creating consumer with invalid selector closes connection and other listeners.
[
https://issues.apache.org/jira/browse/AMQNET-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQNET-424.
-
Resolution: Fixed
Fix Version/s: 1.6.0
Test added on trunk, works as expected using that codebase.
Creating consumer with invalid selector closes connection and other listeners.
--
Key: AMQNET-424
URL: https://issues.apache.org/jira/browse/AMQNET-424
Project: ActiveMQ .Net
Issue Type: Bug
Components: NMS
Affects Versions: 1.5.5
Environment: .NET 2.0
Reporter: Matthew Good
Assignee: Jim Gomes
Fix For: 1.6.0
The following test illustrates the problem. After the exception trying to
create a consumer, the connection is closed which affects other unrelated
consumers and senders. The connection should not close and other consumers
should not be closed.
{noformat}
[Test]
public void TestBadSelector()
{
ConnectionFactory factory = new
ConnectionFactory(tcp://activemqhost:61616);
IConnection conn = factory.CreateConnection();
ISession listenerSession =
conn.CreateSession(AcknowledgementMode.AutoAcknowledge);
string listenerQueueName = ListenerTest;
IDestination listenerdestination =
listenerSession.GetQueue(listenerQueueName);
IMessageConsumer listenerconsumer =
listenerSession.CreateConsumer(listenerdestination);
listenerconsumer.Listener += new
MessageListener(consumer_Listener);
conn.Start();
ISession senderSession =
conn.CreateSession(AcknowledgementMode.AutoAcknowledge);
IDestination destination =
senderSession.GetQueue(listenerQueueName);
IMessageProducer producer =
senderSession.CreateProducer(destination);
ITextMessage goodMsg =
senderSession.CreateTextMessage(testGood);
producer.Send(goodMsg);
Thread.Sleep(1000);
Assert.AreEqual(1, _gotMessage);
try
{
ISession badListenerSession =
conn.CreateSession(AcknowledgementMode.AutoAcknowledge);
IMessageConsumer consumer2 =
badListenerSession.CreateConsumer(destination, badSelector;too);
Assert.Fail(Exception expected.);
}
catch(BrokerException e)
{
Console.WriteLine(e);
}
ITextMessage failMsg =
senderSession.CreateTextMessage(testFail);
producer.Send(failMsg);
Thread.Sleep(1000);
Assert.AreEqual(2, _gotMessage);
conn.Close();
}
private int _gotMessage = 0;
void consumer_Listener(IMessage message)
{
_gotMessage++;
}
{noformat}
--
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] (AMQNET-185) Add new provider implementation for IBM WebSphere MQ (formerly MQSeries)
[ https://issues.apache.org/jira/browse/AMQNET-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQNET-185: Fix Version/s: (was: 1.6.0) Add new provider implementation for IBM WebSphere MQ (formerly MQSeries) Key: AMQNET-185 URL: https://issues.apache.org/jira/browse/AMQNET-185 Project: ActiveMQ .Net Issue Type: New Feature Components: XMS Affects Versions: 1.2.0 Reporter: Jim Gomes Assignee: Jim Gomes Priority: Minor An additional provider implementation for interfacing with IBM WebSphere MQ would greatly enhance the cross-broker support of NMS. This new provider implementation can be implemented in a similar fashion to the TIBCO EMS provider. The new provider should be named Apache.NMS.XMS. The IBM WebSphere MQ .NET client is informally, but commonly, referred to as XMS .NET. The URI prefix for the provider should be XMS: in a similar way that EMS: prefix is used for TIBCO. A new Component module should be added to JIRA to track this provider. The Component module should be named XMS. -- 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] (AMQNET-333) Add new provider implementation for ZeroMQ
[ https://issues.apache.org/jira/browse/AMQNET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQNET-333: Fix Version/s: (was: 1.6.0) Add new provider implementation for ZeroMQ -- Key: AMQNET-333 URL: https://issues.apache.org/jira/browse/AMQNET-333 Project: ActiveMQ .Net Issue Type: New Feature Components: ZMQ Reporter: Jim Gomes Assignee: Jim Gomes Priority: Minor Labels: Provider, ZMQ, ZeroMQ Create a new provider implementation for interfacing with ZeroMQ. This new provider implementation can be implemented in a similar fashion to the MSMQ provider. The new provider should be named Apache.NMS.ZMQ. The URI prefix for the provider should be ZMQ: in a similar way that MSMQ: is used. A new Component module should be added to JIRA to track this provider. The Component module should be named ZMQ. This provider should be directly supported in the main NMS connection factory. -- 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] [Assigned] (AMQNET-338) TcpTransport.cs - Close() taking 30 seconds
[
https://issues.apache.org/jira/browse/AMQNET-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish reassigned AMQNET-338:
---
Assignee: (was: Timothy Bish)
TcpTransport.cs - Close() taking 30 seconds
---
Key: AMQNET-338
URL: https://issues.apache.org/jira/browse/AMQNET-338
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Affects Versions: 1.5.1, 1.5.6
Environment: Windows 7, .NET 2.0, Visual Studio 2008, Unity 3.4
Reporter: Eddie Fast
We've been noticing a random freeze on exit for 30 seconds. The frequency is
different per machine, but it happens about 10-30% of the time, sometimes
more. We've traced it down to TcpTransport.Close(), in this block:
{noformat}
if(null != readThread)
{
if(Thread.CurrentThread != readThread readThread.IsAlive)
{
if(!readThread.Join((int) MAX_THREAD_WAIT.TotalMilliseconds))
{
readThread.Abort();
}
}
readThread = null;
}
{noformat}
We're running this in the Unity game engine, which run C# script in a Mono
environment.
I understand that reproducing this on your end would be difficult, but I'm
reporting this in the hopes that I can gain some insight why this is
happening.
- What thread is this code waiting for?
- What would be some of the causes of the deadlock?
No messages are being sent or received. It's basically starting up and
closing down.
Our temporary workaround is to reduce this wait time from 30 seconds to 5
seconds, but I'd like to eventually find a cause.
Thanks
--
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] [Closed] (AMQCPP-477) Can't specify empty values in URIs
[
https://issues.apache.org/jira/browse/AMQCPP-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish closed AMQCPP-477.
---
Resolution: Won't Fix
Can't specify empty values in URIs
--
Key: AMQCPP-477
URL: https://issues.apache.org/jira/browse/AMQCPP-477
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: Transports
Affects Versions: 3.6.0
Reporter: Valeriy V. Argunov
Assignee: Timothy Bish
Can't specify empty values for wireFormat.topicPrefix, wireFormat.queuePrefix
etc in URIs because URISupport::parseQuery doesn't support this.
It can't parse such URI correctly:
tcp://10.0.0.1:333?wireFormat=stompwireFormat.topicPrefix=wireFormat.queuePrefix=
I've fixed this by the following code in URISupport::parseQuery:
int tokensCount = tokenizer.countTokens();
if (tokensCount != 2 tokensCount != 1) {
throw IllegalArgumentException(__FILE__, __LINE__,
URISupport::parseQuery - Invalid URI Option.);
}
--
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] [Closed] (AMQCPP-438) ssl doesnt match the hostname when there are multiple CN's
[ https://issues.apache.org/jira/browse/AMQCPP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQCPP-438. --- Resolution: Incomplete ssl doesnt match the hostname when there are multiple CN's -- Key: AMQCPP-438 URL: https://issues.apache.org/jira/browse/AMQCPP-438 Project: ActiveMQ C++ Client Issue Type: Bug Components: Decaf Affects Versions: 3.4.4 Environment: HPUX 11.31, but this is not likely important Reporter: Jeffrey B Assignee: Timothy Bish Labels: decaf, hostname, ssl Original Estimate: 48h Remaining Estimate: 48h If the ssl certificate on the server has its hostname in the cn field to be compatable, but it also has other cn's on the same entry, which openssl allows and we always use for all of our certificates, the file OpenSSLSocket.cpp finds that they do not match. It is only checking one item, so it is not iterating through different cn's. This sometimes returns the error that the servers certificate did not match the hostname, and sometimes it simply says that peer did not send his wireformat. This has no doesnt have an option to diable it like in NMS, at least not that I ahave found. -- 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] [Closed] (AMQCPP-216) Implement BlobMessage
[ https://issues.apache.org/jira/browse/AMQCPP-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQCPP-216. --- Resolution: Won't Fix Implement BlobMessage - Key: AMQCPP-216 URL: https://issues.apache.org/jira/browse/AMQCPP-216 Project: ActiveMQ C++ Client Issue Type: Sub-task Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 3.6.1 Original Estimate: 60h Remaining Estimate: 60h Implement BlobMessage in CMS and in the OpenWire code, this requires implementation of ActiveMQBlobMessage and its associated Marshaller. Add code to the OpenWireConnector to deal with it, and add code to the StompConnector to throw an unsupported operation exception. -- 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] [Closed] (AMQCPP-214) Support the ActiveMQBlobMessage and ActiveMQStreamMessage
[ https://issues.apache.org/jira/browse/AMQCPP-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQCPP-214. --- Resolution: Fixed StreamMessage was implemented. BlobMessage requires more work than its worth. Support the ActiveMQBlobMessage and ActiveMQStreamMessage - Key: AMQCPP-214 URL: https://issues.apache.org/jira/browse/AMQCPP-214 Project: ActiveMQ C++ Client Issue Type: Improvement Components: CMS Impl Affects Versions: 2.2.2 Environment: Windows-XP and Mac OS 10.5.5 (Leopard) Reporter: Sahayaraj Assignee: Timothy Bish Priority: Blocker In order to integrate the legacy C and C++ application with modern messaging architecture of ActiveMQ, the C++ client MUST support the Blob and Stream messages as supported in JMS. This support would add the value of interop between the java and legacy C++ systems in enterprise environment. Due to this unavailablity, we are unable to use ActiveMQ and forced us to go for other soultions. -- 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] [Resolved] (AMQ-4351) Deadlock when unsubscribing durable subscriber
[ https://issues.apache.org/jira/browse/AMQ-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-4351. --- Resolution: Fixed Fixed the stats issue on trunk Deadlock when unsubscribing durable subscriber -- Key: AMQ-4351 URL: https://issues.apache.org/jira/browse/AMQ-4351 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.7.0, 5.8.0 Environment: Setup: Active MQ 5.7.0 with master/slave using JDBC store Approx 3 - 5 concurrent durable subscribers Approx 5 messages / sec Reporter: Tim Lammens Assignee: Timothy Bish Labels: patch Fix For: 5.9.0 Attachments: ActiveMQUnsubscribeTest.java, dispatcher.patch We started using durable subscribers a week ago, and after the 4th durable subscriber unsubscribed (due to 1 hour inactivity), the system deadlocked. If the Durable Subscriber Cleanup Timer goes of at the wrong time, your entire server locks up. Setup: Active MQ 5.7.0 with master/slave using JDBC store Approx 3 - 5 concurrent durable subscribers Approx 5 messages / sec Active MQ checks every 1 minute for subscribers which have been offline for 1 hour. Locked threads: ActiveMQ Transport: tcp:///79.125.71.104:48082@8090: at org.apache.activemq.broker.region.Topic.doMessageSend(Topic.java:446) - waiting to lock 0xc6228480 (a org.apache.activemq.broker.region.Topic) at org.apache.activemq.broker.region.Topic.send(Topic.java:427) at org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:407) at org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:503) ActiveMQ Transport: tcp:///79.125.71.104:47590@8090: at org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:142) - waiting to lock 0xc66ba050 (a java.lang.Object) at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:243) at org.apache.activemq.broker.region.policy.StrictOrderDispatchPolicy.dispatch(StrictOrderDispatchPolicy.java:58) ActiveMQ Durable Subscriber Cleanup Timer: at org.apache.activemq.broker.region.Topic.deactivate(Topic.java:288) - waiting to lock 0xc6250670 (a java.util.concurrent.CopyOnWriteArrayList) at org.apache.activemq.broker.region.DurableTopicSubscription.deactivate(DurableTopicSubscription.java:184) - locked 0xc66ba060 (a java.lang.Object) - locked 0xc66ba050 (a java.lang.Object) at org.apache.activemq.broker.region.Topic.deleteSubscription(Topic.java:195) at org.apache.activemq.broker.region.TopicRegion.removeSubscription(TopicRegion.java:199) at org.apache.activemq.broker.region.TopicRegion.doCleanup(TopicRegion.java:99) I have attached a patch which fixes the problem. Since there is only one dispatch policy per Topic, synchronisation can happen on the DispatchPolicy instead of on the consumers object which causes the deadlock. -- 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] [Commented] (AMQNET-433) Correctly rethrow exceptions without swallowing the stack trace
[
https://issues.apache.org/jira/browse/AMQNET-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13643365#comment-13643365
]
Daniel Marbach commented on AMQNET-433:
---
Thank you! I must say I have some issues with your formulated answer. I don't
see why you consider improving the product as a waste of time. But certainly I
can also go through the code and do it if your time is so precious!
Correctly rethrow exceptions without swallowing the stack trace
---
Key: AMQNET-433
URL: https://issues.apache.org/jira/browse/AMQNET-433
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Trivial
Fix For: 1.6.0
When looking through the code I saw a lot of the following code snippets:
try
{
}
catch(AnyException ex)
{
// do something
throw ex;
}
This WILL rewrite the stack trace and is not considered best practice. I
suggest you change the appropriate places in the code to:
try
{
}
catch(AnyException ex)
{
// do something
throw;
}
--
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] [Commented] (AMQNET-433) Correctly rethrow exceptions without swallowing the stack trace
[
https://issues.apache.org/jira/browse/AMQNET-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13643394#comment-13643394
]
Jim Gomes commented on AMQNET-433:
--
Daniel, any additional patch contributions are welcome. Tim is working on some
areas of the code that can have a direct and substantial impact on the overall
performance, which makes them a high priority. This item is marked as Trivial
priority, so spending a lot of time searching for edge cases can definitely
seem like a waste of time. I did a quick scan through the code using some
regular expression searching, and it looks like Tim caught most (if not all) of
the areas. The pointer for best practices is appreciated, and all new code
should follow that format.
Correctly rethrow exceptions without swallowing the stack trace
---
Key: AMQNET-433
URL: https://issues.apache.org/jira/browse/AMQNET-433
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Daniel Marbach
Assignee: Jim Gomes
Priority: Trivial
Fix For: 1.6.0
When looking through the code I saw a lot of the following code snippets:
try
{
}
catch(AnyException ex)
{
// do something
throw ex;
}
This WILL rewrite the stack trace and is not considered best practice. I
suggest you change the appropriate places in the code to:
try
{
}
catch(AnyException ex)
{
// do something
throw;
}
--
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] [Created] (AMQCPP-478) Can't specify empty prefixes for the STOMP queues/topics
Valeriy V. Argunov created AMQCPP-478: - Summary: Can't specify empty prefixes for the STOMP queues/topics Key: AMQCPP-478 URL: https://issues.apache.org/jira/browse/AMQCPP-478 Project: ActiveMQ C++ Client Issue Type: Bug Components: Transports Affects Versions: 3.6.0 Reporter: Valeriy V. Argunov Assignee: Timothy Bish ActiveMQ-CPP uses prefixes for STOMP queues/topics (defaults are /topic/, /queue/ etc). STOMP specification (http://stomp.github.io/stomp-specification-1.2.html) says that queues/topics names are not required to contain any special prefixes: (from the SEND sample) This sends a message to a destination named /queue/a. Note that STOMP treats this destination as an opaque string and no delivery semantics are assumed by the name of a destination. But if the prefix is not required for me, I can't specify empty string (here was a bug https://issues.apache.org/jira/browse/AMQCPP-477). ActiveMQ-CPP doesn't allow to remove prefixes at all. -- 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
