[jira] [Commented] (AMQ-4693) Add kerberos [SASL] authentication for TCP connectors

2015-01-07 Thread Deepak (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267489#comment-14267489
 ] 

Deepak commented on AMQ-4693:
-

Hi Piotr,

Really excited to see this getting implemented! Is this new feature scheduled 
for the upcoming 5.11 release?

Thanks,
Deepak


 Add kerberos [SASL] authentication for TCP connectors
 -

 Key: AMQ-4693
 URL: https://issues.apache.org/jira/browse/AMQ-4693
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 5.8.0
 Environment: linux, solaris
Reporter: Bhanu
Priority: Minor
 Fix For: Unscheduled


 Hi,
 Can kerberos based authentication be added to ActiveMQ's TCP connectors.
 Thanks,
 Bhanu



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] activemq-6 pull request: Fix failing RA OutgoingConnectionTests

2015-01-07 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/activemq-6/pull/54


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Created] (ACTIVEMQ6-67) clean up configuration files

2015-01-07 Thread Andy Taylor (JIRA)
Andy Taylor created ACTIVEMQ6-67:


 Summary: clean up configuration files
 Key: ACTIVEMQ6-67
 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-67
 Project: Apache ActiveMQ 6
  Issue Type: Task
Reporter: Andy Taylor
Assignee: Andy Taylor
 Fix For: 6.0.0


The configuration files and parsers need consolidating to be cleaner, that is 
the main and configuration file should be combined and the securty bootstrap 
needs fixing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ACTIVEMQ6-66) implement configuration persistence

2015-01-07 Thread Andy Taylor (JIRA)
Andy Taylor created ACTIVEMQ6-66:


 Summary: implement configuration persistence
 Key: ACTIVEMQ6-66
 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-66
 Project: Apache ActiveMQ 6
  Issue Type: New Feature
Reporter: Andy Taylor
 Fix For: 6.1.0


We should reflect changes thru management such as adding destinations in the 
configuration file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMQ-5249) cursor got duplicate error after upgrade

2015-01-07 Thread Christian Tytgat (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267512#comment-14267512
 ] 

Christian Tytgat commented on AMQ-5249:
---

Same problem over here with 5.10.0. Happens on a topic for us:

2015-01-06 04:58:58,331 [10.29.0.4:46476] WARN  Topic  
- duplicate message from store 
ID:svlumipmq01.x.y.be-59515-1420515005092-3:975:-1:1:107, redirecting for dlq 
processing
2015-01-06 04:58:58,475 [10.29.0.4:46476] WARN  AbstractStoreCursor
- TopicStorePrefetch(m2mGatewayEventClient,m2mGatewayDurableEventSubscription) 
ID:svlumipweb01.x.y.be-47894-1419262838671-5:1:1:3 - 
org.apache.activemq.broker.region.cursors.TopicStorePrefetch@7ec6ea1b:m2mbox.IT-LUMI-9-MB-Herdi1.event.cogen.level/changed,batchResetNeeded=false,storeHasMessages=true,size=0,cacheEnabled=true,maxBatchSize:200,hasSpace:true
 - cursor got duplicate: 
ID:svlumipmq01.x.y.be-59515-1420515005092-3:975:-1:1:109, 4

 cursor got duplicate error after upgrade
 --

 Key: AMQ-5249
 URL: https://issues.apache.org/jira/browse/AMQ-5249
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.1, 5.10.0
Reporter: Rural Hunter

 I was using 5.9.0 and meet one problem so I tried to upgrade activemq. I 
 tried both 5.9.1 and 5.10.0 and encouterred a same problem. I saw messages 
 filled DLQ very quickly. I checked the clients both producer and consumer but 
 there was no error. I checked activemq log and found the log is full of these 
 warnings:
 2014-06-27 23:22:09,337 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com.cyyun.webmon.spider.update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:211.com-52399-1400732399425-1:1:235992:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,337 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:nbzjjf22805-34129-1403880308671-1:1:28:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,338 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com.x.update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:jxncxnj2-48598-1403856107346-1:1:6007:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,338 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:jxnc17-60227-1400730816361-1:1:149072:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,339 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:cyyun-46954-1403800808565-1:1:9765:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,339 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:ubuntu-55495-1403497638437-1:1:53086:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,340 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:cyyun-39030-1403880008363-1:1:70:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 The problem mostly happens right after activemq starts and sometimes happened 
 after activemq worked normally for a while.
 For now I have to roll back to 5.9.0 and the problem doesn't occure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (AMQ-5249) cursor got duplicate error after upgrade

2015-01-07 Thread Christian Tytgat (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267512#comment-14267512
 ] 

Christian Tytgat edited comment on AMQ-5249 at 1/7/15 10:57 AM:


Same problem over here with 5.10.0. Happens on a topic for us.
DLQ suddenly starts filling up with these messages:

2015-01-06 04:58:58,331 [10.29.0.4:46476] WARN  Topic  
- duplicate message from store 
ID:svlumipmq01.x.y.be-59515-1420515005092-3:975:-1:1:107, redirecting for dlq 
processing
2015-01-06 04:58:58,475 [10.29.0.4:46476] WARN  AbstractStoreCursor
- TopicStorePrefetch(m2mGatewayEventClient,m2mGatewayDurableEventSubscription) 
ID:svlumipweb01.x.y.be-47894-1419262838671-5:1:1:3 - 
org.apache.activemq.broker.region.cursors.TopicStorePrefetch@7ec6ea1b:m2mbox.IT-LUMI-9-MB-Herdi1.event.cogen.level/changed,batchResetNeeded=false,storeHasMessages=true,size=0,cacheEnabled=true,maxBatchSize:200,hasSpace:true
 - cursor got duplicate: 
ID:svlumipmq01.x.y.be-59515-1420515005092-3:975:-1:1:109, 4


was (Author: syberyan):
Same problem over here with 5.10.0. Happens on a topic for us:

2015-01-06 04:58:58,331 [10.29.0.4:46476] WARN  Topic  
- duplicate message from store 
ID:svlumipmq01.x.y.be-59515-1420515005092-3:975:-1:1:107, redirecting for dlq 
processing
2015-01-06 04:58:58,475 [10.29.0.4:46476] WARN  AbstractStoreCursor
- TopicStorePrefetch(m2mGatewayEventClient,m2mGatewayDurableEventSubscription) 
ID:svlumipweb01.x.y.be-47894-1419262838671-5:1:1:3 - 
org.apache.activemq.broker.region.cursors.TopicStorePrefetch@7ec6ea1b:m2mbox.IT-LUMI-9-MB-Herdi1.event.cogen.level/changed,batchResetNeeded=false,storeHasMessages=true,size=0,cacheEnabled=true,maxBatchSize:200,hasSpace:true
 - cursor got duplicate: 
