[jira] [Closed] (AMQ-6437) Old KahaDB log files not removed

[Timothy Bish (JIRA)]

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

Timothy Bish closed AMQ-6437.
-
Resolution: Invalid

Please use the mailing list for help with debugging issues.  

> Old KahaDB log files not removed
> 
>
> Key: AMQ-6437
> URL: https://issues.apache.org/jira/browse/AMQ-6437
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.13.0, 5.14.0
>Reporter: Steve Hill
>
> Old messages get stuck in KahaDB and never get cleaned up.  The oldest file 
> is from July 14, 2016.  Since then we have restarted ActiveMQ multiple times, 
> and all servers in environment. This is occuring in our test environment as 
> well as production environment.  Currently the only solution is to stop 
> ActiveMQ and remove the KahaDB log directory.
> Follows is the log of a checkpoint from today 9/21/2016
>  2016-09-21 13:27:34,313 [eckpoint Worker] DEBUG MessageDatabase  
>   - Checkpoint started.
>  2016-09-21 13:27:34,322 [eckpoint Worker] TRACE MessageDatabase  
>   - Last update: 1438:1243461, full gc candidates set: [674, 691, 699, 705, 
> 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 939, 940, 
> 949, 960, 968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 1093, 
> , 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 1284, 
> 1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 1308, 
> 1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 
> 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 1368, 
> 1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 1387, 
> 1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 
> 1401, 1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 
> 1414, 1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 1426, 1427, 
> 1428, 1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1438, 1439]
>  2016-09-21 13:27:34,322 [eckpoint Worker] TRACE MessageDatabase  
>   - gc candidates after producerSequenceIdTrackerLocation:1438, [674, 691, 
> 699, 705, 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 
> 939, 940, 949, 960, 968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 
> 1083, 1093, , 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 
> 1283, 1284, 1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 
> 1307, 1308, 1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 
> 1321, 1322, 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 
> 1367, 1368, 1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 
> 1380, 1387, 1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 
> 1399, 1400, 1401, 1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 
> 1412, 1413, 1414, 1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 
> 1426, 1427, 1428, 1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1439]
>  2016-09-21 13:27:34,323 [eckpoint Worker] TRACE MessageDatabase  
>   - gc candidates after ackMessageFileMapLocation:1438, [674, 691, 699, 705, 
> 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 939, 940, 
> 949, 960, 968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 1093, 
> , 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 1284, 
> 1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 1308, 
> 1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 
> 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 1368, 
> 1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 1387, 
> 1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 
> 1401, 1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 
> 1414, 1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 1426, 1427, 
> 1428, 1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1439]
>  2016-09-21 13:27:34,324 [eckpoint Worker] TRACE MessageDatabase  
>   - gc candidates after tx range:[980:15980880, 980:15980880], [674, 691, 
> 699, 705, 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 
> 939, 940, 949, 960, 968, 975, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 
> 1093, , 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 
> 1284, 1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 
> 1308, 1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 
> 1322, 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 
> 1368, 1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 
> 1387, 1388, 1389, 1390, 1391, 1392, 1393, 

[jira] [Commented] (ARTEMIS-738) Improving Transaction support on AMQP

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511623#comment-15511623
 ] 

ASF GitHub Bot commented on ARTEMIS-738:


Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/782


> Improving Transaction support on AMQP
> -
>
> Key: ARTEMIS-738
> URL: https://issues.apache.org/jira/browse/ARTEMIS-738
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: clebert suconic
> Fix For: 1.5.0
>
>




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

[jira] [Commented] (AMQ-6437) Old KahaDB log files not removed