ID:svlumipmq01.x.y.be-59515-1420515005092-3:975:-1:1:109, 4

 cursor got duplicate error after upgrade
 --

 Key: AMQ-5249
 URL: https://issues.apache.org/jira/browse/AMQ-5249
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.1, 5.10.0
Reporter: Rural Hunter

 I was using 5.9.0 and meet one problem so I tried to upgrade activemq. I 
 tried both 5.9.1 and 5.10.0 and encouterred a same problem. I saw messages 
 filled DLQ very quickly. I checked the clients both producer and consumer but 
 there was no error. I checked activemq log and found the log is full of these 
 warnings:
 2014-06-27 23:22:09,337 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com.cyyun.webmon.spider.update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:211.com-52399-1400732399425-1:1:235992:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,337 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:nbzjjf22805-34129-1403880308671-1:1:28:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,338 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com.x.update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:jxncxnj2-48598-1403856107346-1:1:6007:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,338 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:jxnc17-60227-1400730816361-1:1:149072:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,339 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:cyyun-46954-1403800808565-1:1:9765:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,339 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:ubuntu-55495-1403497638437-1:1:53086:1:1, 4 | 
 

[jira] [Commented] (AMQ-5249) cursor got duplicate error after upgrade

2015-01-07 Thread Gary Tully (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267563#comment-14267563
 ] 

Gary Tully commented on AMQ-5249:
-

@Christian - can you verify against 5.11-SNAPSHOT and if the problem persists 
try and build a simple reproducible test case? There are a bunch of tests 
around https://issues.apache.org/jira/browse/AMQ-5266 - peek at the activity 
tab. They may give inspiration.

 cursor got duplicate error after upgrade
 --

 Key: AMQ-5249
 URL: https://issues.apache.org/jira/browse/AMQ-5249
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.1, 5.10.0
Reporter: Rural Hunter

 I was using 5.9.0 and meet one problem so I tried to upgrade activemq. I 
 tried both 5.9.1 and 5.10.0 and encouterred a same problem. I saw messages 
 filled DLQ very quickly. I checked the clients both producer and consumer but 
 there was no error. I checked activemq log and found the log is full of these 
 warnings:
 2014-06-27 23:22:09,337 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com.cyyun.webmon.spider.update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:211.com-52399-1400732399425-1:1:235992:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,337 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:nbzjjf22805-34129-1403880308671-1:1:28:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,338 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com.x.update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:jxncxnj2-48598-1403856107346-1:1:6007:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,338 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:jxnc17-60227-1400730816361-1:1:149072:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,339 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:cyyun-46954-1403800808565-1:1:9765:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,339 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:ubuntu-55495-1403497638437-1:1:53086:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,340 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:cyyun-39030-1403880008363-1:1:70:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 The problem mostly happens right after activemq starts and sometimes happened 
 after activemq worked normally for a while.
 For now I have to roll back to 5.9.0 and the problem doesn't occure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (AMQ-5249) cursor got duplicate error after upgrade

2015-01-07 Thread Gary Tully (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267560#comment-14267560
 ] 

Gary Tully commented on AMQ-5249:
-

@Alex - there was a change of behaviour in 5.10 - to treat duplicates from the 
store a as problem - in the past, they were ignored by the cursor but could get 
redispatched on a restart or if the audit was exhausted, they would be 
redispatched as duplicates. in 5.10, if the page in logic from the store gets a 
duplicate if does the DLQ thing. So in some ways the difference between 5.9 and 
5.10 is expected.
What is unknown is what exact scenario causes the behaviour you see.
The trigger for the duplicates I tracked in the past was queue memory limit 
being reached with concurrent producers to the same destination, some of which 
were transactional. The interleaving could leave the cursor and store out of 
sync, such that when the cursor needed to page in from the store, it would use 
the wrong start point.
Your trigger seems to be related to the network bridge, which would introduce a 
non transacted client ack consumer and non transacted producer. Maybe you can 
simulate that at load without the bridge.
We need to determine the sequence of events that lead to the duplicate from the 
store to understand if it is legitimate or not and if not, to ensure we don't 
fill the DLQ in this case.

 cursor got duplicate error after upgrade
 --

 Key: AMQ-5249
 URL: https://issues.apache.org/jira/browse/AMQ-5249
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.1, 5.10.0
Reporter: Rural Hunter

 I was using 5.9.0 and meet one problem so I tried to upgrade activemq. I 
 tried both 5.9.1 and 5.10.0 and encouterred a same problem. I saw messages 
 filled DLQ very quickly. I checked the clients both producer and consumer but 
 there was no error. I checked activemq log and found the log is full of these 
 warnings:
 2014-06-27 23:22:09,337 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com.cyyun.webmon.spider.update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:211.com-52399-1400732399425-1:1:235992:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,337 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:nbzjjf22805-34129-1403880308671-1:1:28:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,338 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com.x.update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:jxncxnj2-48598-1403856107346-1:1:6007:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,338 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:jxnc17-60227-1400730816361-1:1:149072:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,339 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:cyyun-46954-1403800808565-1:1:9765:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,339 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:ubuntu-55495-1403497638437-1:1:53086:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,340 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:cyyun-39030-1403880008363-1:1:70:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 The problem mostly happens right after activemq 

[jira] [Updated] (AMQ-5508) Broker shutdown race condition leads to IllegalStateException: Timer already cancelled

2015-01-07 Thread Pero Atanasov (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMQ-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pero Atanasov updated AMQ-5508:
---
Description: 
This issue is seen on the surface with the broker failing to remove a consumer:

2014-12-19 10:45:42,586 | WARN  | Failed to remove consumer:
ID:hack-34927-1419007505006-2:3:0:0 |
org.apache.activemq.broker.TransportConnection | ActiveMQ
BrokerService[broker0] Task-6
java.lang.IllegalStateException: Timer already cancelled.

The full stack trace [STACK_TRACE] will be specified at the end of this report.

In this case, the race condition is exposed via some of the AdvisoryBroker code 
while trying to send an advisory message as part of the consumer/producer 
addition/removal code. Below are excerpts of code to explain this race 
condition:

activemq-broker/src/main/java/org/apache/activemq/advisory/AdvisoryBroker.java

Lines 605 - 637 [in fireAdvisory(...)]
if (getBrokerService().isStarted()) {
 // code to create and populate an advisory message
 next.send(producerExchange, advisoryMessage);
 // send will trigger destination creation/addition for this advisory 
message topic
}

However, it can easily happen that a client (consumer or producer) connects and 
is added _before_ getBrokerService().isStarted() is true, so in that case, the 
boolean expression in the block above will evaluate to false and hence skip the 
entire advisory message send and create/add destination process. At this point, 
the consumer/producer destination does not have its advisory message 
destination created. If no other consumer/producer connects on the same 
destination until the broker is shutting down, then no advisory destination 
pairing will be created for that consumer/producer. When the broker starts the 
shutdown process, the event that will trigger an advisory message will be the 
removal of a consumer/producer as part of the TransportConnection stopping 
process. The sequence of calls with line numbers can be seen within the 
STACK_TRACE.

Back to the above specified code block, when the broker is shutting down, the 
broker is still in the started state. Then, the boolean expression will 
evaluate to true and hence proceed with the advisory message creation/sending 
and destination creation/addition process. However, in the meantime, as part of 
the shutdown process, the Scheduler timer is being cancelled. Consider the 
following blocks of code:

activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java

Lines 756 - 761 [in stop()]
// for each service
 stopper.stop(service);

activemq-client/src/main/java/org/apache/activemq/util/ServiceSupport.java

Lines 67 - 84 [in stop()]
if (stopped.compareAndSet(false, true)) {
... some code ...
doStop(stopper);
... some code ...
}

activemq-client/src/main/java/org/apache/activemq/thread/Scheduler.java

Lines 69 - 71 [in doStop(...)]

if (this.timer != null) {
 this.timer.cancel();
}

At this point, the timer is cancelled. Now, back to the thread removing the 
consumer. From the STACK_TRACE, it can be seen that after many calls related to 
the advisory message destination creation, it ends up in AbstractRegion’s 
addDestination method.

activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java

Lines 132 - 145 [in addDestination(...)]
if (dest == null) {
 ... some code ...
 dest = createDestination(context, destination);
 ... some code ...
 dest.start();  
 ... some code ...
}

As it can be seen in the STACK_TRACE below, dest.start() call will trigger the 
need for a timer to be scheduled on the same timer that has already been 
cancelled. Some debug prints to confirm the race condition:

1. Fail to send advisory message for this consumer advisory topic because 
getBrokerService().isStarted() is false:

2015-01-06 08:49:26,215 | INFO  | patanasov: from AdvisoryBroker fireAdvisory 
would have sent advisoryMessage: topic 
ActiveMQ.Advisory.Consumer.Queue.2015.01.06-08.23.00.16401 | 
org.apache.activemq.advisory.AdvisoryBroker

2. Broker shutting down and cancelling timer:

2015-01-06 08:49:43,602 | INFO  | Apache ActiveMQ 5.10.0 (broker0, 
ID:host-40197-1420555763149-0:1) is shutting down | 
org.apache.activemq.broker.BrokerService | ActiveMQ ShutdownHook
2015-01-06 08:49:43,603 | INFO  | patanasov: from ServiceSupport calling 
doStop(stopper) | org.apache.activemq.util.ServiceSupport | ActiveMQ 
ShutdownHook
2015-01-06 08:49:43,603 | INFO  | patanasov: from Scheduler 
doStop(ServiceStopper stopper) calling this.timer.cancel(): timer 
java.util.Timer@7df33bb0 | org.apache.activemq.thread.Scheduler | ActiveMQ 
ShutdownHook

3. Adding destination and scheduling on cancelled timer (7df33bb0):

2015-01-06 08:49:43,767 | INFO  | patanasov: broker0 adding destination: 
qualified: topic://ActiveMQ.Advisory.Consumer.Queue.2015.01.06-08.23.00.16401, 
physical: 

[jira] [Commented] (AMQ-5249) cursor got duplicate error after upgrade

2015-01-07 Thread Anuj Khandelwal (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14268871#comment-14268871
 ] 

Anuj Khandelwal commented on AMQ-5249:
--

Hi,

We are using 5.10 broker. 
We saw this error messages. 
[20150107 15:01:52.282 EST (ActiveMQ Transport: 
tcp:///10.79.26.196:41859@61613) 
org.apache.activemq.broker.region.cursors.AbstractStoreCursor#recoverMess
age 103 WARN] - 
TopicStorePrefetch(cas_stuff_price_info_to_jsh,new_golden_price_message) 
ID:kepler47.com-49402-1420406276070-1:22507:-1:1 - org
.apache.activemq.broker.region.cursors.TopicStorePrefetch@7524aad9:pricing.goldenPriceFeed,batchResetNeeded=false,storeHasMessages=true,size=52586,cacheEn
abled=false,maxBatchSize:200,hasSpace:true - cursor got duplicate: 
ID:helium16.nyc-49994-1420473196066-5:6690:1:1:4257, 4 

From the source code of 
org.apache.activemq.broker.region.cursors.AbstractStoreCursor#recoverMess
age it looks like duplicates messages got stored in kahadb for same 
destination. The topic for which it happend has a durable subscriber. 
I want to understand in what cases kahadb stores duplicate messages ? Is this a 
bug? 


Thanks,
Anuj


 cursor got duplicate error after upgrade
 --

 Key: AMQ-5249
 URL: https://issues.apache.org/jira/browse/AMQ-5249
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.1, 5.10.0
Reporter: Rural Hunter

 I was using 5.9.0 and meet one problem so I tried to upgrade activemq. I 
 tried both 5.9.1 and 5.10.0 and encouterred a same problem. I saw messages 
 filled DLQ very quickly. I checked the clients both producer and consumer but 
 there was no error. I checked activemq log and found the log is full of these 
 warnings:
 2014-06-27 23:22:09,337 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com.cyyun.webmon.spider.update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:211.com-52399-1400732399425-1:1:235992:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,337 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:nbzjjf22805-34129-1403880308671-1:1:28:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,338 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com.x.update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:jxncxnj2-48598-1403856107346-1:1:6007:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,338 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:jxnc17-60227-1400730816361-1:1:149072:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,339 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:cyyun-46954-1403800808565-1:1:9765:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,339 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:ubuntu-55495-1403497638437-1:1:53086:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 2014-06-27 23:22:09,340 | WARN  | 
 org.apache.activemq.broker.region.cursors.QueueStorePrefetch@19117501:com..update,batchResetNeeded=false,storeHasMessages=true,size=211,cacheEnabled=true,maxBatchSize:200,hasSpace:true
  - cursor got duplicate: ID:cyyun-39030-1403880008363-1:1:70:1:1, 4 | 
 org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ 
 Broker[localhost] Scheduler
 The problem mostly happens right after activemq starts and sometimes happened 
 after activemq worked normally for a while.
 For now I have to roll back to 5.9.0 and the problem doesn't occure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: [VOTE] Release Apache.NMS API 1.7.0

2015-01-07 Thread jgenender
+1 (Non-binding)

Jeff



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/VOTE-Release-Apache-NMS-API-1-7-0-tp4689440p4689612.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


[GitHub] activemq-6 pull request: Remove jboss jms from examples

2015-01-07 Thread mtaylor
GitHub user mtaylor opened a pull request:

https://github.com/apache/activemq-6/pull/56

Remove jboss jms from examples



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mtaylor/activemq-6 removeJBossJMSFromExamples

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-6/pull/56.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #56


commit 63769aab917fb8296ace878b21de7dcbb8d1b638
Author: Martyn Taylor mtay...@redhat.com
Date:   2015-01-07T14:16:13Z

ActiveMQ6-65 JBoss JMS 2.0 spec jar - Geronimo

Swaps out all usages of the JBoss JMS 2.0 spec jar and replaces with the
Geronimo spec jar, in examples, docs and distribution.

commit 56d6a47a830cb0940275aefe0bf58659c07efbdb
Author: Martyn Taylor mtay...@redhat.com
Date:   2015-01-07T16:22:08Z

ActiveMQ6-65 JBoss JMS1.1 - Geronimo 2.0 spec jar

Replaces usage of the JBoss 1.1 API jar with the Geronimo JMS 2.0 jar.
The API is backwards compatibile.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


apache parent on activemq6/pom messing up Idea integration

2015-01-07 Thread Clebert Suconic
I'm seeing something weird...


if I keep the parent on the main pom for activemq6, Idea won't be able
to execute any tests within the Ide... the integration gets broken. I
only realized that after I needed to reimport my project... and I
could find the culprit by reverting recent commits.


Is there anyone also seeing this issue?


Re: [activemq6] XML or Not on Configurations

2015-01-07 Thread Clebert Suconic
We will just stick to XML...


We were looking at how we load configurations and I thought we would
be able to do something cool without burning resources...

We have a lot on our plate as is already... so I would rather do
something cool that would reflect on the broker runtime than spending
time on supporting multiple formats... so we gave up on this task :)

On Wed, Jan 7, 2015 at 3:32 PM, jgenender jgenen...@apache.org wrote:
 Yep, I agree with Chirino.  That said, there is nothing wrong with supporting
 multiple types.  but I would definitely ensure that XML is a first class
 citizen.

 Jeff



 --
 View this message in context: 
 http://activemq.2283324.n4.nabble.com/activemq6-XML-or-Not-on-Configurations-tp4688999p4689611.html
 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.



-- 
Clebert Suconic
http://community.jboss.org/people/clebert.suco...@jboss.com
http://clebertsuconic.blogspot.com


Re: apache parent on activemq6/pom messing up Idea integration

2015-01-07 Thread Clebert Suconic
If I remove these following lines it works fine:

   parent
  groupIdorg.apache/groupId
  artifactIdapache/artifactId
  version16/version
   /parent



I will probably remove it temporarily until we figure out why.

On Wed, Jan 7, 2015 at 3:59 PM, Clebert Suconic
clebert.suco...@gmail.com wrote:
 I'm seeing something weird...


 if I keep the parent on the main pom for activemq6, Idea won't be able
 to execute any tests within the Ide... the integration gets broken. I
 only realized that after I needed to reimport my project... and I
 could find the culprit by reverting recent commits.


 Is there anyone also seeing this issue?



-- 
Clebert Suconic
http://community.jboss.org/people/clebert.suco...@jboss.com
http://clebertsuconic.blogspot.com


[jira] [Commented] (AMQ-4693) Add kerberos [SASL] authentication for TCP connectors

2015-01-07 Thread Piotr Klimczak (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14268214#comment-14268214
 ] 

Piotr Klimczak commented on AMQ-4693:
-

Hi Deepak!

Unfortunately not. Nothing changed. The only progress you see is because I 
decided to spent one Saturday and two evenings of my private time and since 
beginning of the December had no more time for it.
I hope to find some time soon to finish it. I have started to craft unit tests 
with ApacheDS but it needs at least few more days work which I am struggle to 
find.
In general the answer is: it will be merged into current snapshot when it will 
be ready: meaning fully and clearly implemented, including tests and tests 
passing. But 'when it will be ready' is to be decided by committers.
Good information here is that this change should not affect any existing 
functionality so there should be no problem with regression (currently existing 
tests).

Thanks,
Peter

 Add kerberos [SASL] authentication for TCP connectors
 -

 Key: AMQ-4693
 URL: https://issues.apache.org/jira/browse/AMQ-4693
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 5.8.0
 Environment: linux, solaris
Reporter: Bhanu
Priority: Minor
 Fix For: Unscheduled


 Hi,
 Can kerberos based authentication be added to ActiveMQ's TCP connectors.
 Thanks,
 Bhanu



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: World Class ActiveMQ: Patch releases and 5.10.1

2015-01-07 Thread artnaseef
Thanks Hadrian.  To which comments of Dejan's are you referring?




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/World-Class-ActiveMQ-Patch-releases-and-5-10-1-tp4689606p4689620.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Re: World Class ActiveMQ: Patch releases and 5.10.1

2015-01-07 Thread Hadrian Zbarcea

Uhm, never mind, it was on a different list. I will take care of it.
Hadrian


On 01/07/2015 04:16 PM, artnaseef wrote:

Thanks Hadrian.  To which comments of Dejan's are you referring?




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/World-Class-ActiveMQ-Patch-releases-and-5-10-1-tp4689606p4689620.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.




Re: [activemq6] XML or Not on Configurations

2015-01-07 Thread Hiram Chirino
Hey.. I personally think that XML is must have these days even if it's
a little cumbersome.  Just about everyone understands it and then you
easily integrate into stuff like Spring with a namespace handler.  But
it would be nice if the same config object model could be parsed from
something a little more terse like Yaml or HOCON [1]

Having a BrokerBuilder like Jakub described would be nice, but I think
I would prefer if it was a BrokerConfigBuilder :)