[Steve Hill (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511617#comment-15511617
 ] 

Steve Hill commented on AMQ-6437:
-

Timothy:

Thank you for updating this ticket.  For some reason I did not get the 
responses, will follow up with our email team and see what the problem might 
be.  We did previously have messages on the DLQ but they were all moved.  When 
I posted there are no messages showing in the activemq console.  and as 
mentioned all systems have been restarted multiiple times.  I enabled the debug 
ports on activemq if i can look at anything to get to the bottom of it.

Thanks!
Steve.

> Old KahaDB log files not removed
> 
>
> Key: AMQ-6437
> URL: https://issues.apache.org/jira/browse/AMQ-6437
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.13.0, 5.14.0
>Reporter: Steve Hill
>
> Old messages get stuck in KahaDB and never get cleaned up.  The oldest file 
> is from July 14, 2016.  Since then we have restarted ActiveMQ multiple times, 
> and all servers in environment. This is occuring in our test environment as 
> well as production environment.  Currently the only solution is to stop 
> ActiveMQ and remove the KahaDB log directory.
> Follows is the log of a checkpoint from today 9/21/2016
>  2016-09-21 13:27:34,313 [eckpoint Worker] DEBUG MessageDatabase  
>   - Checkpoint started.
>  2016-09-21 13:27:34,322 [eckpoint Worker] TRACE MessageDatabase  
>   - Last update: 1438:1243461, full gc candidates set: [674, 691, 699, 705, 
> 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 939, 940, 
> 949, 960, 968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 1093, 
> , 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 1284, 
> 1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 1308, 
> 1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 
> 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 1368, 
> 1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 1387, 
> 1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 
> 1401, 1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 
> 1414, 1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 1426, 1427, 
> 1428, 1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1438, 1439]
>  2016-09-21 13:27:34,322 [eckpoint Worker] TRACE MessageDatabase  
>   - gc candidates after producerSequenceIdTrackerLocation:1438, [674, 691, 
> 699, 705, 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 
> 939, 940, 949, 960, 968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 
> 1083, 1093, , 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 
> 1283, 1284, 1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 
> 1307, 1308, 1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 
> 1321, 1322, 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 
> 1367, 1368, 1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 
> 1380, 1387, 1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 
> 1399, 1400, 1401, 1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 
> 1412, 1413, 1414, 1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 
> 1426, 1427, 1428, 1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1439]
>  2016-09-21 13:27:34,323 [eckpoint Worker] TRACE MessageDatabase  
>   - gc candidates after ackMessageFileMapLocation:1438, [674, 691, 699, 705, 
> 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 939, 940, 
> 949, 960, 968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 1093, 
> , 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 1284, 
> 1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 1308, 
> 1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 
> 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 1368, 
> 1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 1387, 
> 1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 
> 1401, 1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 
> 1414, 1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 1426, 1427, 
> 1428, 1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1439]
>  2016-09-21 13:27:34,324 [eckpoint Worker] TRACE MessageDatabase  
>   - gc candidates after tx range:[980:15980880, 980:15980880], [674, 691, 
> 699, 705, 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 
> 939, 940, 949, 960, 968, 975, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 
> 1093, , 1126, 

[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

[Quinn Stevenson (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511598#comment-15511598
 ] 

Quinn Stevenson commented on ARTEMIS-737:
-

@clebertsucconic - yes, I'm getting the notifications.  Sorry - I was away from 
my desk for a while.

I tried to answer all the questions so far.  I see I missed the checkstyle 
checks - I'll have to get those errors fixed and update the PR.

> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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

[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

[Quinn Stevenson (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511595#comment-15511595
 ] 

Quinn Stevenson commented on ARTEMIS-737:
-

Yes - these rules are primarily targeted for end-users.  The idea was to make 
it as simple as possible to write unit tests for applications that need a 
messaging back-end.

> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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

[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

[Quinn Stevenson (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511591#comment-15511591
 ] 

Quinn Stevenson commented on ARTEMIS-737:
-

I don't necessarily think this approach is "better" than the existing test 
suite.  I was looking for something simple for end-user testing - similar to 
what I contributed to ActiveMQ (activemq-junit) a while back.

I don't have any expectations on whether or not these rules would help with 
testing Artemis itself - I'm not familiar enough with Artemis yet to have an 
informed opinion on that.  So I wouldn't expect internal Artemis tests to use 
these Rules -but they could if it made sense.

And No - I didn't have any plans on converting the existing test cases.  Again, 
if the Rule looks like it would make sense for those tests, I'd be happy to try 
and convert some of them.  But these Rules were primarily targeted and 
end-users (like me) who want to easily test their applications (like my Camel 
routes).

> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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

[jira] [Comment Edited] (ARTEMIS-737) Add JUnit Rules

[Quinn Stevenson (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511580#comment-15511580
 ] 

Quinn Stevenson edited comment on ARTEMIS-737 at 9/22/16 12:02 AM:
---

I'd be happy to put something in the user docs - but I don't know how you go 
about that :-).  I've edited the wiki pages for ActiveMQ and Camel before, but 
I don't know the documentation process for Artemis.

There are some simple examples in the unit tests.  Granted, they don't do much, 
but they definitely show how to setup the rules to support a test.


was (Author: hqstevenson):
I'd be happy to put something in the user docs - but I don't know how you go 
about that :-).  I've edited the wiki pages for ActiveMQ and Camel before, but 
I don't know the documentation process for Artemis.


> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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

[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

[Quinn Stevenson (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511580#comment-15511580
 ] 

Quinn Stevenson commented on ARTEMIS-737:
-

I'd be happy to put something in the user docs - but I don't know how you go 
about that :-).  I've edited the wiki pages for ActiveMQ and Camel before, but 
I don't know the documentation process for Artemis.


> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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

[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511422#comment-15511422
 ] 

ASF GitHub Bot commented on ARTEMIS-737:


Github user johnament commented on the issue:

https://github.com/apache/activemq-artemis/pull/789
  
@clebertsuconic agreed.  This does look like an awesome idea though for end 
users trying to test with messaging systems.


> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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

[jira] [Commented] (AMQ-6438) AMQP: Investigate possible performance improvements in the Message transformers

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511375#comment-15511375
 ] 

ASF subversion and git services commented on AMQ-6438:
--

Commit d4c7cce7d733df9fcdcd0daec4ce64fb3844ce64 in activemq's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=d4c7cce ]

https://issues.apache.org/jira/browse/AMQ-6438

Makes some improvements to the profiling test for the transformers. 

> AMQP: Investigate possible performance improvements in the Message 
> transformers
> ---
>
> Key: AMQ-6438
> URL: https://issues.apache.org/jira/browse/AMQ-6438
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.14.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.15.0
>
>
> The JMS Message Transformer seem to have several areas where performance can 
> be improved.  



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

[jira] [Created] (AMQ-6438) AMQP: Investigate possible performance improvements in the Message transformers

[Timothy Bish (JIRA)]

Timothy Bish created AMQ-6438:
-

 Summary: AMQP: Investigate possible performance improvements in 
the Message transformers
 Key: AMQ-6438
 URL: https://issues.apache.org/jira/browse/AMQ-6438
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.14.0
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 5.15.0


The JMS Message Transformer seem to have several areas where performance can be 
improved.  



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

[jira] [Commented] (AMQ-6437) Old KahaDB log files not removed

[Timothy Bish (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511361#comment-15511361
 ] 

Timothy Bish commented on AMQ-6437:
---

I believe you've already asked about this on the mailing list and been given 
several explanations on how and why this happens.  The typical case is that you 
have old messages sitting around on a Queue such as in a DLQ that end up being 
spread across the journal logs which prevent clean up.  If this is normal 
operating conditions for you then looking into mKahaDB would be a good 
solution, all of which was brought up on the mailing list thread.

> Old KahaDB log files not removed
> 
>
> Key: AMQ-6437
> URL: https://issues.apache.org/jira/browse/AMQ-6437
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.13.0, 5.14.0
>Reporter: Steve Hill
>
> Old messages get stuck in KahaDB and never get cleaned up.  The oldest file 
> is from July 14, 2016.  Since then we have restarted ActiveMQ multiple times, 
> and all servers in environment. This is occuring in our test environment as 
> well as production environment.  Currently the only solution is to stop 
> ActiveMQ and remove the KahaDB log directory.
> Follows is the log of a checkpoint from today 9/21/2016
>  2016-09-21 13:27:34,313 [eckpoint Worker] DEBUG MessageDatabase  
>   - Checkpoint started.
>  2016-09-21 13:27:34,322 [eckpoint Worker] TRACE MessageDatabase  
>   - Last update: 1438:1243461, full gc candidates set: [674, 691, 699, 705, 
> 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 939, 940, 
> 949, 960, 968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 1093, 
> , 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 1284, 
> 1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 1308, 
> 1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 
> 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 1368, 
> 1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 1387, 
> 1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 
> 1401, 1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 
> 1414, 1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 1426, 1427, 
> 1428, 1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1438, 1439]
>  2016-09-21 13:27:34,322 [eckpoint Worker] TRACE MessageDatabase  
>   - gc candidates after producerSequenceIdTrackerLocation:1438, [674, 691, 
> 699, 705, 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 
> 939, 940, 949, 960, 968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 
> 1083, 1093, , 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 
> 1283, 1284, 1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 
> 1307, 1308, 1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 
> 1321, 1322, 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 
> 1367, 1368, 1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 
> 1380, 1387, 1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 
> 1399, 1400, 1401, 1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 
> 1412, 1413, 1414, 1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 
> 1426, 1427, 1428, 1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1439]
>  2016-09-21 13:27:34,323 [eckpoint Worker] TRACE MessageDatabase  
>   - gc candidates after ackMessageFileMapLocation:1438, [674, 691, 699, 705, 
> 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 939, 940, 
> 949, 960, 968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 1093, 
> , 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 1284, 
> 1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 1308, 
> 1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 
> 1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 1368, 
> 1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 1387, 
> 1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 
> 1401, 1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 
> 1414, 1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 1426, 1427, 
> 1428, 1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1439]
>  2016-09-21 13:27:34,324 [eckpoint Worker] TRACE MessageDatabase  
>   - gc candidates after tx range:[980:15980880, 980:15980880], [674, 691, 
> 699, 705, 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 
> 939, 940, 949, 960, 968, 975, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 
> 1093, , 1126, 1137, 1138, 1155, 1167, 

[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511350#comment-15511350
 ] 

ASF GitHub Bot commented on ARTEMIS-737:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/789
  
I guess this is intended for users to use on their tests?

What was the intention, to refactor Artemis' testsuite, or to provide rules 
for users running their own tests?



> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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

[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511334#comment-15511334
 ] 

ASF GitHub Bot commented on ARTEMIS-737:


Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/789
  
I think it would also be good to have a clear explanation of why this 
approach is superior to the approach already adopted in the test-suite.

Additional questions:

1. What expectation is there to adopt this style of testing?  Should all 
new tests use this style?
2. Do you plan on converting all existing test-cases to this style?  If 
not, I'd be concerned with having 2 methods of doing the same thing introducing 
confusion.


> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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

[jira] [Commented] (ARTEMIS-743) Default the queue address to the queue name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511321#comment-15511321
 ] 

ASF GitHub Bot commented on ARTEMIS-743:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/787
  
just to let you guys know.. I ran the testsuite and only got a few known 
failures. looks good.


> Default the queue address to the queue name
> ---
>
> Key: ARTEMIS-743
> URL: https://issues.apache.org/jira/browse/ARTEMIS-743
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Francesco Nigro
>  Labels: features
>
> In many instances, users will want the queue name and address to be the same. 
> The latter could default to the queue name, and then it would be safe to omit 
> the address in the queue config.



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

[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511304#comment-15511304
 ] 

ASF GitHub Bot commented on ARTEMIS-737:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/789
  
This looks a great idea...


however.. there's no docs on how to use this. it would warrant a chapter on 
the user-docs..

and maybe examples on how to run tests with it?


> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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

[jira] [Commented] (ARTEMIS-737) Add JUnit Rules

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511288#comment-15511288
 ] 

ASF GitHub Bot commented on ARTEMIS-737:


GitHub user hqstevenson opened a pull request:

https://github.com/apache/activemq-artemis/pull/789

ARTEMIS-737 - added JUnit rules for Artemis servers and clients



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

$ git pull https://github.com/hqstevenson/activemq-artemis ARTEMIS-737

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

https://github.com/apache/activemq-artemis/pull/789.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 #789


commit c79d00b78c23f55af88c94507c0a5ec8325cf893
Author: Quinn Stevenson 
Date:   2016-09-21T21:45:05Z

ARTEMIS-737 - added JUnit rules for Artemis servers and clients




> Add JUnit Rules
> ---
>
> Key: ARTEMIS-737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-737
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Quinn Stevenson
>Priority: Minor
>
> ActiveMQ includes a JUnit rule for embedding a JMS Broker.  This would be a 
> nice feature to have for Artemis as well, along with the JUnit rules for JMS 
> Clients.



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

[jira] [Commented] (ARTEMIS-740) Auto-reload diverts from broker.xml

[clebert suconic (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511188#comment-15511188
 ] 

clebert suconic commented on ARTEMIS-740:
-

[~scop] thanks!

> Auto-reload diverts from broker.xml
> ---
>
> Key: ARTEMIS-740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-740
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Ville Skyttä
> Fix For: 1.5.0
>
>
> Automatic reloading of diverts from broker.xml would be equally useful as for 
> addresses, security, and jms destinations, see ARTEMIS-601



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

[jira] [Closed] (ARTEMIS-740) Auto-reload diverts from broker.xml

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-740.
---
Resolution: Fixed

> Auto-reload diverts from broker.xml
> ---
>
> Key: ARTEMIS-740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-740
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Ville Skyttä
> Fix For: 1.5.0
>
>
> Automatic reloading of diverts from broker.xml would be equally useful as for 
> addresses, security, and jms destinations, see ARTEMIS-601



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

[jira] [Commented] (ARTEMIS-740) Auto-reload diverts from broker.xml

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511182#comment-15511182
 ] 

ASF subversion and git services commented on ARTEMIS-740:
-

Commit 589adbccacb34aa0ff9c933ff5b240bb71dc5463 in activemq-artemis's branch 
refs/heads/master from [~scop]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=589adbc ]

ARTEMIS-740 Auto-reload diverts from broker.xml


> Auto-reload diverts from broker.xml
> ---
>
> Key: ARTEMIS-740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-740
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Ville Skyttä
> Fix For: 1.5.0
>
>
> Automatic reloading of diverts from broker.xml would be equally useful as for 
> addresses, security, and jms destinations, see ARTEMIS-601



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

[jira] [Commented] (ARTEMIS-740) Auto-reload diverts from broker.xml

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511184#comment-15511184
 ] 

ASF GitHub Bot commented on ARTEMIS-740:


Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/784


> Auto-reload diverts from broker.xml
> ---
>
> Key: ARTEMIS-740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-740
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Ville Skyttä
> Fix For: 1.5.0
>
>
> Automatic reloading of diverts from broker.xml would be equally useful as for 
> addresses, security, and jms destinations, see ARTEMIS-601



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

[jira] [Updated] (ARTEMIS-745) Messages sent to a jms topi address are not expiring in temporary queue created via core API

[Ruben Cala (JIRA)]

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

Ruben Cala updated ARTEMIS-745:
---
Description: 
I am publishing messages to a topic address (jms.topic.).  I set the 
message expiration to be 2 seconds (publishing via core api).  I have two 
consumers, one using core api, one using generic stomp protocol.  The core api 
creates a temporary queue to receive the messages from the  address.  The stomp 
consumer relies on the auto-generated temporary queue mechanism provided by the 
broker.  To investigate slow consumer scenarios, both consumers are not 
acknowledging the messages.
In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute 
count rises, while the MessageCount stays constant with the MessagesAdded count 
(low number around 5 usually).
For the core api consumer, however, its queue MessagesAcknowledged attribute 
count stays at 0, while its MessageCount attribute increases with the 
MessagesAdded number.  This eventually causes the broker to run out of memory.

  was:
I am publishing messages to a topic address (jms.topic.). I set the 
message expiration to be 2 seconds (publisher via core api).  I have two 
consumers, one using core api, one using generic stomp protocol.  The core api 
creates a temporary queue to receive the messages from the the address.  The 
stomp consumer relies on the auto-generated temporary queue mechanism provided 
by the broker.  Both consumers are not acknowledging the messages.
In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute 
count rises with the MessagesAdded count, while the MessageCount stays constant 
at 2.
For the core api consumer, however, its queue MessagesAcknowledged attribute 
count stays at 0, while its MessageCount attribute matches the MessagesAdded 
number.
I see in artemis.log repeated null pointer exception messages for the core 
consumer:


> Messages sent to a jms topi address are not expiring in temporary queue 
> created via core API
> 
>
> Key: ARTEMIS-745
> URL: https://issues.apache.org/jira/browse/ARTEMIS-745
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
> Environment: Redhat Linux 6.2
>Reporter: Ruben Cala
>
> I am publishing messages to a topic address (jms.topic.).  I set the 
> message expiration to be 2 seconds (publishing via core api).  I have two 
> consumers, one using core api, one using generic stomp protocol.  The core 
> api creates a temporary queue to receive the messages from the  address.  The 
> stomp consumer relies on the auto-generated temporary queue mechanism 
> provided by the broker.  To investigate slow consumer scenarios, both 
> consumers are not acknowledging the messages.
> In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute 
> count rises, while the MessageCount stays constant with the MessagesAdded 
> count (low number around 5 usually).
> For the core api consumer, however, its queue MessagesAcknowledged attribute 
> count stays at 0, while its MessageCount attribute increases with the 
> MessagesAdded number.  This eventually causes the broker to run out of memory.



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

[jira] [Commented] (ARTEMIS-738) Improving Transaction support on AMQP

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510993#comment-15510993
 ] 

ASF GitHub Bot commented on ARTEMIS-738:


Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/782
  
@mtaylor / @gemmellr  This is now ready to merge... 

(tagging you guys since you both commented on this PR before)


> Improving Transaction support on AMQP
> -
>
> Key: ARTEMIS-738
> URL: https://issues.apache.org/jira/browse/ARTEMIS-738
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: clebert suconic
> Fix For: 1.5.0
>
>




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

[jira] [Commented] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510765#comment-15510765
 ] 

ASF GitHub Bot commented on ARTEMIS-732:


Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/788#discussion_r79900532
  
--- Diff: 
artemis-cli/src/main/resources/org/apache/activemq/artemis/cli/commands/bin/artemis
 ---
@@ -105,6 +105,16 @@ if [ -z "$LOG_MANAGER" ] ; then
   LOG_MANAGER="$ARTEMIS_HOME/lib/${logmanager}"
 fi
 
+# determine which native library version to load
+LIBRARY_PATH="-Djava.library.path=\"$ARTEMIS_HOME/bin/lib"
+if [ "$(uname -m)" = "x86_64" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-x86_64\""
+elif [ "$(uname -m)" = "i686" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-i686\""
+else
+  LIBRARY_PATH=""
--- End diff --

if ./create can't find libaio, the configuration will be set to NIO and aio 
won't be used.


> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Assignee: Justin Bertram
>Priority: Blocker
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to only have the proper  32-bit or 64-bit. All that 
> is necessary is to modify the library path to be platform specific, and the 
> error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Commented] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510763#comment-15510763
 ] 

ASF GitHub Bot commented on ARTEMIS-732:


Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/788#discussion_r79900443
  
--- Diff: 
artemis-cli/src/main/resources/org/apache/activemq/artemis/cli/commands/bin/artemis
 ---
@@ -105,6 +105,16 @@ if [ -z "$LOG_MANAGER" ] ; then
   LOG_MANAGER="$ARTEMIS_HOME/lib/${logmanager}"
 fi
 
+# determine which native library version to load
+LIBRARY_PATH="-Djava.library.path=\"$ARTEMIS_HOME/bin/lib"
+if [ "$(uname -m)" = "x86_64" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-x86_64\""
+elif [ "$(uname -m)" = "i686" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-i686\""
+else
+  LIBRARY_PATH=""
--- End diff --

Actually no, the ./artemis create will use the libaio to determine the 
journal type (if it can't load libaio, it won't use it).. and it will also 
perform a sync on the system to calculate the timed-buffer values.


> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Assignee: Justin Bertram
>Priority: Blocker
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to only have the proper  32-bit or 64-bit. All that 
> is necessary is to modify the library path to be platform specific, and the 
> error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Commented] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510754#comment-15510754
 ] 

ASF GitHub Bot commented on ARTEMIS-732:


Github user jbertram commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/788#discussion_r79899679
  
--- Diff: 
artemis-cli/src/main/resources/org/apache/activemq/artemis/cli/commands/bin/artemis
 ---
@@ -105,6 +105,16 @@ if [ -z "$LOG_MANAGER" ] ; then
   LOG_MANAGER="$ARTEMIS_HOME/lib/${logmanager}"
 fi
 
+# determine which native library version to load
+LIBRARY_PATH="-Djava.library.path=\"$ARTEMIS_HOME/bin/lib"
+if [ "$(uname -m)" = "x86_64" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-x86_64\""
+elif [ "$(uname -m)" = "i686" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-i686\""
+else
+  LIBRARY_PATH=""
--- End diff --

We only need to set the library path for the actual broker instance, right? 
 We don't need to set it for the other CLI commands.


> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Assignee: Justin Bertram
>Priority: Blocker
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to only have the proper  32-bit or 64-bit. All that 
> is necessary is to modify the library path to be platform specific, and the 
> error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Commented] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510746#comment-15510746
 ] 

ASF GitHub Bot commented on ARTEMIS-732:


Github user jbertram commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/788#discussion_r79899253
  
--- Diff: 
artemis-cli/src/main/resources/org/apache/activemq/artemis/cli/commands/bin/artemis
 ---
@@ -105,6 +105,16 @@ if [ -z "$LOG_MANAGER" ] ; then
   LOG_MANAGER="$ARTEMIS_HOME/lib/${logmanager}"
 fi
 
+# determine which native library version to load
+LIBRARY_PATH="-Djava.library.path=\"$ARTEMIS_HOME/bin/lib"
+if [ "$(uname -m)" = "x86_64" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-x86_64\""
+elif [ "$(uname -m)" = "i686" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-i686\""
+else
+  LIBRARY_PATH=""
--- End diff --

If the user is on a Linux system then I would expect `uname -a` to return 
`x86_64` or `i686`.  My thought here was to avoid setting the library path for 
systems where `uname -a` returned something other than what we support 
out-of-the-box.


> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Assignee: Justin Bertram
>Priority: Blocker
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to only have the proper  32-bit or 64-bit. All that 
> is necessary is to modify the library path to be platform specific, and the 
> error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Commented] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510726#comment-15510726
 ] 

ASF GitHub Bot commented on ARTEMIS-732:


Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/788#discussion_r79898185
  
--- Diff: 
artemis-cli/src/main/resources/org/apache/activemq/artemis/cli/commands/bin/artemis
 ---
@@ -105,6 +105,16 @@ if [ -z "$LOG_MANAGER" ] ; then
   LOG_MANAGER="$ARTEMIS_HOME/lib/${logmanager}"
 fi
 
+# determine which native library version to load
+LIBRARY_PATH="-Djava.library.path=\"$ARTEMIS_HOME/bin/lib"
+if [ "$(uname -m)" = "x86_64" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-x86_64\""
+elif [ "$(uname -m)" = "i686" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-i686\""
+else
+  LIBRARY_PATH=""
--- End diff --

There are two artemis I think.. one for the distribution, one for the 
instance.


> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Assignee: Justin Bertram
>Priority: Blocker
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to only have the proper  32-bit or 64-bit. All that 
> is necessary is to modify the library path to be platform specific, and the 
> error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Commented] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510724#comment-15510724
 ] 

ASF GitHub Bot commented on ARTEMIS-732:


Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/788#discussion_r79898051
  
--- Diff: 
artemis-cli/src/main/resources/org/apache/activemq/artemis/cli/commands/bin/artemis
 ---
@@ -105,6 +105,16 @@ if [ -z "$LOG_MANAGER" ] ; then
   LOG_MANAGER="$ARTEMIS_HOME/lib/${logmanager}"
 fi
 
+# determine which native library version to load
+LIBRARY_PATH="-Djava.library.path=\"$ARTEMIS_HOME/bin/lib"
+if [ "$(uname -m)" = "x86_64" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-x86_64\""
+elif [ "$(uname -m)" = "i686" ]; then
+  LIBRARY_PATH="$LIBRARY_PATH/linux-i686\""
+else
+  LIBRARY_PATH=""
--- End diff --

We need something here in case of else.

Say you are on a Linux for a new System, and the user compiled the library 
himself. on that case you need something on the LD_LIBRARY_PATH to work.

Maybe we could have the x86_64 here?


> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Assignee: Justin Bertram
>Priority: Blocker
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to only have the proper  32-bit or 64-bit. All that 
> is necessary is to modify the library path to be platform specific, and the 
> error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Updated] (ARTEMIS-745) Messages sent to a jms topi address are not expiring in temporary queue created via core API

[Ruben Cala (JIRA)]

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

Ruben Cala updated ARTEMIS-745:
---
Description: 
I am publishing messages to a topic address (jms.topic.). I set the 
message expiration to be 2 seconds (publisher via core api).  I have two 
consumers, one using core api, one using generic stomp protocol.  The core api 
creates a temporary queue to receive the messages from the the address.  The 
stomp consumer relies on the auto-generated temporary queue mechanism provided 
by the broker.  Both consumers are not acknowledging the messages.
In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute 
count rises with the MessagesAdded count, while the MessageCount stays constant 
at 2.
For the core api consumer, however, its queue MessagesAcknowledged attribute 
count stays at 0, while its MessageCount attribute matches the MessagesAdded 
number.
I see in artemis.log repeated null pointer exception messages for the core 
consumer:

  was:
I am publishing messages to a topic address (jms.topic.). I set the 
message expiration to be 2 seconds (publisher via core api).  I have two 
consumers, one using core api, one using generic stomp protocol.  The core api 
creates a temporary queue to receive the messages from the the address.  The 
stomp consumer relies on the auto-generated temporary queue mechanism provided 
by the broker.  Both consumers are not acknowledging the messages.
In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute 
count rises with the MessagesAdded count, while the MessageCount stays constant 
at 2.
For the core api consumer, however, its queue MessagesAcknowledged attribute 
count stays at 0, while its MessageCount attribute matches the MessagesAdded 
number.
I see in artemis.log repeated messages for the core consumer:


> Messages sent to a jms topi address are not expiring in temporary queue 
> created via core API
> 
>
> Key: ARTEMIS-745
> URL: https://issues.apache.org/jira/browse/ARTEMIS-745
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
> Environment: Redhat Linux 6.2
>Reporter: Ruben Cala
>
> I am publishing messages to a topic address (jms.topic.). I set the 
> message expiration to be 2 seconds (publisher via core api).  I have two 
> consumers, one using core api, one using generic stomp protocol.  The core 
> api creates a temporary queue to receive the messages from the the address.  
> The stomp consumer relies on the auto-generated temporary queue mechanism 
> provided by the broker.  Both consumers are not acknowledging the messages.
> In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute 
> count rises with the MessagesAdded count, while the MessageCount stays 
> constant at 2.
> For the core api consumer, however, its queue MessagesAcknowledged attribute 
> count stays at 0, while its MessageCount attribute matches the MessagesAdded 
> number.
> I see in artemis.log repeated null pointer exception messages for the core 
> consumer:



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

[jira] [Updated] (ARTEMIS-745) Messages sent to a jms topi address are not expiring in temporary queue created via core API

[Ruben Cala (JIRA)]

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

Ruben Cala updated ARTEMIS-745:
---
Description: 
I am publishing messages to a topic address (jms.topic.). I set the 
message expiration to be 2 seconds (publisher via core api).  I have two 
consumers, one using core api, one using generic stomp protocol.  The core api 
creates a temporary queue to receive the messages from the the address.  The 
stomp consumer relies on the auto-generated temporary queue mechanism provided 
by the broker.  Both consumers are not acknowledging the messages.
In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute 
count rises with the MessagesAdded count, while the MessageCount stays constant 
at 2.
For the core api consumer, however, its queue MessagesAcknowledged attribute 
count stays at 0, while its MessageCount attribute matches the MessagesAdded 
number.
I see in artemis.log repeated messages for the core consumer:

  was:I am publishing messages to a topic address (jms.topic.). I set 
the message expiration to be 2 seconds (publisher via core api).  I have two 
consumers, one using core api, one using generic stomp protocol.  The core api 
creates a temporary queue to receive the messages from the the address.  The 
stomp consumer relies on the auto-generated temporary queue mechanism provided 
by the broker.  Both consumers are not acknowledging the messages.


> Messages sent to a jms topi address are not expiring in temporary queue 
> created via core API
> 
>
> Key: ARTEMIS-745
> URL: https://issues.apache.org/jira/browse/ARTEMIS-745
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
> Environment: Redhat Linux 6.2
>Reporter: Ruben Cala
>
> I am publishing messages to a topic address (jms.topic.). I set the 
> message expiration to be 2 seconds (publisher via core api).  I have two 
> consumers, one using core api, one using generic stomp protocol.  The core 
> api creates a temporary queue to receive the messages from the the address.  
> The stomp consumer relies on the auto-generated temporary queue mechanism 
> provided by the broker.  Both consumers are not acknowledging the messages.
> In JConsole for the stomp consumer, its queue MessagesAcknowledged attribute 
> count rises with the MessagesAdded count, while the MessageCount stays 
> constant at 2.
> For the core api consumer, however, its queue MessagesAcknowledged attribute 
> count stays at 0, while its MessageCount attribute matches the MessagesAdded 
> number.
> I see in artemis.log repeated messages for the core consumer:



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

[jira] [Created] (AMQ-6437) Old KahaDB log files not removed

[Steve Hill (JIRA)]

Steve Hill created AMQ-6437:
---

 Summary: Old KahaDB log files not removed
 Key: AMQ-6437
 URL: https://issues.apache.org/jira/browse/AMQ-6437
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.14.0, 5.13.0
Reporter: Steve Hill


Old messages get stuck in KahaDB and never get cleaned up.  The oldest file is 
from July 14, 2016.  Since then we have restarted ActiveMQ multiple times, and 
all servers in environment. This is occuring in our test environment as well as 
production environment.  Currently the only solution is to stop ActiveMQ and 
remove the KahaDB log directory.

Follows is the log of a checkpoint from today 9/21/2016

 2016-09-21 13:27:34,313 [eckpoint Worker] DEBUG MessageDatabase
- Checkpoint started.
 2016-09-21 13:27:34,322 [eckpoint Worker] TRACE MessageDatabase
- Last update: 1438:1243461, full gc candidates set: [674, 691, 699, 705, 711, 
790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 939, 940, 949, 960, 
968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 1093, , 1126, 
1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 1284, 1288, 1289, 
1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 1308, 1309, 1310, 
1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 1323, 1324, 
1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 1368, 1369, 1370, 
1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 1387, 1388, 1389, 
1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 1401, 1402, 
1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 1414, 1415, 
1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 1426, 1427, 1428, 1429, 
1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1438, 1439]
 2016-09-21 13:27:34,322 [eckpoint Worker] TRACE MessageDatabase
- gc candidates after producerSequenceIdTrackerLocation:1438, [674, 691, 699, 
705, 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 939, 940, 
949, 960, 968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 1093, 
, 1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 1284, 
1288, 1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 1308, 
1309, 1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 
1323, 1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 1368, 
1369, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 1387, 
1388, 1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 
1401, 1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 
1414, 1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 1426, 1427, 
1428, 1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1439]
 2016-09-21 13:27:34,323 [eckpoint Worker] TRACE MessageDatabase
- gc candidates after ackMessageFileMapLocation:1438, [674, 691, 699, 705, 711, 
790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 939, 940, 949, 960, 
968, 975, 980, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 1093, , 1126, 
1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 1284, 1288, 1289, 
1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 1308, 1309, 1310, 
1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 1323, 1324, 
1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 1368, 1369, 1370, 
1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 1387, 1388, 1389, 
1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 1401, 1402, 
1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 1414, 1415, 
1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 1426, 1427, 1428, 1429, 
1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1439]
 2016-09-21 13:27:34,324 [eckpoint Worker] TRACE MessageDatabase
- gc candidates after tx range:[980:15980880, 980:15980880], [674, 691, 699, 
705, 711, 790, 858, 865, 866, 877, 888, 899, 904, 909, 910, 918, 930, 939, 940, 
949, 960, 968, 975, 981, 1051, 1066, 1067, 1074, 1075, 1082, 1083, 1093, , 
1126, 1137, 1138, 1155, 1167, 1277, 1279, 1280, 1281, 1282, 1283, 1284, 1288, 
1289, 1291, 1294, 1295, 1296, 1297, 1298, 1299, 1300, 1301, 1307, 1308, 1309, 
1310, 1311, 1312, 1314, 1315, 1316, 1317, 1318, 1319, 1320, 1321, 1322, 1323, 
1324, 1325, 1326, 1327, 1328, 1329, 1330, 1336, 1365, 1366, 1367, 1368, 1369, 
1370, 1371, 1372, 1373, 1374, 1375, 1376, 1377, 1378, 1379, 1380, 1387, 1388, 
1389, 1390, 1391, 1392, 1393, 1394, 1395, 1396, 1397, 1398, 1399, 1400, 1401, 
1402, 1403, 1404, 1405, 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 1414, 
1415, 1416, 1417, 1418, 1419, 1420, 1421, 1423, 1424, 1425, 1426, 1427, 1428, 
1429, 1430, 1431, 1432, 1433, 1434, 1435, 1436, 1437, 1439]
 2016-09-21 13:27:34,324 [eckpoint Worker] TRACE MessageDatabase
- 

[jira] [Closed] (ARTEMIS-745) Messages sent to a jms topi address are not expiring in temporary queue created via core API

[Ruben Cala (JIRA)]

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

Ruben Cala closed ARTEMIS-745.
--
Resolution: Duplicate

accidentally hit ctrl-c before finishing description

> Messages sent to a jms topi address are not expiring in temporary queue 
> created via core API
> 
>
> Key: ARTEMIS-745
> URL: https://issues.apache.org/jira/browse/ARTEMIS-745
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
> Environment: Redhat Linux 6.2
>Reporter: Ruben Cala
>
> I am publishing messages to a topic address (jms.topic.). I set the 
> message expiration to be 2 seconds (publisher via core api).  I have two 
> consumers, one using core api, one using generic stomp protocol.  The core 
> api creates a temporary queue to receive the messages from the the address.  
> The stomp consumer relies on the auto-generated temporary queue mechanism 
> provided by the broker.  Both consumers are not acknowledging the messages.



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

[jira] [Created] (ARTEMIS-746) Messages sent to a jms topic address are not expiring and are remaining in the queue of core api consumer

[Ruben Cala (JIRA)]

Ruben Cala created ARTEMIS-746:
--

 Summary: Messages sent to a jms topic address are not expiring and 
are remaining in the queue of core api consumer
 Key: ARTEMIS-746
 URL: https://issues.apache.org/jira/browse/ARTEMIS-746
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 1.1.0
 Environment: Redhat Linux 6.2
Reporter: Ruben Cala


I am pushing messages to a jms topic address (jms.topic.) on a 
standalone server. The publisher is using core api. Two consumers, one using 
core api, the other using generic stomp protocol. The core api consumer creates 
a temporary queue to get the messages from the address. The stomp client relies 
on the temporary queue created for it by the broker via the jms topic 
functionality. To test slow client scenarios, both consumers are not 
acknowledging the messages received.
In jconsole for the queues, I see the MessageCount attribute for the stomp 
client stay at a low constant number (2), while the MessagesAcknowledged number 
climbs with the MessagesAdded attribute, as expected. For the core api 
consumer, however, the MessageCount matches the MessagesAdded attribute, while 
the MessageCount remains at zero.
I see in artemis.log a null pointer exception:



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

[jira] [Commented] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510630#comment-15510630
 ] 

ASF GitHub Bot commented on ARTEMIS-732:


GitHub user jbertram opened a pull request:

https://github.com/apache/activemq-artemis/pull/788

ARTEMIS-732 loading wrong arch lib



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

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-732

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

https://github.com/apache/activemq-artemis/pull/788.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 #788


commit 1f4a768b1bf58c1e5fd1b9e1df85ac94ae533037
Author: jbertram 
Date:   2016-09-21T17:41:22Z

ARTEMIS-732 loading wrong arch lib




> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Assignee: Justin Bertram
>Priority: Blocker
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to only have the proper  32-bit or 64-bit. All that 
> is necessary is to modify the library path to be platform specific, and the 
> error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Created] (ARTEMIS-745) Messages sent to a jms topi address are not expiring in temporary queue created via core API

[Ruben Cala (JIRA)]

Ruben Cala created ARTEMIS-745:
--

 Summary: Messages sent to a jms topi address are not expiring in 
temporary queue created via core API
 Key: ARTEMIS-745
 URL: https://issues.apache.org/jira/browse/ARTEMIS-745
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 1.1.0
 Environment: Redhat Linux 6.2
Reporter: Ruben Cala


I am publishing messages to a topic address (jms.topic.). I set the 
message expiration to be 2 seconds (publisher via core api).  I have two 
consumers, one using core api, one using generic stomp protocol.  The core api 
creates a temporary queue to receive the messages from the the address.  The 
stomp consumer relies on the auto-generated temporary queue mechanism provided 
by the broker.  Both consumers are not acknowledging the messages.



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

[jira] [Updated] (ARTEMIS-744) Problem to connect in a list of nodes when 1 or more is down.

[Vinicius Araujo Geraldo (JIRA)]

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

Vinicius Araujo Geraldo updated ARTEMIS-744:

Summary: Problem to connect in a list of nodes when 1 or more is down.  
(was: Problem to connect in a list of Apache server when 1 or more is down.)

> Problem to connect in a list of nodes when 1 or more is down.
> -
>
> Key: ARTEMIS-744
> URL: https://issues.apache.org/jira/browse/ARTEMIS-744
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Vinicius Araujo Geraldo
>
> The Artemis' Client when pass the list of nodes, if one is down when consumer 
> try to connect the client thrown an exception and not connect to another 
> nodes.
> Here the code i am using to test:
> TransportConfiguration[] servers = {server1, server2};
> ActiveMQConnectionFactory connectionFactory = 
> ActiveMQJMSClient.createConnectionFactoryWithHA(JMSFactoryType.CF, servers);
> factory.createConnection(username, password);
> I tried to pass param FailoverOnInitialConnection to ConnectionFactory but 
> inside Implementation this param is discarted.
> Is import that client connect to available nodes and try to reconnect in 
> future to others nodes. 



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

[jira] [Updated] (ARTEMIS-744) Problem to connect in a list of Apache server when 1 or more are down.

[Vinicius Araujo Geraldo (JIRA)]

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

Vinicius Araujo Geraldo updated ARTEMIS-744:

Summary: Problem to connect in a list of Apache server when 1 or more are 
down.  (was: Problem to connect in a list of Apache server when 1 or more is 
down.)

> Problem to connect in a list of Apache server when 1 or more are down.
> --
>
> Key: ARTEMIS-744
> URL: https://issues.apache.org/jira/browse/ARTEMIS-744
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Vinicius Araujo Geraldo
>
> The Artemis' Client when pass the list of nodes, if one is down when consumer 
> try to connect the client thrown an exception and not connect to another 
> nodes.
> Here the code i am using to test:
> TransportConfiguration[] servers = {server1, server2};
> ActiveMQConnectionFactory connectionFactory = 
> ActiveMQJMSClient.createConnectionFactoryWithHA(JMSFactoryType.CF, servers);
> factory.createConnection(username, password);
> I tried to pass param FailoverOnInitialConnection to ConnectionFactory but 
> inside Implementation this param is discarted.
> Is import that client connect to available nodes and try to reconnect in 
> future to others nodes. 



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

[jira] [Updated] (ARTEMIS-744) Problem to connect in a list of Apache server when 1 or more is down.

[Vinicius Araujo Geraldo (JIRA)]

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

Vinicius Araujo Geraldo updated ARTEMIS-744:

Summary: Problem to connect in a list of Apache server when 1 or more is 
down.  (was: Problem to connect in a list of Apache server when 1 or more are 
down.)

> Problem to connect in a list of Apache server when 1 or more is down.
> -
>
> Key: ARTEMIS-744
> URL: https://issues.apache.org/jira/browse/ARTEMIS-744
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Vinicius Araujo Geraldo
>
> The Artemis' Client when pass the list of nodes, if one is down when consumer 
> try to connect the client thrown an exception and not connect to another 
> nodes.
> Here the code i am using to test:
> TransportConfiguration[] servers = {server1, server2};
> ActiveMQConnectionFactory connectionFactory = 
> ActiveMQJMSClient.createConnectionFactoryWithHA(JMSFactoryType.CF, servers);
> factory.createConnection(username, password);
> I tried to pass param FailoverOnInitialConnection to ConnectionFactory but 
> inside Implementation this param is discarted.
> Is import that client connect to available nodes and try to reconnect in 
> future to others nodes. 



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

[jira] [Created] (ARTEMIS-744) Problem to connect in a list of Apache server when 1 or more is down.

[Vinicius Araujo Geraldo (JIRA)]

Vinicius Araujo Geraldo created ARTEMIS-744:
---

 Summary: Problem to connect in a list of Apache server when 1 or 
more is down.
 Key: ARTEMIS-744
 URL: https://issues.apache.org/jira/browse/ARTEMIS-744
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Vinicius Araujo Geraldo


The Artemis' Client when pass the list of nodes, if one is down when consumer 
try to connect the client thrown an exception and not connect to another nodes.

Here the code i am using to test:

TransportConfiguration[] servers = {server1, server2};

ActiveMQConnectionFactory connectionFactory = 
ActiveMQJMSClient.createConnectionFactoryWithHA(JMSFactoryType.CF, servers);
factory.createConnection(username, password);

I tried to pass param FailoverOnInitialConnection to ConnectionFactory but 
inside Implementation this param is discarted.

Is import that client connect to available nodes and try to reconnect in future 
to others nodes. 



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

[jira] [Commented] (ARTEMIS-743) Default the queue address to the queue name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510318#comment-15510318
 ] 

ASF GitHub Bot commented on ARTEMIS-743:


Github user franz1981 commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/787#discussion_r79863944
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
 ---
@@ -1290,10 +1291,7 @@ protected ServerSessionImpl 
internalCreateSession(String name,
  SessionCallback 
callback,
  OperationContext 
context,
  boolean 
autoCreateJMSQueues) throws Exception {
-  return new ServerSessionImpl(name, username, password, 
validatedUser, minLargeMessageSize, autoCommitSends, autoCommitAcks, 
preAcknowledge, configuration.isPersistDeliveryCountBeforeDelivery(),
-   xa, connection, storageManager, 
postOffice, resourceManager, securityStore, managementService, this, 
configuration.getManagementAddress(),
-   defaultAddress == null ? null : new 
SimpleString(defaultAddress), callback, context, autoCreateJMSQueues ? 
jmsQueueCreator : null,
-   pagingManager);
+  return new ServerSessionImpl(name, username, password, 
validatedUser, minLargeMessageSize, autoCommitSends, autoCommitAcks, 
preAcknowledge, configuration.isPersistDeliveryCountBeforeDelivery(), xa, 
connection, storageManager, postOffice, resourceManager, securityStore, 
managementService, this, configuration.getManagementAddress(), defaultAddress 
== null ? null : new SimpleString(defaultAddress), callback, context, 
autoCreateJMSQueues ? jmsQueueCreator : null, pagingManager);
--- End diff --

Yes! 
And then i'll squash the commit!


> Default the queue address to the queue name
> ---
>
> Key: ARTEMIS-743
> URL: https://issues.apache.org/jira/browse/ARTEMIS-743
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Francesco Nigro
>  Labels: features
>
> In many instances, users will want the queue name and address to be the same. 
> The latter could default to the queue name, and then it would be safe to omit 
> the address in the queue config.



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

[jira] [Commented] (ARTEMIS-743) Default the queue address to the queue name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510312#comment-15510312
 ] 