The reason is that like in Apollo, it would be nice if a broker did
not just use the configuration model for initial startup, but also to
handle configuration updates.

BrokerConfig config = .. some kinda of config builder (dsl or xml parser) ..;
Broker broker = factory.createBroker(config);
broker.start();

BrokerConfig update = .. some kinda of config builder (dsl or xml parser) ..;
broker.update(update);


[1]: https://github.com/typesafehub/config#features-of-hocon

On Wed, Jan 7, 2015 at 11:13 AM, Jakub Korab
jakub.korab.li...@gmail.com wrote:
 Hi Clebert,

 I would like to chime in on the configuration front.

 ActiveMQ 5 currently supports 2 XML variants - Spring and Blueprint
 (which have the same features, but different namespaces). This makes it
 really easy to embed in existing applications, as well as leverage tools
 like Jasypt to support encryption in placeholders used for passwords.
 One of the strengths of this approach is that it is also really easy to
 drop in Camel code (also via its own XML namespace) inside the same
 configurations for things like content-based routing and bridging to
 other messaging providers (I have seen this inside numerous installations).

 This is not meant to dissuade from other approaches (except JSON, which
 doesn't support comments, ugh), but it needs to be there for feature parity.

 What would be awesome to see in ActiveMQ 6, which is currently a
 downside of ActiveMQ 5, is a separation of the configuration part of the
 broker from the runtime implementation. ActiveMQ 5 uses XBean on the
 implementation classes, which is a bit iffy. Separating the two would
 give users the possibility to pull up the config of a broker via the
 runtime itself. Camel does this by allowing you to dump routes out as
 their XML representation at JMX. There are a number of reasons that this
 would be awesome:

 * A small portion of users ( 5%) configure ActiveMQ programatically via
 their own wrapper process. You end up going down this path if you have
 complex networks of brokers, with lots of networkConnectors that each
 have a lot of rules about which destinations are included or excluded.
 For someone coming in to fix a problem, this means trawling through code
 to work out how a broker is configured. ActiveMQ 5 is also heavily
 embedded for testing purposes, anything that would make this easier to
 do would be warmly regarded by devs.
 * External tooling can only get information about a broker by what is
 available via JMX/advisory messages/statistics plugin. This is only a
 subset of the information that would be possible if it could pull up
 what the config was. E.g. Imagine a visual representation of a broker
 network that could take into consideration what paths a message could go
 down.

 A configuration DSL could take the form of something like the following
 (lovingly ripped straight from the Camel concepts):

 public class MyBroker extends BrokerBuilder {
   public void configure() {
 broker(myBroker).enableJmx(1099).persistent(false)
   .transportConnector(stomp://0.0.0.0:61614)
   .networkConnector(static:failover:(tcp://anotherHost))
 .staticallyIncludedDestinations()
   .queue(foo)
   .queue(bar)
 .excludedDestinations()
   .topic(ActiveMQ.Advisory.)
   .end();
   }
 }

 BrokerContext context = new BrokerContext(new MyBroker());
 context.start();
 // later...
 context.stop();

 IMO this would be huge step forward for ActiveMQ.

 Cheers,

 Jakub

 On 17/12/14 17:17, Clebert Suconic wrote:
 Since we are not moving on ActiveMQ6 we could things differently.

 I was wondering for configuration.. is there anything better these
 days for storing config?

 I heard today for two options... YAML, and JSON.


 So we would have Three options so far:

 YAML - it seems nice.. but I'm not sure about libraries
 JSON
 XML


 We could look at what was done on Apollo... but I *believe* it was XML as 
 well?

 Any experience for other newer projects?



 Clebert




-- 
Hiram Chirino
Engineering | Red Hat, Inc.
hchir...@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino


Re: [VOTE] Release Apache.NMS API 1.7.0

2015-01-07 Thread Hiram Chirino
+1

On Mon, Jan 5, 2015 at 9:59 AM, Timothy Bish tabish...@gmail.com wrote:
 Hello

 This is a call for a vote on the release of the Apache.NMS API v1.7.0.
 This package contains the API for the various Apache.NMS client along
 with utility classes and unit test cases against the abstract NMS API.

 This version of the API will be the basis for the next set of NMS client
 releases including Apache.NMS.ActiveMQ and Apache.NMS.Stomp etc.

 Changes in this version include:

 * Added IDisposable as a base of IDestination.
 * Added some improvements to the Unit tests framework.
 * Added some new provider names (AMQP and MQTT) to allow for future clients.

 The binaries and source bundles for the Release Candidate can be found
 here:
 [ http://people.apache.org/~tabish/nms-1.7.x ]

 The Wiki Page for this release is here:
 [ http://activemq.apache.org/nms/apachenms-api-v170.html ]

 Please cast your votes (the vote will be open for 72 hrs):

 [ ] +1 Release the source as Apache NMS API 1.7.0
 [ ] -1 (provide specific comments)

 Here's my +1

 Regards,
 Tim

 --
 Tim Bish
 Sr Software Engineer | RedHat Inc.
 tim.b...@redhat.com | www.redhat.com
 skype: tabish121 | twitter: @tabish121
 blog: http://timbish.blogspot.com/




-- 
Hiram Chirino
Engineering | Red Hat, Inc.
hchir...@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino


[jira] [Assigned] (AMQ-5300) Inifinite loop when attempting to replay levelDB logs to rebuild index

2015-01-07 Thread Gary Tully (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMQ-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Tully reassigned AMQ-5300:
---

Assignee: Gary Tully

 Inifinite loop when attempting to replay levelDB logs to rebuild index
 --

 Key: AMQ-5300
 URL: https://issues.apache.org/jira/browse/AMQ-5300
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-leveldb-store
Affects Versions: 5.9.1, 5.10.0
 Environment: Linux
Reporter: Vu Le
Assignee: Gary Tully

 While searching for a workaround for issue AMQ-5284, I came across this issue.
 To work around the serialization issue (AMQ-5284), I deleted the index 
 snapshots from the LevelDB datastore. This will replay the logs to regenerate 
 the index. However, if a log rotation has already occurred, you will get an 
 infinite loop upon restart.
 Here are the steps to reproduce what I am seeing:
 Configure ActiveMQ 5.10.0 to use a LevelDB data store with the log size of 
 about 1MB.
 {code}
 persistenceAdapter
 levelDB directory=${activemq.data}/leveldb logSize=100 /
 /persistenceAdapter
 {code}
 Then I started up the broker and published 10,000 persistent messages to a 
 queue, causing the log files to rotate (twice in my case). I see the 
 following files in the data store folder:
 {code}
 -rw-rw-r--. 1 user users 171 Jul 30 11:15 .log
 -rw-rw-r--. 1 user users 109 Jul 30 11:16 000f4287.log
 drwxrwxr-x. 2 user users4096 Jul 30 11:16 001e84d0.index
 -rw-rw-r--. 1 user users 100 Jul 30 11:17 001e84d0.log
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 dirty.index
 -rw-rw-r--. 1 user users   0 Jul 30 11:11 lock
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 plist.index
 -rw-rw-r--. 1 user users  24 Jul 30 11:11 store-version.txt
 {code}
 I then consume 5,000 messages, which causes the first log to be deleted since 
 it is no longer being referenced. I see the following log statements:
 {code}
 2014-07-30 11:29:14,960 | DEBUG | Log no longer referenced: 0 | 
 org.apache.activemq.leveldb.LevelDBClient | Thread-2
 2014-07-30 11:29:14,967 | DEBUG | Deleting log at 0 | 
 org.apache.activemq.leveldb.LevelDBClient | Thread-2
 {code}
 And I see the remaining files in the data store folder (notice the 
 .log is gone):
 {code}
 -rw-rw-r--. 1 user users 109 Jul 30 11:16 000f4287.log
 -rw-rw-r--. 1 user users 111 Jul 30 11:29 001e84d0.log
 drwxrwxr-x. 2 user users4096 Jul 30 11:29 002dc71b.index
 -rw-rw-r--. 1 user users 100 Jul 30 11:29 002dc71b.log
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 dirty.index
 -rw-rw-r--. 1 user users   0 Jul 30 11:11 lock
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 plist.index
 -rw-rw-r--. 1 user users  24 Jul 30 11:11 store-version.txt
 {code}
 At this point, I shut down the broker and here is the listing of what's left 
 in the data store:
 {code}
 -rw-rw-r--. 1 user users 109 Jul 30 11:16 000f4287.log
 -rw-rw-r--. 1 user users 111 Jul 30 11:29 001e84d0.log
 -rw-rw-r--. 1 user users 100 Jul 30 11:29 002dc71b.log
 drwxrwxr-x. 2 user users4096 Jul 30 11:36 00301737.index
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 dirty.index
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 plist.index
 -rw-rw-r--. 1 user users  24 Jul 30 11:11 store-version.txt
 {code}
 I then delete the index folder within the data store (in my case 
 00301737.index). I am doing this to force a replay of the logs to 
 regenerate the index (due to the serialization issue I ran into).
 And finally, this is the message I am getting once I start the broker back up 
 (infinite loop of this same message, and I have to shut down the broker):
 {code}
 2014-07-30 11:40:27,415 | WARN  | No reader available for position: 0, 
 log_infos: 
 {171=LogInfo(/home/user/apache-activemq-5.10.0/data/leveldb/000f4287.log,171,109),
  
 280=LogInfo(/home/user/apache-activemq-5.10.0/data/leveldb/001e84d0.log,280,111),
  
 391=LogInfo(/home/user/apache-activemq-5.10.0/data/leveldb/002dc71b.log,391,0)}
  | org.apache.activemq.leveldb.RecordLog | main
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (AMQ-5300) Inifinite loop when attempting to replay levelDB logs to rebuild index

2015-01-07 Thread Gary Tully (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMQ-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Tully resolved AMQ-5300.
-
   Resolution: Fixed
Fix Version/s: 5.11.0

fix and test in http://git-wip-us.apache.org/repos/asf/activemq/commit/b54606b1

 Inifinite loop when attempting to replay levelDB logs to rebuild index
 --

 Key: AMQ-5300
 URL: https://issues.apache.org/jira/browse/AMQ-5300
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-leveldb-store
Affects Versions: 5.9.1, 5.10.0
 Environment: Linux
Reporter: Vu Le
Assignee: Gary Tully
 Fix For: 5.11.0


 While searching for a workaround for issue AMQ-5284, I came across this issue.
 To work around the serialization issue (AMQ-5284), I deleted the index 
 snapshots from the LevelDB datastore. This will replay the logs to regenerate 
 the index. However, if a log rotation has already occurred, you will get an 
 infinite loop upon restart.
 Here are the steps to reproduce what I am seeing:
 Configure ActiveMQ 5.10.0 to use a LevelDB data store with the log size of 
 about 1MB.
 {code}
 persistenceAdapter
 levelDB directory=${activemq.data}/leveldb logSize=100 /
 /persistenceAdapter
 {code}
 Then I started up the broker and published 10,000 persistent messages to a 
 queue, causing the log files to rotate (twice in my case). I see the 
 following files in the data store folder:
 {code}
 -rw-rw-r--. 1 user users 171 Jul 30 11:15 .log
 -rw-rw-r--. 1 user users 109 Jul 30 11:16 000f4287.log
 drwxrwxr-x. 2 user users4096 Jul 30 11:16 001e84d0.index
 -rw-rw-r--. 1 user users 100 Jul 30 11:17 001e84d0.log
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 dirty.index
 -rw-rw-r--. 1 user users   0 Jul 30 11:11 lock
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 plist.index
 -rw-rw-r--. 1 user users  24 Jul 30 11:11 store-version.txt
 {code}
 I then consume 5,000 messages, which causes the first log to be deleted since 
 it is no longer being referenced. I see the following log statements:
 {code}
 2014-07-30 11:29:14,960 | DEBUG | Log no longer referenced: 0 | 
 org.apache.activemq.leveldb.LevelDBClient | Thread-2
 2014-07-30 11:29:14,967 | DEBUG | Deleting log at 0 | 
 org.apache.activemq.leveldb.LevelDBClient | Thread-2
 {code}
 And I see the remaining files in the data store folder (notice the 
 .log is gone):
 {code}
 -rw-rw-r--. 1 user users 109 Jul 30 11:16 000f4287.log
 -rw-rw-r--. 1 user users 111 Jul 30 11:29 001e84d0.log
 drwxrwxr-x. 2 user users4096 Jul 30 11:29 002dc71b.index
 -rw-rw-r--. 1 user users 100 Jul 30 11:29 002dc71b.log
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 dirty.index
 -rw-rw-r--. 1 user users   0 Jul 30 11:11 lock
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 plist.index
 -rw-rw-r--. 1 user users  24 Jul 30 11:11 store-version.txt
 {code}
 At this point, I shut down the broker and here is the listing of what's left 
 in the data store:
 {code}
 -rw-rw-r--. 1 user users 109 Jul 30 11:16 000f4287.log
 -rw-rw-r--. 1 user users 111 Jul 30 11:29 001e84d0.log
 -rw-rw-r--. 1 user users 100 Jul 30 11:29 002dc71b.log
 drwxrwxr-x. 2 user users4096 Jul 30 11:36 00301737.index
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 dirty.index
 drwxrwxr-x. 2 user users4096 Jul 30 11:11 plist.index
 -rw-rw-r--. 1 user users  24 Jul 30 11:11 store-version.txt
 {code}
 I then delete the index folder within the data store (in my case 
 00301737.index). I am doing this to force a replay of the logs to 
 regenerate the index (due to the serialization issue I ran into).
 And finally, this is the message I am getting once I start the broker back up 
 (infinite loop of this same message, and I have to shut down the broker):
 {code}
 2014-07-30 11:40:27,415 | WARN  | No reader available for position: 0, 
 log_infos: 
 {171=LogInfo(/home/user/apache-activemq-5.10.0/data/leveldb/000f4287.log,171,109),
  
 280=LogInfo(/home/user/apache-activemq-5.10.0/data/leveldb/001e84d0.log,280,111),
  
 391=LogInfo(/home/user/apache-activemq-5.10.0/data/leveldb/002dc71b.log,391,0)}
  | org.apache.activemq.leveldb.RecordLog | main
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: [activemq6] XML or Not on Configurations

2015-01-07 Thread Jakub Korab
Hi Clebert,

I would like to chime in on the configuration front.

ActiveMQ 5 currently supports 2 XML variants - Spring and Blueprint
(which have the same features, but different namespaces). This makes it
really easy to embed in existing applications, as well as leverage tools
like Jasypt to support encryption in placeholders used for passwords.
One of the strengths of this approach is that it is also really easy to
drop in Camel code (also via its own XML namespace) inside the same
configurations for things like content-based routing and bridging to
other messaging providers (I have seen this inside numerous installations).

This is not meant to dissuade from other approaches (except JSON, which
doesn't support comments, ugh), but it needs to be there for feature parity.

What would be awesome to see in ActiveMQ 6, which is currently a
downside of ActiveMQ 5, is a separation of the configuration part of the
broker from the runtime implementation. ActiveMQ 5 uses XBean on the
implementation classes, which is a bit iffy. Separating the two would
give users the possibility to pull up the config of a broker via the
runtime itself. Camel does this by allowing you to dump routes out as
their XML representation at JMX. There are a number of reasons that this
would be awesome:

* A small portion of users ( 5%) configure ActiveMQ programatically via
their own wrapper process. You end up going down this path if you have
complex networks of brokers, with lots of networkConnectors that each
have a lot of rules about which destinations are included or excluded.
For someone coming in to fix a problem, this means trawling through code
to work out how a broker is configured. ActiveMQ 5 is also heavily
embedded for testing purposes, anything that would make this easier to
do would be warmly regarded by devs.
* External tooling can only get information about a broker by what is
available via JMX/advisory messages/statistics plugin. This is only a
subset of the information that would be possible if it could pull up
what the config was. E.g. Imagine a visual representation of a broker
network that could take into consideration what paths a message could go
down.

A configuration DSL could take the form of something like the following
(lovingly ripped straight from the Camel concepts):

public class MyBroker extends BrokerBuilder {
  public void configure() {
broker(myBroker).enableJmx(1099).persistent(false)
  .transportConnector(stomp://0.0.0.0:61614)
  .networkConnector(static:failover:(tcp://anotherHost))
.staticallyIncludedDestinations()
  .queue(foo)
  .queue(bar)
.excludedDestinations()
  .topic(ActiveMQ.Advisory.)
  .end();
  }
}

BrokerContext context = new BrokerContext(new MyBroker());
context.start();
// later...
context.stop();

IMO this would be huge step forward for ActiveMQ.

Cheers,

Jakub

On 17/12/14 17:17, Clebert Suconic wrote:
 Since we are not moving on ActiveMQ6 we could things differently.

 I was wondering for configuration.. is there anything better these
 days for storing config?

 I heard today for two options... YAML, and JSON.


 So we would have Three options so far:

 YAML - it seems nice.. but I'm not sure about libraries
 JSON
 XML


 We could look at what was done on Apollo... but I *believe* it was XML as 
 well?

 Any experience for other newer projects?



 Clebert



[GitHub] activemq-6 pull request: Apache Rat- Exclude target dirs and intel...

2015-01-07 Thread mtaylor
GitHub user mtaylor opened a pull request:

https://github.com/apache/activemq-6/pull/55

Apache Rat- Exclude target dirs and intellij files



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mtaylor/activemq-6 exclude_files_licence_check

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-6/pull/55.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #55


commit 3557fbd1af09cd6a9f195e17832b5deb1aca9131
Author: Martyn Taylor mtay...@redhat.com
Date:   2015-01-07T16:25:58Z

Apache Rat- Exclude target dirs and intellij files




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


World Class ActiveMQ: Patch releases and 5.10.1

2015-01-07 Thread artnaseef
ActiveMQ is a world-class application that is widely-used in critical
business functions across many industries.  It is looked up to as a leader
in the application integration and messaging spaces and it is our mission to
continue to lead and drive this space.

At this time, we are coming up short.  ActiveMQ releases are infrequent
leaving users experiencing issues - which may have been fixed months before
- to wait for resolution or take more extreme measures.  Users expect rapid
development and timely releases, and rightfully so.

Toward this end, I am pursuing monthly patch releases.  I gladly offer to
perform the releases myself starting with the imminent 5.10.1 release
started by Hardian.  Thank you Hadrian.




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/World-Class-ActiveMQ-Patch-releases-and-5-10-1-tp4689606.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


[jira] [Commented] (AMQ-4097) Broker-to-Broker Reconnect fails wrongly due to duplicate name

2015-01-07 Thread JIRA

[ 
https://issues.apache.org/jira/browse/AMQ-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14268016#comment-14268016
 ] 

Rodrigo dos Santos Côrtes commented on AMQ-4097:


Hi Ron,

What about the allowLinkStealing option (recently added) for the 
TransportConnector? Don't you think it can solve this problem?

Thanks.

 Broker-to-Broker Reconnect fails wrongly due to duplicate name
 --

 Key: AMQ-4097
 URL: https://issues.apache.org/jira/browse/AMQ-4097
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.7.0
 Environment: A central broker to which a lot (50+) of external 
 brokers connect with a duplex bridge. A special routing/firewall is used 
 which can affect timing but not order of TCP packets. This can be simulated 
 by using socat.
 Actually we are using 5.7-SNAPSHOT of 2012-08-31.
Reporter: Ron Koerner

 The situation is as follows:
 - an external broker A connects
 - time passes
 - a lot of external brokers disconnect including A
 - A reconnects (as well as all the other external brokers)
 - wrong message about duplicate name is generated
 In the log it looks like this:
 {code}
 2012-10-08 17:11:19,835 INFO  .DemandForwardingBridgeSupport - Network 
 connection between vm://c04ptec#278 and 
 tcp:///127.0.0.1:54191(cbox-56BU902442) has been established. 
 [StartLocalBridge: localBroker=vm://c04ptec#278]
 ...
 ... a lot more of the following with different ports
 2012-10-08 17:37:01,958 WARN  .DemandForwardingBridgeSupport - Network 
 connection between vm://c04ptec#278 and tcp:///127.0.0.1:54191 shutdown due 
 to a remote error: java.io.EOFException [ActiveMQ NIO Worker 193]
 ... more of these
 2012-10-08 17:37:03,438 INFO  emq.broker.TransportConnection - Started 
 responder end of duplex bridge cBox 56BU902442 to cBox 
 Proxy@ID:P013SPWMK1WN-39320-1349704902319-0:1 [ActiveMQ NIO Worker 215]
 ...
 2012-10-08 17:37:03,922 WARN  emq.broker.TransportConnection - Failed to add 
 Connection ID:c04ptec-51799-1349706422094-242:2, reason: 
 javax.jms.InvalidClientIDException: Broker: c04ptec - Client: cBox 56BU902442 
 to cBox Proxy_cbox-56BU902442_inbound_c04ptec already connected from 
 vm://c04ptec#278 [StartLocalBridge: localBroker=vm://c04ptec#478]
 2012-10-08 17:37:03,923 INFO  .DemandForwardingBridgeSupport - Network 
 connection between vm://c04ptec#478 and tcp:///127.0.0.1:56529 shutdown due 
 to a local error: javax.jms.InvalidClientIDException: Broker: c04ptec - 
 Client: cBox 56BU902442 to cBox Proxy_cbox-56BU902442_inbound_c04ptec already 
 connected from vm://c04ptec#278 [StartLocalBridge: 
 localBroker=vm://c04ptec#478]
 ...
 2012-10-08 17:37:04,036 INFO  .DemandForwardingBridgeSupport - c04ptec bridge 
 to cbox-56BU902442 stopped [ActiveMQ Task-182]
 ...
 2012-10-08 17:37:06,540 INFO  emq.broker.TransportConnection - Started 
 responder end of duplex bridge cBox 56BU902442 to cBox 
 Proxy@ID:P013SPWMK1WN-39320-1349704902319-0:1 [ActiveMQ NIO Worker 207]
 ...
 2012-10-08 17:37:06,548 WARN  emq.broker.TransportConnection - Failed to add 
 Connection ID:c04ptec-51799-1349706422094-292:1, reason: 
 javax.jms.InvalidClientIDException: Broker: c04ptec - Client: cBox 56BU902442 
 to cBox Proxy_cbox-56BU902442_inbound_c04ptec already connected from 
 vm://c04ptec#278 [StartLocalBridge: localBroker=vm://c04ptec#570]
 2012-10-08 17:37:06,548 INFO  .DemandForwardingBridgeSupport - Network 
 connection between vm://c04ptec#570 and tcp:///127.0.0.1:56576 shutdown due 
 to a local error: javax.jms.InvalidClientIDException: Broker: c04ptec - 
 Client: cBox 56BU902442 to cBox Proxy_cbox-56BU902442_inbound_c04ptec already 
 connected from vm://c04ptec#278 [StartLocalBridge: 
 localBroker=vm://c04ptec#570]
 ...
 2012-10-08 17:37:06,559 INFO  .DemandForwardingBridgeSupport - c04ptec bridge 
 to cbox-56BU902442 stopped [ActiveMQ Task-204]
 ...
 2012-10-08 17:37:24,417 INFO  .DemandForwardingBridgeSupport - c04ptec bridge 
 to cbox-56BU902442 stopped [ActiveMQ Task-73]
 ...
 2012-10-08 17:37:25,103 INFO  emq.broker.TransportConnection - Started 
 responder end of duplex bridge cBox 56BU902442 to cBox 
 Proxy@ID:P013SPWMK1WN-39320-1349704902319-0:1 [ActiveMQ NIO Worker 268]
 ...
 2012-10-08 17:37:29,110 INFO  .DemandForwardingBridgeSupport - Network 
 connection between vm://c04ptec#594 and 
 tcp:///127.0.0.1:56656(cbox-56BU902442) has been established. 
 [StartLocalBridge: localBroker=vm://c04ptec#594]
 ...
 2012-10-08 17:37:59,669 WARN  .DemandForwardingBridgeSupport - Network 
 connection between vm://c04ptec#594 and 
 tcp:///127.0.0.1:56656(cbox-56BU902442) was interrupted during establishment. 
 [StartLocalBridge: localBroker=vm://c04ptec#594]
 ...
 2012-10-08 17:38:09,005 INFO  .DemandForwardingBridgeSupport - c04ptec bridge 
 to cbox-56BU902442 stopped [ActiveMQ 

Re: [VOTE] Release Apache.NMS API 1.7.0

2015-01-07 Thread Chuck Rolke
+1 (nonbinding)



Re: World Class ActiveMQ: Patch releases and 5.10.1

2015-01-07 Thread Hadrian Zbarcea

Art,

Fully agree. I expressed similar feelings in other thread.
Thanks for volunteering, let me know if I can help out. Best is to start 
with Dejan's comments.


Cheers,
Hadrian

On 01/07/2015 01:10 PM, artnaseef wrote:

ActiveMQ is a world-class application that is widely-used in critical
business functions across many industries.  It is looked up to as a leader
in the application integration and messaging spaces and it is our mission to
continue to lead and drive this space.

At this time, we are coming up short.  ActiveMQ releases are infrequent
leaving users experiencing issues - which may have been fixed months before
- to wait for resolution or take more extreme measures.  Users expect rapid
development and timely releases, and rightfully so.

Toward this end, I am pursuing monthly patch releases.  I gladly offer to
perform the releases myself starting with the imminent 5.10.1 release
started by Hardian.  Thank you Hadrian.




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/World-Class-ActiveMQ-Patch-releases-and-5-10-1-tp4689606.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.




Jenkins build became unstable: ActiveMQ » ActiveMQ :: AMQP #1584

2015-01-07 Thread Apache Jenkins Server
See 
https://builds.apache.org/job/ActiveMQ/org.apache.activemq$activemq-amqp/1584/



[jira] [Commented] (AMQ-5249) cursor got duplicate error after upgrade

2015-01-07 Thread Christian Tytgat (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267631#comment-14267631
 ] 

Christian Tytgat commented on AMQ-5249:
---

@Gary: I managed to reproduce the problem with a local instance, maybe the 
following info might give you some insights.

- started a client publishing messages to a topic continuously 
- our camel application was consuming from that topic
- while everything was running ok, I restarted activemq
- the duplicate message warnings started appearing immediately after startup
- even after killing the client, the broker seems to be 'stuck' in this state. 
Each single message will trigger the warning from then on.
- not all 'duplicate' messages end up in the DLQ. Seems to be timing related. 
(Looks like the faster the machine, the less messages end up in the DLQ.)  
- reproducable both with an oracle and a kahadb store

I connected a debugger and noticed that the handling thread enters 
AbstractStoreCursor.recoverMessage() twice, hence the duplicate warning because 
it already exists in the audit map. PrefetchSubscription.add() seems to trigger 
the 2 executions, once through pending.addMessageLast(node) and once through 
dispatchPending()...

Here are 2 stacktraces showing how it enters that method.
{code}

ActiveMQ Transport: tcp:///0:0:0:0:0:0:0:1:56106@1883@10055 daemon, prio=5, in 
group 'main', status: 'RUNNING'
  at 
org.apache.activemq.broker.region.cursors.AbstractStoreCursor.recoverMessage(AbstractStoreCursor.java:90)
  at 
org.apache.activemq.broker.region.cursors.TopicStorePrefetch.recoverMessage(TopicStorePrefetch.java:77)
  at 
org.apache.activemq.broker.region.cursors.AbstractStoreCursor.addMessageLast(AbstractStoreCursor.java:194)
  at 
org.apache.activemq.broker.region.cursors.StoreDurableSubscriberCursor.addMessageLast(StoreDurableSubscriberCursor.java:198)
  at 
org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:159)
  at 
org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:272)
  at 
org.apache.activemq.broker.region.policy.SimpleDispatchPolicy.dispatch(SimpleDispatchPolicy.java:48)
  at org.apache.activemq.broker.region.Topic.dispatch(Topic.java:717)
  at 
org.apache.activemq.broker.region.Topic.doMessageSend(Topic.java:510)
  at org.apache.activemq.broker.region.Topic.send(Topic.java:441)
  at 
org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:424)
  at 
org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:445)
  at 
org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:297)
  at org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:147)
  at 
org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:96)
  at 
org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:307)
  at org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:147)
  at 
org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:152)
  at 
org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:496)
  at 
org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:756)
  at 
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:294)
  at 
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:148)
  at 
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:45)
  at 
org.apache.activemq.transport.mqtt.MQTTInactivityMonitor.onCommand(MQTTInactivityMonitor.java:123)
  at 
org.apache.activemq.transport.mqtt.MQTTTransportFilter.sendToActiveMQ(MQTTTransportFilter.java:91)
  at 
org.apache.activemq.transport.mqtt.MQTTProtocolConverter.sendToActiveMQ(MQTTProtocolConverter.java:132)
  at 
org.apache.activemq.transport.mqtt.MQTTProtocolConverter.onMQTTPublish(MQTTProtocolConverter.java:566)
  at 
org.apache.activemq.transport.mqtt.MQTTProtocolConverter.onMQTTCommand(MQTTProtocolConverter.java:175)
  at 
org.apache.activemq.transport.mqtt.MQTTTransportFilter.onCommand(MQTTTransportFilter.java:79)
  at 
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
  at 
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:214)
  at 
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:196)
  at java.lang.Thread.run(Thread.java:745)
{code}


{code}

ActiveMQ Transport: tcp:///0:0:0:0:0:0:0:1:56106@1883@10055 daemon, prio=5, in 
group 'main', status: 'RUNNING'
 blocks ActiveMQ Transport: tcp:///127.0.0.1:56056@61616@9345