ASF GitHub Bot commented on ARTEMIS-743:


Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/787#discussion_r79863285
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/QueueConfig.java
 ---
@@ -0,0 +1,242 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.artemis.core.server;
+
+import org.apache.activemq.artemis.api.core.SimpleString;
+import org.apache.activemq.artemis.core.filter.Filter;
+import org.apache.activemq.artemis.core.filter.FilterUtils;
+import org.apache.activemq.artemis.core.paging.PagingManager;
+import org.apache.activemq.artemis.core.paging.cursor.PageSubscription;
+
+public final class QueueConfig {
+
+   private final long id;
--- End diff --

ahhh... this is an internal class. I thought it was part of the interface 
now.

Never mind then


> Default the queue address to the queue name
> ---
>
> Key: ARTEMIS-743
> URL: https://issues.apache.org/jira/browse/ARTEMIS-743
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Francesco Nigro
>  Labels: features
>
> In many instances, users will want the queue name and address to be the same. 
> The latter could default to the queue name, and then it would be safe to omit 
> the address in the queue config.



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

[jira] [Commented] (ARTEMIS-743) Default the queue address to the queue name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510276#comment-15510276
 ] 

ASF GitHub Bot commented on ARTEMIS-743:


Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/787#discussion_r79860068
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/QueueConfig.java
 ---
@@ -0,0 +1,242 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.artemis.core.server;
+
+import org.apache.activemq.artemis.api.core.SimpleString;
+import org.apache.activemq.artemis.core.filter.Filter;
+import org.apache.activemq.artemis.core.filter.FilterUtils;
+import org.apache.activemq.artemis.core.paging.PagingManager;
+import org.apache.activemq.artemis.core.paging.cursor.PageSubscription;
+
+public final class QueueConfig {
+
+   private final long id;
--- End diff --

The id is assigned when the queue is persisted. Why this is part of the 
config options?


> Default the queue address to the queue name
> ---
>
> Key: ARTEMIS-743
> URL: https://issues.apache.org/jira/browse/ARTEMIS-743
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Francesco Nigro
>  Labels: features
>
> In many instances, users will want the queue name and address to be the same. 
> The latter could default to the queue name, and then it would be safe to omit 
> the address in the queue config.



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

[jira] [Commented] (ARTEMIS-743) Default the queue address to the queue name

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510279#comment-15510279
 ] 

ASF GitHub Bot commented on ARTEMIS-743:


Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/787#discussion_r79860213
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
 ---
@@ -1290,10 +1291,7 @@ protected ServerSessionImpl 
internalCreateSession(String name,
  SessionCallback 
callback,
  OperationContext 
context,
  boolean 
autoCreateJMSQueues) throws Exception {
-  return new ServerSessionImpl(name, username, password, 
validatedUser, minLargeMessageSize, autoCommitSends, autoCommitAcks, 
preAcknowledge, configuration.isPersistDeliveryCountBeforeDelivery(),
-   xa, connection, storageManager, 
postOffice, resourceManager, securityStore, managementService, this, 
configuration.getManagementAddress(),
-   defaultAddress == null ? null : new 
SimpleString(defaultAddress), callback, context, autoCreateJMSQueues ? 
jmsQueueCreator : null,
-   pagingManager);
+  return new ServerSessionImpl(name, username, password, 
validatedUser, minLargeMessageSize, autoCommitSends, autoCommitAcks, 
preAcknowledge, configuration.isPersistDeliveryCountBeforeDelivery(), xa, 
connection, storageManager, postOffice, resourceManager, securityStore, 
managementService, this, configuration.getManagementAddress(), defaultAddress 
== null ? null : new SimpleString(defaultAddress), callback, context, 
autoCreateJMSQueues ? jmsQueueCreator : null, pagingManager);
--- End diff --

this line gets too big.. can you break it?


> Default the queue address to the queue name
> ---
>
> Key: ARTEMIS-743
> URL: https://issues.apache.org/jira/browse/ARTEMIS-743
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Francesco Nigro
>  Labels: features
>
> In many instances, users will want the queue name and address to be the same. 
> The latter could default to the queue name, and then it would be safe to omit 
> the address in the queue config.



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

[jira] [Created] (ARTEMIS-743) Default the queue address to the queue name

[Francesco Nigro (JIRA)]

Francesco Nigro created ARTEMIS-743:
---

 Summary: Default the queue address to the queue name
 Key: ARTEMIS-743
 URL: https://issues.apache.org/jira/browse/ARTEMIS-743
 Project: ActiveMQ Artemis
  Issue Type: New Feature
Reporter: Francesco Nigro


In many instances, users will want the queue name and address to be the same. 
The latter could default to the queue name, and then it would be safe to omit 
the address in the queue config.



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

[jira] [Commented] (ARTEMIS-742) replication quorum broken

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510150#comment-15510150
 ] 

ASF subversion and git services commented on ARTEMIS-742:
-

Commit 680f84b5a28b8f1af85640a32c2c0b936a890d5a in activemq-artemis's branch 
refs/heads/master from [~andytaylor]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=680f84b ]

ARTEMIS-742 = replication quorum broken

https://issues.apache.org/jira/browse/ARTEMIS-742


> replication quorum broken
> -
>
> Key: ARTEMIS-742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-742
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>




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

[jira] [Commented] (ARTEMIS-742) replication quorum broken

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510149#comment-15510149
 ] 

ASF subversion and git services commented on ARTEMIS-742:
-

Commit 680f84b5a28b8f1af85640a32c2c0b936a890d5a in activemq-artemis's branch 
refs/heads/master from [~andytaylor]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=680f84b ]

ARTEMIS-742 = replication quorum broken

https://issues.apache.org/jira/browse/ARTEMIS-742


> replication quorum broken
> -
>
> Key: ARTEMIS-742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-742
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>




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

[jira] [Commented] (ARTEMIS-742) replication quorum broken

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510152#comment-15510152
 ] 

ASF GitHub Bot commented on ARTEMIS-742:


Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/786


> replication quorum broken
> -
>
> Key: ARTEMIS-742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-742
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>




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

[jira] [Assigned] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-732:
--

Assignee: Justin Bertram

> Spurious message while loading native libraries in certain envs.
> 
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Assignee: Justin Bertram
>Priority: Blocker
>  Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit 
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard 
> now.
> It's highly recommended that you fix the library with 'execstack -c 
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the 
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path 
> and the 64-bit library path, but it doesn't actually work.  The script should 
> deal with it accordingly to only have the proper  32-bit or 64-bit. All that 
> is necessary is to modify the library path to be platform specific, and the 
> error condition is resolved. I have attached modified script files 
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the 
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}



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

[jira] [Resolved] (AMQ-6430) noLocal=true in durable subscriptions is ignored after reconnect

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon resolved AMQ-6430.
-
   Resolution: Fixed
Fix Version/s: 5.15.0
   5.14.1

> noLocal=true in durable subscriptions is ignored after reconnect
> 
>
> Key: AMQ-6430
> URL: https://issues.apache.org/jira/browse/AMQ-6430
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.4, 5.14.0
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_111 and Oracle JDK 1.8.0.74, 
> other environments not testet
>Reporter: Daniel Faber
>Assignee: Christopher L. Shannon
> Fix For: 5.14.1, 5.15.0
>
> Attachments: ActiveMQNoLocalTest.java, pom.xml
>
>
> I create a connection to my local ActiveMQ and open two sessions. In the 
> first session I create a durable topic subscriber with noLocal=true. In the 
> second session I send a message to the same topic. Then I close both sessions 
> and the connection. The first time I do this, everything works well, that 
> means I send but do not receive the message. The second time I run the same 
> application I send AND receive the message.
> After removing all files and directories in ActiveMQ's data directory, not 
> receiving my own message works again, but only once.



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

[jira] [Commented] (AMQ-6430) noLocal=true in durable subscriptions is ignored after reconnect

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509928#comment-15509928
 ] 

ASF subversion and git services commented on AMQ-6430:
--

Commit d3b86e77ddfe7d0185ff150520a0dddc9c6cf53e in activemq's branch 
refs/heads/activemq-5.14.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=d3b86e7 ]

https://issues.apache.org/jira/browse/AMQ-6430

When a nolocal durable consumer reconnects the new connectionId is properly 
captured for
the NoLocal expression so that nolocal works on reconnect.  Also fixed
the detection of the nolocal value changing on consumer connect.

(cherry picked from commit 7c293b661f22245ce21bf2b5aa1c5bf4192cb8c5)


> noLocal=true in durable subscriptions is ignored after reconnect
> 
>
> Key: AMQ-6430
> URL: https://issues.apache.org/jira/browse/AMQ-6430
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.4, 5.14.0
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_111 and Oracle JDK 1.8.0.74, 
> other environments not testet
>Reporter: Daniel Faber
>Assignee: Christopher L. Shannon
> Attachments: ActiveMQNoLocalTest.java, pom.xml
>
>
> I create a connection to my local ActiveMQ and open two sessions. In the 
> first session I create a durable topic subscriber with noLocal=true. In the 
> second session I send a message to the same topic. Then I close both sessions 
> and the connection. The first time I do this, everything works well, that 
> means I send but do not receive the message. The second time I run the same 
> application I send AND receive the message.
> After removing all files and directories in ActiveMQ's data directory, not 
> receiving my own message works again, but only once.



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

[jira] [Commented] (AMQ-6430) noLocal=true in durable subscriptions is ignored after reconnect

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509926#comment-15509926
 ] 

ASF subversion and git services commented on AMQ-6430:
--

Commit 7c293b661f22245ce21bf2b5aa1c5bf4192cb8c5 in activemq's branch 
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=7c293b6 ]

https://issues.apache.org/jira/browse/AMQ-6430

When a nolocal durable consumer reconnects the new connectionId is properly 
captured for
the NoLocal expression so that nolocal works on reconnect.  Also fixed
the detection of the nolocal value changing on consumer connect.


> noLocal=true in durable subscriptions is ignored after reconnect
> 
>
> Key: AMQ-6430
> URL: https://issues.apache.org/jira/browse/AMQ-6430
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.4, 5.14.0
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_111 and Oracle JDK 1.8.0.74, 
> other environments not testet
>Reporter: Daniel Faber
>Assignee: Christopher L. Shannon
> Attachments: ActiveMQNoLocalTest.java, pom.xml
>
>
> I create a connection to my local ActiveMQ and open two sessions. In the 
> first session I create a durable topic subscriber with noLocal=true. In the 
> second session I send a message to the same topic. Then I close both sessions 
> and the connection. The first time I do this, everything works well, that 
> means I send but do not receive the message. The second time I run the same 
> application I send AND receive the message.
> After removing all files and directories in ActiveMQ's data directory, not 
> receiving my own message works again, but only once.



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

[jira] [Commented] (AMQ-6422) AMQP - flow(1) without a dispositon can lead to blocked receive

[Gary Tully (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509850#comment-15509850
 ] 

Gary Tully commented on AMQ-6422:
-

Thanks [~gemmellr] for the quick review. I managed to build a test that showed 
the problem with using delivery in the successive flow case. When drained there 
is a flow with credit 0 that reset in the more normal case.

> AMQP - flow(1) without a dispositon can lead to blocked receive
> ---
>
> Key: AMQ-6422
> URL: https://issues.apache.org/jira/browse/AMQ-6422
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> Setting prefetch based on the credit can get in a knot if the credit is small 
> and the dispositions are outstanding.
> The prefetch gets set to 1, but with an inflight message, there is nothing 
> dispatched b/c the sub looks full.



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

[jira] [Resolved] (AMQ-6422) AMQP - flow(1) without a dispositon can lead to blocked receive

[Gary Tully (JIRA)]

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

Gary Tully resolved AMQ-6422.
-
   Resolution: Fixed
Fix Version/s: 5.15.0

> AMQP - flow(1) without a dispositon can lead to blocked receive
> ---
>
> Key: AMQ-6422
> URL: https://issues.apache.org/jira/browse/AMQ-6422
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Gary Tully
>Assignee: Gary Tully
> Fix For: 5.15.0
>
>
> Setting prefetch based on the credit can get in a knot if the credit is small 
> and the dispositions are outstanding.
> The prefetch gets set to 1, but with an inflight message, there is nothing 
> dispatched b/c the sub looks full.



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

[jira] [Commented] (AMQ-6422) AMQP - flow(1) without a dispositon can lead to blocked receive

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509842#comment-15509842
 ] 

ASF subversion and git services commented on AMQ-6422:
--

Commit 6c01b641b1850b384e57d74ad6471ea4c8fcf01f in activemq's branch 
refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=6c01b64 ]

https://issues.apache.org/jira/browse/AMQ-6422 - move delivery tracking to 
pumpoutbound and additional test that shows how the presettle case breaks. 
Thanks to Robbie Gemmell for the feedback


> AMQP - flow(1) without a dispositon can lead to blocked receive
> ---
>
> Key: AMQ-6422
> URL: https://issues.apache.org/jira/browse/AMQ-6422
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Gary Tully
>Assignee: Gary Tully
>
> Setting prefetch based on the credit can get in a knot if the credit is small 
> and the dispositions are outstanding.
> The prefetch gets set to 1, but with an inflight message, there is nothing 
> dispatched b/c the sub looks full.



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

[jira] [Created] (ARTEMIS-742) replication quorum broken

[Andy Taylor (JIRA)]

Andy Taylor created ARTEMIS-742:
---

 Summary: replication quorum broken
 Key: ARTEMIS-742
 URL: https://issues.apache.org/jira/browse/ARTEMIS-742
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Andy Taylor
Assignee: Andy Taylor






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

[jira] [Commented] (AMQ-6430) noLocal=true in durable subscriptions is ignored after reconnect

[Christopher L. Shannon (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509813#comment-15509813
 ] 

Christopher L. Shannon commented on AMQ-6430:
-

Looks like there are two places where the NoLocal attribute needs to be 
checked, it is done in one location but not the other.

> noLocal=true in durable subscriptions is ignored after reconnect
> 
>
> Key: AMQ-6430
> URL: https://issues.apache.org/jira/browse/AMQ-6430
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.4, 5.14.0
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_111 and Oracle JDK 1.8.0.74, 
> other environments not testet
>Reporter: Daniel Faber
>Assignee: Christopher L. Shannon
> Attachments: ActiveMQNoLocalTest.java, pom.xml
>
>
> I create a connection to my local ActiveMQ and open two sessions. In the 
> first session I create a durable topic subscriber with noLocal=true. In the 
> second session I send a message to the same topic. Then I close both sessions 
> and the connection. The first time I do this, everything works well, that 
> means I send but do not receive the message. The second time I run the same 
> application I send AND receive the message.
> After removing all files and directories in ActiveMQ's data directory, not 
> receiving my own message works again, but only once.



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

[jira] [Comment Edited] (AMQ-6430) noLocal=true in durable subscriptions is ignored after reconnect

[Christopher L. Shannon (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509755#comment-15509755
 ] 

Christopher L. Shannon edited comment on AMQ-6430 at 9/21/16 12:26 PM:
---

I took a look at this and there are actually two problems here with how noLocal 
is handled with durables.  The main issue you are seeing is that when the 
durable comes back online the new connectionId is not being captured for the 
NoLocal expression parser which means that when messages are sent after broker 
restart the logic thinks that the message isn't coming from the current 
subscription when it is.  The fix here is to make sure the connectionId is 
updated properly when the new consumer comes online.

The second issue is that the JMS spec says that 
{noformat}
A client can change an existing durable subscription by creating a durable
TopicSubscriber with the same name and a new topic and/or message selector,
or NoLocal attribute. Changing a durable subscription is equivalent to deleting
and recreating it.
{noformat}

Right now we aren't checking if that NoLocal attribute changes at all when a 
new consumer comes online.  Based on the spec I think we should update the 
activation check such that if the NoLocal attribute changes (ie goes from false 
to true or true to false) we treat it as a selector change and process it the 
same way (delete and recreate the sub)

I am working on a patch and fix now to go out with our 5.14.1 release.


was (Author: christopher.l.shannon):
I took a look at this and there are actually two problems here with how noLocal 
is handled with durables.  The main issue you are seeing is that when the 
durable comes back online the new connectionId is not being captured for the 
NoLocal expression parser which means that when messages are sent after broker 
restart the logic thinks that the message isn't coming from the current 
subscription when it is.  The fix here is to make sure the connectionId is 
updated properly when the new consumer comes online.

The second issue is that the JMS spec says that 
{noformat}
A client can change an existing durable subscription by creating a durable
TopicSubscriber with the same name and a new topic and/or message selector,
or NoLocal attribute. Changing a durable subscription is equivalent to deleting
and recreating it.
{noformat}

Right now we aren't checking if that NoLocal attribute changes at all when a 
new consumer comes online.  Base on the spec I think we should update the 
activation check such that if the NoLocal attribute changes (ie goes from false 
to true or true to false) we treat it as a selector change and process it the 
same way (delete and recreate the sub)

I am working on a patch and fix now to go out with our 5.14.1 release.

> noLocal=true in durable subscriptions is ignored after reconnect
> 
>
> Key: AMQ-6430
> URL: https://issues.apache.org/jira/browse/AMQ-6430
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.4, 5.14.0
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_111 and Oracle JDK 1.8.0.74, 
> other environments not testet
>Reporter: Daniel Faber
>Assignee: Christopher L. Shannon
> Attachments: ActiveMQNoLocalTest.java, pom.xml
>
>
> I create a connection to my local ActiveMQ and open two sessions. In the 
> first session I create a durable topic subscriber with noLocal=true. In the 
> second session I send a message to the same topic. Then I close both sessions 
> and the connection. The first time I do this, everything works well, that 
> means I send but do not receive the message. The second time I run the same 
> application I send AND receive the message.
> After removing all files and directories in ActiveMQ's data directory, not 
> receiving my own message works again, but only once.



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

[jira] [Commented] (AMQ-6430) noLocal=true in durable subscriptions is ignored after reconnect

[Christopher L. Shannon (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509755#comment-15509755
 ] 

Christopher L. Shannon commented on AMQ-6430:
-

I took a look at this and there are actually two problems here with how noLocal 
is handled with durables.  The main issue you are seeing is that when the 
durable comes back online the new connectionId is not being captured for the 
NoLocal expression parser which means that when messages are sent after broker 
restart the logic thinks that the message isn't coming from the current 
subscription when it is.  The fix here is to make sure the connectionId is 
updated properly when the new consumer comes online.

The second issue is that the JMS spec says that 
{noformat}
A client can change an existing durable subscription by creating a durable
TopicSubscriber with the same name and a new topic and/or message selector,
or NoLocal attribute. Changing a durable subscription is equivalent to deleting
and recreating it.
{noformat}

Right now we aren't checking if that NoLocal attribute changes at all when a 
new consumer comes online.  Base on the spec I think we should update the 
activation check such that if the NoLocal attribute changes (ie goes from false 
to true or true to false) we treat it as a selector change and process it the 
same way (delete and recreate the sub)

I am working on a patch and fix now to go out with our 5.14.1 release.

> noLocal=true in durable subscriptions is ignored after reconnect
> 
>
> Key: AMQ-6430
> URL: https://issues.apache.org/jira/browse/AMQ-6430
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.4, 5.14.0
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_111 and Oracle JDK 1.8.0.74, 
> other environments not testet
>Reporter: Daniel Faber
>Assignee: Christopher L. Shannon
> Attachments: ActiveMQNoLocalTest.java, pom.xml
>
>
> I create a connection to my local ActiveMQ and open two sessions. In the 
> first session I create a durable topic subscriber with noLocal=true. In the 
> second session I send a message to the same topic. Then I close both sessions 
> and the connection. The first time I do this, everything works well, that 
> means I send but do not receive the message. The second time I run the same 
> application I send AND receive the message.
> After removing all files and directories in ActiveMQ's data directory, not 
> receiving my own message works again, but only once.



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

[jira] [Assigned] (AMQ-6430) noLocal=true in durable subscriptions is ignored after reconnect

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon reassigned AMQ-6430:
---

Assignee: Christopher L. Shannon

> noLocal=true in durable subscriptions is ignored after reconnect
> 
>
> Key: AMQ-6430
> URL: https://issues.apache.org/jira/browse/AMQ-6430
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.4, 5.14.0
> Environment: Ubuntu 14.04, OpenJDK 1.7.0_111 and Oracle JDK 1.8.0.74, 
> other environments not testet
>Reporter: Daniel Faber
>Assignee: Christopher L. Shannon
> Attachments: ActiveMQNoLocalTest.java, pom.xml
>
>
> I create a connection to my local ActiveMQ and open two sessions. In the 
> first session I create a durable topic subscriber with noLocal=true. In the 
> second session I send a message to the same topic. Then I close both sessions 
> and the connection. The first time I do this, everything works well, that 
> means I send but do not receive the message. The second time I run the same 
> application I send AND receive the message.
> After removing all files and directories in ActiveMQ's data directory, not 
> receiving my own message works again, but only once.



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

[jira] [Commented] (AMQ-6422) AMQP - flow(1) without a dispositon can lead to blocked receive

[Robbie Gemmell (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509633#comment-15509633
 ] 

Robbie Gemmell commented on AMQ-6422:
-

The 'logicalDeliveryCount' increment added at the end of the 'delivery' method 
seems off since that method is called based on disposition activity, and may 
either never be called for a given message (if sent pre-settled) or be called 
multiple times for the same message (due to multiple dispositions).

For the purposes of credit tracking, the credit is used as soon as the message 
is finished being handed to proton, in this case in 'pumpOutbound' when the 
link is advanced to complete the current delivery, or the links 'current' 
incomplete delivery is settled (which must advance the link to complete the 
delivery).

> AMQP - flow(1) without a dispositon can lead to blocked receive
> ---
>
> Key: AMQ-6422
> URL: https://issues.apache.org/jira/browse/AMQ-6422
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Gary Tully
>Assignee: Gary Tully
>
> Setting prefetch based on the credit can get in a knot if the credit is small 
> and the dispositions are outstanding.
> The prefetch gets set to 1, but with an inflight message, there is nothing 
> dispatched b/c the sub looks full.



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

[jira] [Commented] (AMQ-6435) Implement JMX destination query API

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509347#comment-15509347
 ] 

ASF subversion and git services commented on AMQ-6435:
--

Commit 5d9f1cd3d58cae626a53cd0fcf21656d4da38ca8 in activemq's branch 
refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=5d9f1cd ]

https://issues.apache.org/jira/browse/AMQ-6435 - use lesser guava dep to match 
leveldb java


> Implement JMX destination query API
> ---
>
> Key: AMQ-6435
> URL: https://issues.apache.org/jira/browse/AMQ-6435
> Project: ActiveMQ
>  Issue Type: New Feature
>Affects Versions: 5.14.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.15.0
>
>
> In an environment when there thousands of destinations on the broker, current 
> way of exposing all MBeans and looking into them in the tools does not scale. 
> We need to implement an API that can be used by tools to filter, sort and 
> page destinations in this scenario.



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

[jira] [Commented] (ARTEMIS-740) Auto-reload diverts from broker.xml

[JIRA]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509314#comment-15509314
 ] 

Ville Skyttä commented on ARTEMIS-740:
--

This only loads new diverts, doesn't remove or modify existing ones.

> Auto-reload diverts from broker.xml
> ---
>
> Key: ARTEMIS-740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-740
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Ville Skyttä
> Fix For: 1.5.0
>
>
> Automatic reloading of diverts from broker.xml would be equally useful as for 
> addresses, security, and jms destinations, see ARTEMIS-601



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

[jira] [Commented] (ARTEMIS-740) Auto-reload diverts from broker.xml

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509309#comment-15509309
 ] 

ASF GitHub Bot commented on ARTEMIS-740:


GitHub user scop opened a pull request:

https://github.com/apache/activemq-artemis/pull/784

ARTEMIS-740 Auto-reload diverts from broker.xml



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

$ git pull https://github.com/scop/activemq-artemis divert-reload

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

https://github.com/apache/activemq-artemis/pull/784.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 #784


commit 520422934bf4e3e18efc93210b0fd27d1c95c084
Author: Ville Skyttä 
Date:   2016-09-21T09:13:31Z

ARTEMIS-740 Auto-reload diverts from broker.xml




> Auto-reload diverts from broker.xml
> ---
>
> Key: ARTEMIS-740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-740
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Ville Skyttä
> Fix For: 1.5.0
>
>
> Automatic reloading of diverts from broker.xml would be equally useful as for 
> addresses, security, and jms destinations, see ARTEMIS-601



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