[jira] [Commented] (ARTEMIS-393) Server logs message with queue deploy even when topic is being deployed.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-393:


GitHub user treblereel opened a pull request:

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

ARTEMIS-393 Server logs message with queue deploy even when topic is …

…being deployed.

[JBEAP-3176] Server logs message with queue deploy even when topic is being 
deployed.

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

$ git pull https://github.com/treblereel/activemq-artemis-wildfly JBEAP-3176

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

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


commit 5c4ab302aa41eaff1dbb3604c28c62768b4b159c
Author: Dmitrii Tikhomirov 
Date:   2016-02-05T18:46:31Z

ARTEMIS-393 Server logs message with queue deploy even when topic is being 
deployed.
[JBEAP-3176] Server logs message with queue deploy even when topic is being 
deployed.




> Server logs message with queue deploy even when topic is being deployed.
> 
>
> Key: ARTEMIS-393
> URL: https://issues.apache.org/jira/browse/ARTEMIS-393
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>




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

[jira] [Commented] (ARTEMIS-388) No obvious way to discover whether an embedded server actually started OK or not

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-388:


Github user asfgit closed the pull request at:

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


> No obvious way to discover whether an embedded server actually started OK or 
> not
> 
>
> Key: ARTEMIS-388
> URL: https://issues.apache.org/jira/browse/ARTEMIS-388
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Mike Hearn
>Assignee: Justin Bertram
>
> If I use the embedded Artemis API, then if the port it's listening on is 
> taken the server still "starts" correctly, but with the most important 
> component in a failed state! I would like to abort the startup of my app in 
> case something like this happens but I wasn't able to figure out from the 
> documentation how to actually check if all the requested 
> connectors/bridges/etc are all functioning correctly or if an exception was 
> thrown (I can see the exception in the logs, of course).



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

[jira] [Commented] (ARTEMIS-395) Auto-delete JMS queues only if auto-delete-jms-queues = true

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-395:


Github user asfgit closed the pull request at:

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


> Auto-delete JMS queues only if auto-delete-jms-queues = true
> 
>
> Key: ARTEMIS-395
> URL: https://issues.apache.org/jira/browse/ARTEMIS-395
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Commented] (ARTEMIS-287) [Artemis Testsuite] PagingTest#testDeleteQueueRestart fails on slower machines

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-287:


Github user asfgit closed the pull request at:

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


> [Artemis Testsuite] PagingTest#testDeleteQueueRestart fails on slower machines
> --
>
> Key: ARTEMIS-287
> URL: https://issues.apache.org/jira/browse/ARTEMIS-287
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Erich Duda
>
> {code}
> long timeout = System.currentTimeMillis() + 5000;
> // I want the buffer full to make sure there are pending messages on the 
> server's side
> while (System.currentTimeMillis() < timeout && cons.getBufferSize() < 1000 && 
> cons2.getBufferSize() < 1000) {
> System.out.println("cons1 buffer = " + cons.getBufferSize() + ", cons2 
> buffer = " + cons2.getBufferSize());
> Thread.sleep(100);
> }
> {code}
> On slower machines the 5 seconds timeout is too short.



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

[jira] [Commented] (ARTEMIS-393) Server logs message with queue deploy even when topic is being deployed.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-393:


Github user asfgit closed the pull request at:

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


> Server logs message with queue deploy even when topic is being deployed.
> 
>
> Key: ARTEMIS-393
> URL: https://issues.apache.org/jira/browse/ARTEMIS-393
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>




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

[jira] [Commented] (ARTEMIS-365) [Artemis Testsuite] AddressControlTest#testGetNumberOfPages fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-365:


GitHub user dudaerich opened a pull request:

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

ARTEMIS-365 - [Artemis Testsuite] AddressControlTest#testGetNumberOfPages 
fails



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

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-365

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

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


commit b0c692c7efdd77c8600e76a53e58a1a6f98d4323
Author: Erich Duda 
Date:   2016-02-08T13:16:59Z

ARTEMIS-365 - [Artemis Testsuite] AddressControlTest#testGetNumberOfPages 
fails




> [Artemis Testsuite] AddressControlTest#testGetNumberOfPages fails
> -
>
> Key: ARTEMIS-365
> URL: https://issues.apache.org/jira/browse/ARTEMIS-365
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> java.lang.AssertionError: expected:<1> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.artemis.tests.integration.management.AddressControlTest.testGetNumberOfPages(AddressControlTest.java:222)
> {code}



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

[jira] [Commented] (ARTEMIS-364) [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-364:


GitHub user dudaerich opened a pull request:

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

ARTEMIS-364 - [Artemis Testsuite] PagingTest#testPagingDifferentSizes…

… fails

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

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-364

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

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


commit b341919f0d40b5ebfde248761b58c461817cef63
Author: Erich Duda 
Date:   2016-02-08T13:52:33Z

ARTEMIS-364 - [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails




> [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails
> -
>
> Key: ARTEMIS-364
> URL: https://issues.apache.org/jira/browse/ARTEMIS-364
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
> Fix For: 1.2.0
>
>
> {code}
> java.lang.AssertionError: null
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.activemq.artemis.tests.integration.client.PagingTest.testPagingDifferentSizes(PagingTest.java:3576)
> {code}



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

[jira] [Commented] (ARTEMIS-395) Auto-delete JMS queues only if auto-delete-jms-queues = true

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-395:


GitHub user jbertram opened a pull request:

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

ARTEMIS-395 auto-delete only if setting is true



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

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

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

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


commit c47a9c38cc11ccb676f45e7227a684618cff0501
Author: jbertram 
Date:   2016-02-09T15:16:38Z

ARTEMIS-395 auto-delete only if setting is true




> Auto-delete JMS queues only if auto-delete-jms-queues = true
> 
>
> Key: ARTEMIS-395
> URL: https://issues.apache.org/jira/browse/ARTEMIS-395
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Commented] (ARTEMIS-388) No obvious way to discover whether an embedded server actually started OK or not

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-388:


GitHub user jbertram opened a pull request:

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

ARTEMIS-388 listen for activation failures



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

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

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

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


commit 8cecaed528a472280e7ba12465e58c166e3de3a9
Author: jbertram 
Date:   2016-02-05T18:11:21Z

ARTEMIS-388 listen for activation failures




> No obvious way to discover whether an embedded server actually started OK or 
> not
> 
>
> Key: ARTEMIS-388
> URL: https://issues.apache.org/jira/browse/ARTEMIS-388
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Mike Hearn
>Assignee: Justin Bertram
>
> If I use the embedded Artemis API, then if the port it's listening on is 
> taken the server still "starts" correctly, but with the most important 
> component in a failed state! I would like to abort the startup of my app in 
> case something like this happens but I wasn't able to figure out from the 
> documentation how to actually check if all the requested 
> connectors/bridges/etc are all functioning correctly or if an exception was 
> thrown (I can see the exception in the logs, of course).



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

[jira] [Commented] (ARTEMIS-388) No obvious way to discover whether an embedded server actually started OK or not

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-388:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/381#issuecomment-181932768
  
Looks good, I will merge it.

@mikehearn if you can try it out... if you see anything please let us know.


> No obvious way to discover whether an embedded server actually started OK or 
> not
> 
>
> Key: ARTEMIS-388
> URL: https://issues.apache.org/jira/browse/ARTEMIS-388
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Mike Hearn
>Assignee: Justin Bertram
>
> If I use the embedded Artemis API, then if the port it's listening on is 
> taken the server still "starts" correctly, but with the most important 
> component in a failed state! I would like to abort the startup of my app in 
> case something like this happens but I wasn't able to figure out from the 
> documentation how to actually check if all the requested 
> connectors/bridges/etc are all functioning correctly or if an exception was 
> thrown (I can see the exception in the logs, of course).



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

[jira] [Commented] (ARTEMIS-387) Typos in error message

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-387:


GitHub user jbertram opened a pull request:

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

ARTEMIS-387 grammar fix



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

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

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

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


commit 8dcea17f1101e705a124737ccea938eadc904368
Author: jbertram 
Date:   2016-02-05T18:13:11Z

ARTEMIS-387 grammar fix




> Typos in error message
> --
>
> Key: ARTEMIS-387
> URL: https://issues.apache.org/jira/browse/ARTEMIS-387
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Mike Hearn
>Assignee: Justin Bertram
>Priority: Trivial
>
> 15:04:46 57 BridgeImpl.connect: AMQ221026: Bridge XXX connected to 
> fowardingAddress=XXX. XXX does not have any bindings what means messages will 
> be ignored until a binding is created.
> forwardingAddress not fowarding
> "does not have any bindings, WHICH means"



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

[jira] [Commented] (ARTEMIS-385) Race between topology update and connection creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-385:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/369#issuecomment-179829081
  
The failure on jenkins is non related. But there's a failure on a test and 
I'm investigating this.


> Race between topology update and connection creation
> 
>
> Key: ARTEMIS-385
> URL: https://issues.apache.org/jira/browse/ARTEMIS-385
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> MultipleThreadsOpeningTest will fail eventually because of this.
> avax.jms.JMSException: Failed to create session factory
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:727)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:229)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.cluster.MultipleThreadsOpeningTest$1ThreadOpen.run(MultipleThreadsOpeningTest.java:59)
> Caused by: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT 
> message=AMQ119013: Timed out waiting to receive cluster topology. Group:null]
>   at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:861)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
>   ... 3 more



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

[jira] [Commented] (ARTEMIS-385) Race between topology update and connection creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-385:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/369#issuecomment-179873433
  
test fixed! ready to merge again


> Race between topology update and connection creation
> 
>
> Key: ARTEMIS-385
> URL: https://issues.apache.org/jira/browse/ARTEMIS-385
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> MultipleThreadsOpeningTest will fail eventually because of this.
> avax.jms.JMSException: Failed to create session factory
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:727)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:229)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.cluster.MultipleThreadsOpeningTest$1ThreadOpen.run(MultipleThreadsOpeningTest.java:59)
> Caused by: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT 
> message=AMQ119013: Timed out waiting to receive cluster topology. Group:null]
>   at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:861)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
>   ... 3 more



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

[jira] [Commented] (AMQ-6160) JDBC XA: NullPointerException on rollback in PREPARED_STATE when trying to unset the XID

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-6160:
-

GitHub user jenshadlich opened a pull request:

https://github.com/apache/activemq/pull/167

[AMQ-6160] fix NPE; use messageId.getFutureOrSequenceLong() as sequen…

…ceId if entryLocator is NULL

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

$ git pull https://github.com/jenshadlich/activemq master

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

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


commit 569ab7e4d01913b646f024f097662da5ed7c8797
Author: Jens Hadlich 
Date:   2016-02-05T09:43:12Z

[AMQ-6160] fix NPE; use messageId.getFutureOrSequenceLong() as sequenceId 
if entryLocator is NULL




> JDBC XA: NullPointerException on rollback in PREPARED_STATE when trying to 
> unset the XID
> 
>
> Key: AMQ-6160
> URL: https://issues.apache.org/jira/browse/AMQ-6160
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 5.12.1
>Reporter: Jens Hadlich
>
> The messageId.getEntryLocator() gives null which leads to the NPE.
> Example stacktrace:
> {noformat}
> 11:12:32.965 [messageListenerContainer-7] WARN  
> c.a.d.xa.XAResourceTransaction - XA resource 'atomikosFactorIn': rollback for 
> XID 
> '3137322E31362E3231352E34312E746D30303030363030303435:3137322E31362E3231352E34312E746D313136'
>  raised -7: the XA resource has become unavailable
> javax.transaction.xa.XAException: java.lang.NullPointerException
> at 
> org.apache.activemq.TransactionContext.toXAException(TransactionContext.java:735)
>  ~[messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> org.apache.activemq.TransactionContext.rollback(TransactionContext.java:497) 
> ~[messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.datasource.xa.XAResourceTransaction.rollback(XAResourceTransaction.java:677)
>  ~[messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.RollbackMessage.send(RollbackMessage.java:70) 
> [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:83) 
> [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:79) 
> [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.Propagator.submitPropagationMessage(Propagator.java:58)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.CoordinatorStateHandler.rollbackFromWithinCallback(CoordinatorStateHandler.java:709)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.ActiveStateHandler$4.doRollback(ActiveStateHandler.java:213)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.CoordinatorStateHandler.rollbackWithAfterCompletionNotification(CoordinatorStateHandler.java:837)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.ActiveStateHandler.rollbackWithAfterCompletionNotification(ActiveStateHandler.java:49)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.ActiveStateHandler.prepare(ActiveStateHandler.java:208)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.CoordinatorImp.prepare(CoordinatorImp.java:681) 
> [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.CoordinatorImp.terminate(CoordinatorImp.java:975) 
> [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.CompositeTerminatorImp.commit(CompositeTerminatorImp.java:82)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.imp.CompositeTransactionImp.commit(CompositeTransactionImp.java:336)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.jta.TransactionImp.commit(TransactionImp.java:190) 
> [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.jta.TransactionManagerImp.commit(TransactionManagerImp.java:436)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> com.atomikos.icatch.jta.UserTransactionImp.commit(UserTransactionImp.java:107)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1021)
>  [messaging-test-tool-1.0-SNAPSHOT.2.jar:na]
> at 
> 

[jira] [Commented] (ARTEMIS-396) [Artemis Testsuite] ReceiveTest#testReceiveImmediate fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-396:


GitHub user dudaerich opened a pull request:

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

ARTEMIS-396 - [Artemis Testsuite] ReceiveTest#testReceiveImmediate fails



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

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-396

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

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


commit 1630e4c919c7a35d16f380fedfe0773a5185b70f
Author: Erich Duda 
Date:   2016-02-12T12:31:25Z

ARTEMIS-396 - [Artemis Testsuite] ReceiveTest#testReceiveImmediate fails




> [Artemis Testsuite] ReceiveTest#testReceiveImmediate fails
> --
>
> Key: ARTEMIS-396
> URL: https://issues.apache.org/jira/browse/ARTEMIS-396
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: null
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertNotNull(Assert.java:621)
>   at org.junit.Assert.assertNotNull(Assert.java:631)
>   at 
> org.apache.activemq.artemis.tests.integration.client.ReceiveTest.testReceiveImmediate(ReceiveTest.java:152)
> {code}
> Sending nondurable messages is not blocking by default. We have to ensure 
> that all messages were received by server before we start consume them.



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

[jira] [Commented] (AMQ-6165) Python stompest tests do not work with newer releases

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-6165:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq/pull/168


> Python stompest tests do not work with newer releases
> -
>
> Key: AMQ-6165
> URL: https://issues.apache.org/jira/browse/AMQ-6165
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Affects Versions: 5.13.0
> Environment: Python 2.7
>Reporter: Ingo Weiss
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 5.14.0
>
>
> The {{listener.py}} from the {{stompest}} API Python example doesn't work 
> with this error message:
> {noformat}
> Unhandled error in Deferred:
> Traceback (most recent call last):
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 393, in callback
> self._startRunCallbacks(result)
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 501, in _startRunCallbacks
> self._runCallbacks()
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 588, in _runCallbacks
> current.result = callback(current.result, *args, **kw)
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 1184, in gotResult
> _inlineCallbacks(r, g, deferred)
> ---  ---
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 1128, in _inlineCallbacks
> result = g.send(result)
>   File "listener.py", line 45, in run
> client.subscribe(destination, self.handleFrame, headers={'ack': 'auto', 
> 'id': 'required-for-STOMP-1.1'}, ack=False)
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/stompest/util/__init__.py",
>  line 16, in __checkattr
> return f(self, *args, **kwargs)
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 1265, in unwindGenerator
> gen = f(*args, **kwargs)
> exceptions.TypeError: subscribe() got an unexpected keyword argument 'ack'
> {noformat}



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

[jira] [Commented] (AMQ-6165) Python stompest tests do not work with newer releases

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-6165:
-

GitHub user iweiss opened a pull request:

https://github.com/apache/activemq/pull/168

[AMQ-6165] Python stompest tests do not work with newer releases



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

$ git pull https://github.com/iweiss/activemq-1 master

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

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


commit dcaf7cc0425c614e8e205a94dbf5e491efda05de
Author: Ingo Weiss 
Date:   2016-02-11T09:03:47Z

Clarified and updated instructions

commit 009080fde8830ac832e34583b818d2600475f789
Author: Ingo Weiss 
Date:   2016-02-11T09:50:30Z

Updated the example to match stompest API changes




> Python stompest tests do not work with newer releases
> -
>
> Key: AMQ-6165
> URL: https://issues.apache.org/jira/browse/AMQ-6165
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Test Cases
>Affects Versions: 5.13.0
> Environment: Python 2.7
>Reporter: Ingo Weiss
>Priority: Minor
>
> The {{listener.py}} from the {{stompest}} API Python example doesn't work 
> with this error message:
> {noformat}
> Unhandled error in Deferred:
> Traceback (most recent call last):
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 393, in callback
> self._startRunCallbacks(result)
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 501, in _startRunCallbacks
> self._runCallbacks()
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 588, in _runCallbacks
> current.result = callback(current.result, *args, **kw)
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 1184, in gotResult
> _inlineCallbacks(r, g, deferred)
> ---  ---
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 1128, in _inlineCallbacks
> result = g.send(result)
>   File "listener.py", line 45, in run
> client.subscribe(destination, self.handleFrame, headers={'ack': 'auto', 
> 'id': 'required-for-STOMP-1.1'}, ack=False)
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/stompest/util/__init__.py",
>  line 16, in __checkattr
> return f(self, *args, **kwargs)
>   File 
> "/Users/iweiss/homebrew/lib/python2.7/site-packages/twisted/internet/defer.py",
>  line 1265, in unwindGenerator
> gen = f(*args, **kwargs)
> exceptions.TypeError: subscribe() got an unexpected keyword argument 'ack'
> {noformat}



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

[jira] [Commented] (AMQ-6036) Too trivial check in SubQueueSelectorCacheBroker.hasWildcards

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-6036:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq/pull/156


> Too trivial check in SubQueueSelectorCacheBroker.hasWildcards
> -
>
> Key: AMQ-6036
> URL: https://issues.apache.org/jira/browse/AMQ-6036
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.12.1, 5.13.0
>Reporter: Patrik Dudits
>Assignee: Christopher L. Shannon
> Fix For: 5.14.0
>
>
> VirtualSelectorCache plugin cannot be reliably used when message selectors 
> use e. g. literals with underscore like {{notificationType = 
> 'NOTIFY_DELETE'}}.
> Full evaluation would need to walk the parsed selector, however the method 
> should at least check for presence of {{LIKE}} case-insensitevely to return 
> less false positives.



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

[jira] [Commented] (ARTEMIS-385) Race between topology update and connection creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-385:


Github user asfgit closed the pull request at:

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


> Race between topology update and connection creation
> 
>
> Key: ARTEMIS-385
> URL: https://issues.apache.org/jira/browse/ARTEMIS-385
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> MultipleThreadsOpeningTest will fail eventually because of this.
> avax.jms.JMSException: Failed to create session factory
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:727)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:229)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.cluster.MultipleThreadsOpeningTest$1ThreadOpen.run(MultipleThreadsOpeningTest.java:59)
> Caused by: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT 
> message=AMQ119013: Timed out waiting to receive cluster topology. Group:null]
>   at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:861)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
>   ... 3 more



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

[jira] [Commented] (ARTEMIS-376) NPE occurs when backup handover to live

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-376:


GitHub user jbertram opened a pull request:

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

ARTEMIS-376 NPE during fail-back



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

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

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

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


commit 5a483f922a63729f4d16904c6ea4f985c9a49b41
Author: jbertram 
Date:   2016-02-04T20:20:02Z

ARTEMIS-376 NPE during fail-back




> NPE occurs when backup handover to live
> ---
>
> Key: ARTEMIS-376
> URL: https://issues.apache.org/jira/browse/ARTEMIS-376
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Howard Nguyen
> Attachments: backup1-artemis.log, backup2-artemis.log, 
> backup3-artemis.log, backup4-artemis.log, live1-artemis.log, 
> live2-artemis.log, live3-artemis.log, live4-artemis.log
>
>
> Producing project:
> https://github.com/khaing211/artemis-cluster-example
> See all attached logs from all the nodes.
> exception from backup1 node
> {code}
> 13:32:29,953 ERROR [org.apache.activemq.artemis.core.client] AMQ214014: 
> Failed to execute failure listener: java.lang.NullPointerException
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation$ReplicationFailureListener.connectionClosed(SharedNothingLiveActivation.java:233)
>  [artemis-server-1.2.0.jar:1.2.0]
> at 
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callClosingListeners(AbstractRemotingConnection.java:84)
>  [artemis-core-client-1.2.0.jar:1.2.0]
> at 
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.destroy(RemotingConnectionImpl.java:233)
>  [artemis-core-client-1.2.0.jar:1.2.0]
> at 
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:529)
>  [artemis-server-1.2.0.jar:1.2.0]
> at 
> org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:667)
>  [artemis-server-1.2.0.jar:1.2.0]
> at 
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelInactive(ActiveMQChannelHandler.java:75)
>  [artemis-core-client-1.2.0.jar:1.2.0]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:208)
>  [netty-all-4.0.32.Final.jar:4.0.32.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:194)
>  [netty-all-4.0.32.Final.jar:4.0.32.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:328)
>  [netty-all-4.0.32.Final.jar:4.0.32.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:208)
>  [netty-all-4.0.32.Final.jar:4.0.32.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:194)
>  [netty-all-4.0.32.Final.jar:4.0.32.Final]
> at 
> io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:828)
>  [netty-all-4.0.32.Final.jar:4.0.32.Final]
> at 
> io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:625)
>  [netty-all-4.0.32.Final.jar:4.0.32.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
>  [netty-all-4.0.32.Final.jar:4.0.32.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357) 
> [netty-all-4.0.32.Final.jar:4.0.32.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
>  [netty-all-4.0.32.Final.jar:4.0.32.Final]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {code}



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

[jira] [Commented] (ARTEMIS-388) No obvious way to discover whether an embedded server actually started OK or not

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-388:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/381#issuecomment-181599074
  
@mikehearn  good point actually :) :+1: 


> No obvious way to discover whether an embedded server actually started OK or 
> not
> 
>
> Key: ARTEMIS-388
> URL: https://issues.apache.org/jira/browse/ARTEMIS-388
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Mike Hearn
>Assignee: Justin Bertram
>
> If I use the embedded Artemis API, then if the port it's listening on is 
> taken the server still "starts" correctly, but with the most important 
> component in a failed state! I would like to abort the startup of my app in 
> case something like this happens but I wasn't able to figure out from the 
> documentation how to actually check if all the requested 
> connectors/bridges/etc are all functioning correctly or if an exception was 
> thrown (I can see the exception in the logs, of course).



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

[jira] [Commented] (ARTEMIS-388) No obvious way to discover whether an embedded server actually started OK or not

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-388:


Github user mikehearn commented on the pull request:

https://github.com/apache/activemq-artemis/pull/381#issuecomment-181598417
  
Looks good, but javadocs?


> No obvious way to discover whether an embedded server actually started OK or 
> not
> 
>
> Key: ARTEMIS-388
> URL: https://issues.apache.org/jira/browse/ARTEMIS-388
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Mike Hearn
>Assignee: Justin Bertram
>
> If I use the embedded Artemis API, then if the port it's listening on is 
> taken the server still "starts" correctly, but with the most important 
> component in a failed state! I would like to abort the startup of my app in 
> case something like this happens but I wasn't able to figure out from the 
> documentation how to actually check if all the requested 
> connectors/bridges/etc are all functioning correctly or if an exception was 
> thrown (I can see the exception in the logs, of course).



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

[jira] [Commented] (ARTEMIS-388) No obvious way to discover whether an embedded server actually started OK or not

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-388:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/381#issuecomment-181613119
  
@jbertram  from the original JIRA, one of the issues was a netty acceptor 
not being activated because another process somewhere was already accessing it. 
I thought this was about also call a listener when the acceptor failed to init 
for instance.

I wasn't sure by just reading the diffs if that feature was implemented. 


> No obvious way to discover whether an embedded server actually started OK or 
> not
> 
>
> Key: ARTEMIS-388
> URL: https://issues.apache.org/jira/browse/ARTEMIS-388
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Mike Hearn
>Assignee: Justin Bertram
>
> If I use the embedded Artemis API, then if the port it's listening on is 
> taken the server still "starts" correctly, but with the most important 
> component in a failed state! I would like to abort the startup of my app in 
> case something like this happens but I wasn't able to figure out from the 
> documentation how to actually check if all the requested 
> connectors/bridges/etc are all functioning correctly or if an exception was 
> thrown (I can see the exception in the logs, of course).



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

[jira] [Commented] (ARTEMIS-388) No obvious way to discover whether an embedded server actually started OK or not

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-388:


Github user jbertram commented on the pull request:

https://github.com/apache/activemq-artemis/pull/381#issuecomment-181617040
  
@clebertsuconic, yes.  That's precisely the use-case I was targeting.  Note 
the test-case I added tests this explicitly.


> No obvious way to discover whether an embedded server actually started OK or 
> not
> 
>
> Key: ARTEMIS-388
> URL: https://issues.apache.org/jira/browse/ARTEMIS-388
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Mike Hearn
>Assignee: Justin Bertram
>
> If I use the embedded Artemis API, then if the port it's listening on is 
> taken the server still "starts" correctly, but with the most important 
> component in a failed state! I would like to abort the startup of my app in 
> case something like this happens but I wasn't able to figure out from the 
> documentation how to actually check if all the requested 
> connectors/bridges/etc are all functioning correctly or if an exception was 
> thrown (I can see the exception in the logs, of course).



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

[jira] [Commented] (ARTEMIS-369) [Artemis Testsuite] BridgeFailoverTest#testFailoverOnBridgeNoRetryOnSameNode fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-369:


Github user asfgit closed the pull request at:

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


> [Artemis Testsuite] BridgeFailoverTest#testFailoverOnBridgeNoRetryOnSameNode 
> fails
> --
>
> Key: ARTEMIS-369
> URL: https://issues.apache.org/jira/browse/ARTEMIS-369
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> AMQ119007: Cannot connect to server(s). Tried with all available servers.
> org.apache.activemq.artemis.api.core.ActiveMQNotConnectedException: 
> AMQ119007: Cannot connect to server(s). Tried with all available servers.
>   at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:777)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.bridge.BridgeFailoverTest.internalTestFailoverOnBridge(BridgeFailoverTest.java:191)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.bridge.BridgeFailoverTest.testFailoverOnBridgeNoRetryOnSameNode(BridgeFailoverTest.java:96)
> {code}
> There is wrong wait condition. In the test we check if backup server started 
> after failover, but we should check whether backup server activated.



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

[jira] [Commented] (ARTEMIS-368) [Artemis Testsuite] TemporaryQueueTest#testBlockingWithTemporaryQueue fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-368:


Github user asfgit closed the pull request at:

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


> [Artemis Testsuite] TemporaryQueueTest#testBlockingWithTemporaryQueue fails
> ---
>
> Key: ARTEMIS-368
> URL: https://issues.apache.org/jira/browse/ARTEMIS-368
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> expected:<737> but was:<736>
> java.lang.AssertionError: expected:<737> but was:<736>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.artemis.tests.integration.client.TemporaryQueueTest.testBlockingWithTemporaryQueue(TemporaryQueueTest.java:600)
> {code}
> There is while cycle which check whether producer is blocked and thus 
> temporary queue is full. Sometimes it can happen that producer spend all his 
> credits too fast and he is blocked because he waits to receive credits from 
> server, but the queue is not full. We have to ensure that the producer is 
> blocked due to full queue and it is not just temporary state.



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

[jira] [Commented] (ARTEMIS-368) [Artemis Testsuite] TemporaryQueueTest#testBlockingWithTemporaryQueue fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-368:


GitHub user dudaerich opened a pull request:

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

ARTEMIS-368 - [Artemis Testsuite] TemporaryQueueTest#testBlockingWith…

…TemporaryQueue fails

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

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-368

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

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


commit 3663f4c01e69f315ea806530b78a791789d6a8ee
Author: Erich Duda 
Date:   2016-01-29T08:57:49Z

ARTEMIS-368 - [Artemis Testsuite] 
TemporaryQueueTest#testBlockingWithTemporaryQueue fails




> [Artemis Testsuite] TemporaryQueueTest#testBlockingWithTemporaryQueue fails
> ---
>
> Key: ARTEMIS-368
> URL: https://issues.apache.org/jira/browse/ARTEMIS-368
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> expected:<737> but was:<736>
> java.lang.AssertionError: expected:<737> but was:<736>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.artemis.tests.integration.client.TemporaryQueueTest.testBlockingWithTemporaryQueue(TemporaryQueueTest.java:600)
> {code}
> There is while cycle which check whether producer is blocked and thus 
> temporary queue is full. Sometimes it can happen that producer spend all his 
> credits too fast and he is blocked because he waits to receive credits from 
> server, but the queue is not full. We have to ensure that the producer is 
> blocked due to full queue and it is not just temporary state.



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

[jira] [Commented] (ARTEMIS-369) [Artemis Testsuite] BridgeFailoverTest#testFailoverOnBridgeNoRetryOnSameNode fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-369:


GitHub user dudaerich opened a pull request:

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

ARTEMIS-369 - [Artemis Testsuite] BridgeFailoverTest#testFailoverOnBr…

…idgeNoRetryOnSameNode fails

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

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-369

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

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


commit 1a181ff2c05e91734ad542484c08157b6a558321
Author: Erich Duda 
Date:   2016-01-29T12:41:33Z

ARTEMIS-369 - [Artemis Testsuite] 
BridgeFailoverTest#testFailoverOnBridgeNoRetryOnSameNode fails




> [Artemis Testsuite] BridgeFailoverTest#testFailoverOnBridgeNoRetryOnSameNode 
> fails
> --
>
> Key: ARTEMIS-369
> URL: https://issues.apache.org/jira/browse/ARTEMIS-369
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> AMQ119007: Cannot connect to server(s). Tried with all available servers.
> org.apache.activemq.artemis.api.core.ActiveMQNotConnectedException: 
> AMQ119007: Cannot connect to server(s). Tried with all available servers.
>   at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:777)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.bridge.BridgeFailoverTest.internalTestFailoverOnBridge(BridgeFailoverTest.java:191)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.bridge.BridgeFailoverTest.testFailoverOnBridgeNoRetryOnSameNode(BridgeFailoverTest.java:96)
> {code}
> There is wrong wait condition. In the test we check if backup server started 
> after failover, but we should check whether backup server activated.



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

[jira] [Commented] (AMQ-6150) Found (and fixed) 3 instances of impossible casts in the activemq code

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-6150:
-

GitHub user mbreslow opened a pull request:

https://github.com/apache/activemq/pull/166

Fix AMQ-6150 (Found 3 instances of impossible casts in the activemq code)

Running static analysis on activemq I was able to identify 3 instances of 
impossible casts in the code. This pull request resolves them.

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

$ git pull https://github.com/DevFactory/activemq 
AMQ-6150-fix-impossible-cast-issues

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

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


commit 364e10d40569042595ec27ae710c2fd687fa2746
Author: Marc Breslow 
Date:   2016-01-28T21:39:29Z

Fix Impossible Cast issues in MemoryTopicSub:
- recoverSubscription()
-- map is defined as LinkedHashMap
-- msg is defined as  entry.getValue() so must be a Message
-- condition if (msg.getClass() == MessageId.class) could never be true
-- no need to cast at all when using generics

- recoverNextMessages()
-- basically same code copy/pasted so same fix

commit 61f951d0c811b8c9dcde306fa7843aadce70d199
Author: Marc Breslow 
Date:   2016-01-29T15:51:18Z

Removed 2 conditions from ServerSessionPoolImpl that would result in 
impossible casts. Conditions removed were trying to cast ActiveMQQueueSession 
and ActiveMQTopicSession to ActiveMQSession which is illegal.

Since it isn't obvious what to do if you get an ActiveMQQueueSession or 
ActiveMQTopicSession from getServerSession() I make it fall back to the else 
condition which raises an async exception. This is better than getting a 
ClassCastException at runtime.

commit f177a52c62336115dc3df7af0694851046ae670c
Author: Marc Breslow 
Date:   2016-01-29T16:00:31Z

Remove impossible cast in MemoryMessageStore

commit 509fe1ce8f3e1a6b5b64be4a027487e9c11737a6
Author: Marc Breslow 
Date:   2016-01-29T16:11:30Z

Merge branch 'master' into AMQ-6150-fix-impossible-cast-issues




> Found (and fixed) 3 instances of impossible casts in the activemq code
> --
>
> Key: AMQ-6150
> URL: https://issues.apache.org/jira/browse/AMQ-6150
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.0
>Reporter: Marc Breslow
>Priority: Critical
> Attachments: 0001-Fix-Impossible-Cast-issues-in-MemoryTopicSub.patch, 
> 0002-Removed-2-conditions-from-ServerSessionPoolImpl-that.patch, 
> 0003-Remove-impossible-cast-in-MemoryMessageStore.patch
>
>
> Running static analysis on activemq I was able to identify 3 instances of 
> impossible casts in the code. Attaching patch files to fix.



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-362:


GitHub user l-dobrev opened a pull request:

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

Fix for ARTEMIS-362

Fix for https://issues.apache.org/jira/browse/ARTEMIS-362

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

$ git pull https://github.com/l-dobrev/activemq-artemis master

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

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


commit 6c6a237aa276ce7411bcf241495f19d1fff877ee
Author: Lachezar Dobrev 
Date:   2016-01-26T11:03:29Z

Fix for ARTEMIS-362




> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (ARTEMIS-357) Possible encoding race over many destinations

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-357:


GitHub user clebertsuconic opened a pull request:

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

ARTEMIS-357 fixing an issue created by my previous commit on this

@jbertram  helped figuring out the growing buffer issue

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

$ git pull https://github.com/clebertsuconic/activemq-artemis master

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

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


commit 4c22138f5b85ea36e546058bfea02788ab1cf95f
Author: jbertram 
Date:   2016-01-26T18:51:45Z

ARTEMIS-357 test for client buffer mod

commit eb6e042c1c35e5f7de10aa03dd29b45f624e636a
Author: Clebert Suconic 
Date:   2016-01-27T03:30:24Z

ARTEMIS-357 fixing issue with Messages Growing after JMS sends (after my 
last change on ARTEMIS-357)




> Possible encoding race over many destinations
> -
>
> Key: ARTEMIS-357
> URL: https://issues.apache.org/jira/browse/ARTEMIS-357
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
>
> There seems to be a possibility of a race on messageImpl:encodeToBuffer
> The current implementation try to reuse the buffer sent on producer on an 
> optimization that was used when we were on Netty Blocking.
> We have been reported of cases where the client can't decode the message:



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

[jira] [Commented] (ARTEMIS-357) Possible encoding race over many destinations

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-357:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/350#issuecomment-175383216
  
Tests are broken though.. will have to look tomorrow


> Possible encoding race over many destinations
> -
>
> Key: ARTEMIS-357
> URL: https://issues.apache.org/jira/browse/ARTEMIS-357
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
>
> There seems to be a possibility of a race on messageImpl:encodeToBuffer
> The current implementation try to reuse the buffer sent on producer on an 
> optimization that was used when we were on Netty Blocking.
> We have been reported of cases where the client can't decode the message:



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

[jira] [Commented] (ARTEMIS-357) Possible encoding race over many destinations

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-357:


Github user jbertram commented on the pull request:

https://github.com/apache/activemq-artemis/pull/350#issuecomment-175378662
  
Nice work, @clebertsuconic. Glad we squashed this bug.


> Possible encoding race over many destinations
> -
>
> Key: ARTEMIS-357
> URL: https://issues.apache.org/jira/browse/ARTEMIS-357
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
>
> There seems to be a possibility of a race on messageImpl:encodeToBuffer
> The current implementation try to reuse the buffer sent on producer on an 
> optimization that was used when we were on Netty Blocking.
> We have been reported of cases where the client can't decode the message:



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

[jira] [Commented] (ARTEMIS-357) Possible encoding race over many destinations

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-357:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/350#issuecomment-175393266
  
fixed the tests


> Possible encoding race over many destinations
> -
>
> Key: ARTEMIS-357
> URL: https://issues.apache.org/jira/browse/ARTEMIS-357
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
>
> There seems to be a possibility of a race on messageImpl:encodeToBuffer
> The current implementation try to reuse the buffer sent on producer on an 
> optimization that was used when we were on Netty Blocking.
> We have been reported of cases where the client can't decode the message:



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

[jira] [Commented] (ARTEMIS-365) [Artemis Testsuite] AddressControlTest#testGetNumberOfPages fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-365:


Github user dudaerich commented on the pull request:

https://github.com/apache/activemq-artemis/pull/355#issuecomment-175693517
  
@clebertsuconic, you're welcome :) Yes, I've tested it with master and it's 
ok now.


> [Artemis Testsuite] AddressControlTest#testGetNumberOfPages fails
> -
>
> Key: ARTEMIS-365
> URL: https://issues.apache.org/jira/browse/ARTEMIS-365
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: expected:<1> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.artemis.tests.integration.management.AddressControlTest.testGetNumberOfPages(AddressControlTest.java:222)
> {code}



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

[jira] [Commented] (ARTEMIS-364) [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-364:


Github user asfgit closed the pull request at:

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


> [Artemis Testsuite] PagingTest#testPagingDifferentSizes fails
> -
>
> Key: ARTEMIS-364
> URL: https://issues.apache.org/jira/browse/ARTEMIS-364
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: null
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertTrue(Assert.java:52)
>   at 
> org.apache.activemq.artemis.tests.integration.client.PagingTest.testPagingDifferentSizes(PagingTest.java:3576)
> {code}



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

[jira] [Commented] (ARTEMIS-365) [Artemis Testsuite] AddressControlTest#testGetNumberOfPages fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-365:


Github user asfgit closed the pull request at:

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


> [Artemis Testsuite] AddressControlTest#testGetNumberOfPages fails
> -
>
> Key: ARTEMIS-365
> URL: https://issues.apache.org/jira/browse/ARTEMIS-365
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: expected:<1> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.artemis.tests.integration.management.AddressControlTest.testGetNumberOfPages(AddressControlTest.java:222)
> {code}



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

[jira] [Commented] (ARTEMIS-377) [Artemis Testsuite] NettySecurityClientTest#testProducerConsumerClientWithSecurityManager fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-377:


GitHub user dudaerich opened a pull request:

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

ARTEMIS-377 - [Artemis Testsuite] NettySecurityClientTest#testProduce…

…rConsumerClientWithSecurityManager fails

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

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-377

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

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


commit 8842b9e38a646ea2fccf2aff77f6b2e87141
Author: Erich Duda 
Date:   2016-02-01T09:27:37Z

ARTEMIS-377 - [Artemis Testsuite] 
NettySecurityClientTest#testProducerConsumerClientWithSecurityManager fails




> [Artemis Testsuite] 
> NettySecurityClientTest#testProducerConsumerClientWithSecurityManager fails
> ---
>
> Key: ARTEMIS-377
> URL: https://issues.apache.org/jira/browse/ARTEMIS-377
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> client VM did not exit cleanly expected:<0> but was:<1>
> java.lang.AssertionError: client VM did not exit cleanly expected:<0> but 
> was:<1>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at 
> org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.doTestProducerConsumerClient(NettySecurityClientTest.java:96)
>   at 
> org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.testProducerConsumerClientWithSecurityManager(NettySecurityClientTest.java:45)
> {code}
> The test has two problems:
> 1. Method {{URL.getPath()}} encode special characters with {{%}} sign. We 
> should use {{URLDecoder.decode()}} to decode these characters.
> 2. When we run the test with IBM JDK, the additional permission is needed.



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

[jira] [Commented] (AMQ-6150) Found (and fixed) 3 instances of impossible casts in the activemq code

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-6150:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq/pull/166


> Found (and fixed) 3 instances of impossible casts in the activemq code
> --
>
> Key: AMQ-6150
> URL: https://issues.apache.org/jira/browse/AMQ-6150
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.0
>Reporter: Marc Breslow
>Assignee: Christopher L. Shannon
>Priority: Critical
> Attachments: 0001-Fix-Impossible-Cast-issues-in-MemoryTopicSub.patch, 
> 0002-Removed-2-conditions-from-ServerSessionPoolImpl-that.patch, 
> 0003-Remove-impossible-cast-in-MemoryMessageStore.patch
>
>
> Running static analysis on activemq I was able to identify 3 instances of 
> impossible casts in the code. Attaching patch files to fix.



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

[jira] [Commented] (ARTEMIS-374) Support scheduled messages on last-value queue

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-374:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/362#issuecomment-178063508
  
@jbertram it's set during routing on PostOfficeImpl.
it should be set by the time you get there.


> Support scheduled messages on last-value queue
> --
>
> Key: ARTEMIS-374
> URL: https://issues.apache.org/jira/browse/ARTEMIS-374
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Commented] (ARTEMIS-374) Support scheduled messages on last-value queue

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-374:


Github user jbertram commented on the pull request:

https://github.com/apache/activemq-artemis/pull/362#issuecomment-178061415
  
I'm not following.  From what I can tell in addHead() (where I need to do 
the check) Rreference.getScheduledDeliveryTime() will always return 0 so 
there's no way to differentiate scheduled messages from non-scheduled messages 
by using this property.  Can you clarify your suggestion?


> Support scheduled messages on last-value queue
> --
>
> Key: ARTEMIS-374
> URL: https://issues.apache.org/jira/browse/ARTEMIS-374
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Commented] (ARTEMIS-378) expose some Network info via the management interfaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-378:


GitHub user andytaylor opened a pull request:

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

ARTEMIS-378 - expose some Network info via the management interfaces

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

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

$ git pull https://github.com/andytaylor/activemq-artemis master

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

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


commit ecfa1fecc2263d2e26e84677112844ce3acb2226
Author: Andy Taylor 
Date:   2016-02-01T12:11:28Z

ARTEMIS-378 - expose some Network info via the management interfaces

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




> expose some Network info via the management interfaces
> --
>
> Key: ARTEMIS-378
> URL: https://issues.apache.org/jira/browse/ARTEMIS-378
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 1.1.0
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.2.0
>
>




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

[jira] [Commented] (ARTEMIS-374) Support scheduled messages on last-value queue

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-374:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/362#issuecomment-178052072
  
Look at Reference.getDeliveryTime(). it will be set to 0 during the 
Scheduling handler. It seems that's what you need, no need for any other 
property.

if (getDeliveryTime()==0).. go directly to the head.. same as if it had 
your property (I think)


I don't see a need for a new property


> Support scheduled messages on last-value queue
> --
>
> Key: ARTEMIS-374
> URL: https://issues.apache.org/jira/browse/ARTEMIS-374
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Commented] (ARTEMIS-385) Race between topology update and connection creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-385:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/369#issuecomment-179582606
  
@jbertram  this could be related to the issue you were hitting on backup?


> Race between topology update and connection creation
> 
>
> Key: ARTEMIS-385
> URL: https://issues.apache.org/jira/browse/ARTEMIS-385
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> MultipleThreadsOpeningTest will fail eventually because of this.
> avax.jms.JMSException: Failed to create session factory
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:727)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:229)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.cluster.MultipleThreadsOpeningTest$1ThreadOpen.run(MultipleThreadsOpeningTest.java:59)
> Caused by: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT 
> message=AMQ119013: Timed out waiting to receive cluster topology. Group:null]
>   at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:861)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
>   ... 3 more



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

[jira] [Commented] (ARTEMIS-385) Race between topology update and connection creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-385:


Github user jbertram commented on the pull request:

https://github.com/apache/activemq-artemis/pull/369#issuecomment-179587849
  
@clebertsuconic, I certainly think it's possible.  However, I haven't dug 
into that issue much as I've been working on other tasks so I can't say for 
sure.


> Race between topology update and connection creation
> 
>
> Key: ARTEMIS-385
> URL: https://issues.apache.org/jira/browse/ARTEMIS-385
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> MultipleThreadsOpeningTest will fail eventually because of this.
> avax.jms.JMSException: Failed to create session factory
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:727)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:229)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.cluster.MultipleThreadsOpeningTest$1ThreadOpen.run(MultipleThreadsOpeningTest.java:59)
> Caused by: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT 
> message=AMQ119013: Timed out waiting to receive cluster topology. Group:null]
>   at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:861)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
>   ... 3 more



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

[jira] [Commented] (ARTEMIS-385) Race between topology update and connection creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-385:


GitHub user clebertsuconic opened a pull request:

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

ARTEMIS-385 fixing race



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

$ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-385

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

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


commit ba7e11a54c6b487b2d2fc5a970fe1521bcf69906
Author: Clebert Suconic 
Date:   2016-02-04T02:14:26Z

ARTEMIS-385 On a possible race the Topology final notification may get lost 
when using many connection factories

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

This fix will make sure we only wait for the topologies that are arriving 
from the current connection over the createFactory method




> Race between topology update and connection creation
> 
>
> Key: ARTEMIS-385
> URL: https://issues.apache.org/jira/browse/ARTEMIS-385
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> MultipleThreadsOpeningTest will fail eventually because of this.
> avax.jms.JMSException: Failed to create session factory
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:727)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:233)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:229)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.cluster.MultipleThreadsOpeningTest$1ThreadOpen.run(MultipleThreadsOpeningTest.java:59)
> Caused by: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT 
> message=AMQ119013: Timed out waiting to receive cluster topology. Group:null]
>   at 
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:861)
>   at 
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:724)
>   ... 3 more



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

[jira] [Commented] (ARTEMIS-374) Support scheduled messages on last-value queue

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-374:


GitHub user jbertram opened a pull request:

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

ARTEMIS-374 support schedule messages on LVQ



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

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

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

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


commit d54739239bac05f82e4599f9e6936d9814ad0c86
Author: jbertram 
Date:   2016-01-27T22:15:59Z

ARTEMIS-374 support schedule messages on LVQ




> Support scheduled messages on last-value queue
> --
>
> Key: ARTEMIS-374
> URL: https://issues.apache.org/jira/browse/ARTEMIS-374
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Commented] (ARTEMIS-381) [Artemis Testsuite] LargeMessageOverBridgeTest.testSendBytesAsLargeOnBridgeOnly fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-381:


Github user asfgit closed the pull request at:

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


> [Artemis Testsuite] 
> LargeMessageOverBridgeTest.testSendBytesAsLargeOnBridgeOnly fails
> -
>
> Key: ARTEMIS-381
> URL: https://issues.apache.org/jira/browse/ARTEMIS-381
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: null
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertNotNull(Assert.java:621)
>   at org.junit.Assert.assertNotNull(Assert.java:631)
>   at 
> org.apache.activemq.artemis.tests.integration.jms.cluster.LargeMessageOverBridgeTest.testSendBytesAsLargeOnBridgeOnly(LargeMessageOverBridgeTest.java:210)
> {code}
> Problem is in redistribution-delay property which is defaul set on -1. It 
> means that messages shouldn't be redistributed.



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

[jira] [Commented] (ARTEMIS-357) Possible encoding race over many destinations

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-357:


Github user asfgit closed the pull request at:

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


> Possible encoding race over many destinations
> -
>
> Key: ARTEMIS-357
> URL: https://issues.apache.org/jira/browse/ARTEMIS-357
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
>
> There seems to be a possibility of a race on messageImpl:encodeToBuffer
> The current implementation try to reuse the buffer sent on producer on an 
> optimization that was used when we were on Netty Blocking.
> We have been reported of cases where the client can't decode the message:



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

[jira] [Commented] (ARTEMIS-379) [Artemis Testsuite] BackupSyncLargeMessageTest.testReserveFileIdValuesOnBackup fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-379:


GitHub user dudaerich opened a pull request:

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

ARTEMIS-379 - [Artemis Testsuite] BackupSyncLargeMessageTest.testRese…

…rveFileIdValuesOnBackup fails

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

$ git pull https://github.com/dudaerich/activemq-artemis ARTEMIS-379

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

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


commit f0245dbd793f548213eb2d3375fb261983ac51b2
Author: Erich Duda 
Date:   2016-02-01T14:51:18Z

ARTEMIS-379 - [Artemis Testsuite] 
BackupSyncLargeMessageTest.testReserveFileIdValuesOnBackup fails




> [Artemis Testsuite] 
> BackupSyncLargeMessageTest.testReserveFileIdValuesOnBackup fails
> 
>
> Key: ARTEMIS-379
> URL: https://issues.apache.org/jira/browse/ARTEMIS-379
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> backup started? (true). Finished synchronizing 
> (org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation@17f62e33).
>  SessionFactory!=null ? true || sessionFactory.getBackupConnector()==null
> java.lang.AssertionError: backup started? (true). Finished synchronizing 
> (org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation@17f62e33).
>  SessionFactory!=null ? true || sessionFactory.getBackupConnector()==null
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> org.apache.activemq.artemis.tests.util.ActiveMQTestBase.waitForRemoteBackup(ActiveMQTestBase.java:1330)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.failover.BackupSyncJournalTest.testReserveFileIdValuesOnBackup(BackupSyncJournalTest.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

[jira] [Commented] (ARTEMIS-378) expose some Network info via the management interfaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-378:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/365#issuecomment-178003192
  
look good, merging it


> expose some Network info via the management interfaces
> --
>
> Key: ARTEMIS-378
> URL: https://issues.apache.org/jira/browse/ARTEMIS-378
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 1.1.0
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.2.0
>
>




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

[jira] [Commented] (ARTEMIS-378) expose some Network info via the management interfaces

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-378:


Github user asfgit closed the pull request at:

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


> expose some Network info via the management interfaces
> --
>
> Key: ARTEMIS-378
> URL: https://issues.apache.org/jira/browse/ARTEMIS-378
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 1.1.0
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.2.0
>
>




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

[jira] [Commented] (ARTEMIS-377) [Artemis Testsuite] NettySecurityClientTest#testProducerConsumerClientWithSecurityManager fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-377:


Github user asfgit closed the pull request at:

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


> [Artemis Testsuite] 
> NettySecurityClientTest#testProducerConsumerClientWithSecurityManager fails
> ---
>
> Key: ARTEMIS-377
> URL: https://issues.apache.org/jira/browse/ARTEMIS-377
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> client VM did not exit cleanly expected:<0> but was:<1>
> java.lang.AssertionError: client VM did not exit cleanly expected:<0> but 
> was:<1>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at 
> org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.doTestProducerConsumerClient(NettySecurityClientTest.java:96)
>   at 
> org.apache.activemq.artemis.tests.integration.security.NettySecurityClientTest.testProducerConsumerClientWithSecurityManager(NettySecurityClientTest.java:45)
> {code}
> The test has two problems:
> 1. Method {{URL.getPath()}} encode special characters with {{%}} sign. We 
> should use {{URLDecoder.decode()}} to decode these characters.
> 2. When we run the test with IBM JDK, the additional permission is needed.



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

[jira] [Commented] (ARTEMIS-379) [Artemis Testsuite] BackupSyncLargeMessageTest.testReserveFileIdValuesOnBackup fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-379:


Github user asfgit closed the pull request at:

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


> [Artemis Testsuite] 
> BackupSyncLargeMessageTest.testReserveFileIdValuesOnBackup fails
> 
>
> Key: ARTEMIS-379
> URL: https://issues.apache.org/jira/browse/ARTEMIS-379
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> backup started? (true). Finished synchronizing 
> (org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation@17f62e33).
>  SessionFactory!=null ? true || sessionFactory.getBackupConnector()==null
> java.lang.AssertionError: backup started? (true). Finished synchronizing 
> (org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation@17f62e33).
>  SessionFactory!=null ? true || sessionFactory.getBackupConnector()==null
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> org.apache.activemq.artemis.tests.util.ActiveMQTestBase.waitForRemoteBackup(ActiveMQTestBase.java:1330)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.failover.BackupSyncJournalTest.testReserveFileIdValuesOnBackup(BackupSyncJournalTest.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

[jira] [Commented] (ARTEMIS-374) Support scheduled messages on last-value queue

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-374:


Github user jbertram commented on the pull request:

https://github.com/apache/activemq-artemis/pull/362#issuecomment-178012905
  
I need some way to differentiate messages that are put on the head of the 
queue by the scheduler and those that aren't because they need to be treated 
differently (notice the new 'if' block in addHead()).  A message property 
seemed the simplest way to do that, but I'm open to other possibilities.  Do 
you have any suggestions here?


> Support scheduled messages on last-value queue
> --
>
> Key: ARTEMIS-374
> URL: https://issues.apache.org/jira/browse/ARTEMIS-374
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Commented] (ARTEMIS-350) possible OOM in replication manager

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-350:


Github user asfgit closed the pull request at:

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


> possible OOM in replication manager
> ---
>
> Key: ARTEMIS-350
> URL: https://issues.apache.org/jira/browse/ARTEMIS-350
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.3.0
>
>
> This is becausee we have no flow control, we need to throttle back when the 
> channel is not writable



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

[jira] [Commented] (AMQ-6181) Upgrade to Joda-time 2.9

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-6181:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq/pull/169


> Upgrade to Joda-time 2.9
> 
>
> Key: AMQ-6181
> URL: https://issues.apache.org/jira/browse/AMQ-6181
> Project: ActiveMQ
>  Issue Type: Task
>  Components: karaf
>Reporter: Andrea Cosentino
>Priority: Minor
> Fix For: 5.14.0
>
>
> Since joda-time is stable on 2.9.x I think it is good to upgrade the bundle 
> used in activemq-karaf



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

[jira] [Commented] (ARTEMIS-421) wrong XA_RETRY XAException error code returned on crash for 1PC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-421:


Github user gaohoward commented on the pull request:

https://github.com/apache/activemq-artemis/pull/403#issuecomment-188268825
  
It's checkstyle error. I'll fix it.


> wrong XA_RETRY XAException error code returned on crash for 1PC
> ---
>
> Key: ARTEMIS-421
> URL: https://issues.apache.org/jira/browse/ARTEMIS-421
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Critical
> Fix For: 1.2.0
>
>
> According to XA spec you can't return XA_RETRY from xa_commit(TMONEPHASE) and 
> that RMFAIL should be returned.
> Currently artemis always return XA_RETRY regardless of one_phase flag.



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

[jira] [Commented] (ARTEMIS-421) wrong XA_RETRY XAException error code returned on crash for 1PC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-421:


GitHub user gaohoward opened a pull request:

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

ARTEMIS-421 wrong XA_RETRY XAException error code returned on crash for 1PC

ARTEMIS-421 wrong XA_RETRY XAException error code returned on crash for 1PC

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

$ git pull https://github.com/gaohoward/activemq-artemis artemis421

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

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


commit 19fe7fd595566236788929afe26e9cebedce9ce7
Author: Howard Gao 
Date:   2016-02-24T10:54:45Z

ARTEMIS-421 wrong XA_RETRY XAException error code
returned on crash for 1PC




> wrong XA_RETRY XAException error code returned on crash for 1PC
> ---
>
> Key: ARTEMIS-421
> URL: https://issues.apache.org/jira/browse/ARTEMIS-421
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Critical
> Fix For: 1.2.0
>
>
> According to XA spec you can't return XA_RETRY from xa_commit(TMONEPHASE) and 
> that RMFAIL should be returned.
> Currently artemis always return XA_RETRY regardless of one_phase flag.



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

[jira] [Commented] (ARTEMIS-421) wrong XA_RETRY XAException error code returned on crash for 1PC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-421:


Github user asfgit closed the pull request at:

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


> wrong XA_RETRY XAException error code returned on crash for 1PC
> ---
>
> Key: ARTEMIS-421
> URL: https://issues.apache.org/jira/browse/ARTEMIS-421
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Critical
> Fix For: 1.2.0
>
>
> According to XA spec you can't return XA_RETRY from xa_commit(TMONEPHASE) and 
> that RMFAIL should be returned.
> Currently artemis always return XA_RETRY regardless of one_phase flag.



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

[jira] [Commented] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-359:


GitHub user clebertsuconic opened a pull request:

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

Revert "ARTEMIS-359 - test suite fix - IBM JDK 6/7/8 does not allow b…

…yteman agent to modify classes."

This is causing issues with running tests on the IDEs

This reverts commit fe9b95ed64821c6ed63564a0c0ba9792123823b3.

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

$ git pull https://github.com/clebertsuconic/activemq-artemis revert

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

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


commit d12ccbf63a2795455b3a0db85a6eb0463bbc6c7d
Author: Clebert Suconic 
Date:   2016-02-24T17:00:30Z

Revert "ARTEMIS-359 - test suite fix - IBM JDK 6/7/8 does not allow byteman 
agent to modify classes."

This is causing issues with running tests on the IDEs

This reverts commit fe9b95ed64821c6ed63564a0c0ba9792123823b3.




> [TestSuite] IBM JDK does not allow to instrument classes
> 
>
> Key: ARTEMIS-359
> URL: https://issues.apache.org/jira/browse/ARTEMIS-359
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Miroslav Novak
> Fix For: 1.3.0
>
>
> IBM JDK 6/7/8 does not allow byteman agent to modify classes. For example 
> "extra-tests" will fail with following exception:
> {code}
> Running 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> byteman jar is 
> /home/mnovak/.m2/repository/org/jboss/byteman/byteman/2.2.0/byteman-2.2.0.jar
> com.ibm.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:401)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.attachTarget(VirtualMachineImpl.java:94)
>   at 
> com.ibm.tools.attach.javaSE.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:37)
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:55)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:472)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:98)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.net.SocketTimeoutException: Accept timed out
>   at 
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:445)
>   at java.net.ServerSocket.implAccept(ServerSocket.java:620)
>   at java.net.ServerSocket.accept(ServerSocket.java:579)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:396)
>   ... 17 more
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 291.094 sec 
> <<< FAILURE! - in 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest(org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest)
>   Time elapsed: 291.094 sec  <<< ERROR!
> com.sun.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
>   at 

[jira] [Commented] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-359:


Github user asfgit closed the pull request at:

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


> [TestSuite] IBM JDK does not allow to instrument classes
> 
>
> Key: ARTEMIS-359
> URL: https://issues.apache.org/jira/browse/ARTEMIS-359
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Miroslav Novak
> Fix For: 1.3.0
>
>
> IBM JDK 6/7/8 does not allow byteman agent to modify classes. For example 
> "extra-tests" will fail with following exception:
> {code}
> Running 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> byteman jar is 
> /home/mnovak/.m2/repository/org/jboss/byteman/byteman/2.2.0/byteman-2.2.0.jar
> com.ibm.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:401)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.attachTarget(VirtualMachineImpl.java:94)
>   at 
> com.ibm.tools.attach.javaSE.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:37)
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:55)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:472)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:98)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.net.SocketTimeoutException: Accept timed out
>   at 
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:445)
>   at java.net.ServerSocket.implAccept(ServerSocket.java:620)
>   at java.net.ServerSocket.accept(ServerSocket.java:579)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:396)
>   ... 17 more
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 291.094 sec 
> <<< FAILURE! - in 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest(org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest)
>   Time elapsed: 291.094 sec  <<< ERROR!
> com.sun.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:472)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:98)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> 

[jira] [Commented] (ARTEMIS-350) possible OOM in replication manager

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-350:


Github user asfgit closed the pull request at:

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


> possible OOM in replication manager
> ---
>
> Key: ARTEMIS-350
> URL: https://issues.apache.org/jira/browse/ARTEMIS-350
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.3.0
>
>
> This is becausee we have no flow control, we need to throttle back when the 
> channel is not writable



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

[jira] [Commented] (AMQ-6188) Queues containing PERSISTENT messages can be garbage collected due to Inactivity

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-6188:
-

GitHub user bdjdev opened a pull request:

https://github.com/apache/activemq/pull/170

https://issues.apache.org/jira/browse/AMQ-6188 - reset BaseDestinatio…

Fix and test for https://issues.apache.org/jira/browse/AMQ-6188

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

$ git pull https://github.com/bdjdev/activemq AMQ-6188

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

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


commit c88bcedff0e498667db53af561ab01d03b286e0c
Author: Brian D. Johnson 
Date:   2016-02-26T20:19:50Z

https://issues.apache.org/jira/browse/AMQ-6188 - reset 
BaseDestination.lastActiveTime each time a message is delivered to the broker.




> Queues containing PERSISTENT messages can be garbage collected due to 
> Inactivity
> 
>
> Key: AMQ-6188
> URL: https://issues.apache.org/jira/browse/AMQ-6188
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.13.0, 5.13.1
>Reporter: Brian D. Johnson
>
> It is possible for a queue to be garbage collected due to inactivity despite 
> undelivered {{PERSISTENT}} messages being present on the queue.
> Order of events-
> * unused queue is marked for garbage collection due to inactivity
> * prior to garbage collection, an anonymous producer must comes online, 
> sending one or more messages, then closing
> ** Note: the queue's {{lastActiveTime}} is not reset when an anonymous 
> producer is created because they are not bound to a destination at creation.
> * queue with pending Message(s) is garbage collected
> A simple fix for this seems to be resetting 
> {{BaseDestination#lastActiveTime}} to zero each time a message is sent 
> ({{BaseDestination#messageDelivered(context, messageReference)}}).
> I'll submit a PR with a patch shortly.



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

[jira] [Commented] (ARTEMIS-422) Implement appendRollbackRecord in o.a.a.a.c.j.i.FileWrapperJournal

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-422:


GitHub user jbertram opened a pull request:

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

ARTEMIS-422 support appendRollbackRecord



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

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

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

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


commit e64ecf5523f7f5a0ce924cc4bf2666ece425f135
Author: jbertram 
Date:   2016-02-25T19:31:19Z

ARTEMIS-422 support appendRollbackRecord




> Implement appendRollbackRecord in o.a.a.a.c.j.i.FileWrapperJournal
> --
>
> Key: ARTEMIS-422
> URL: https://issues.apache.org/jira/browse/ARTEMIS-422
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>
> There are situations where replica will receive a 
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.ReplicationCommitMessage
>  where rollback = true which means 
> org.apache.activemq.artemis.core.journal.impl.FileWrapperJournal should 
> support appendRollbackRecord rather than throwing an 
> org.apache.activemq.artemis.api.core.ActiveMQUnsupportedPacketException.



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

[jira] [Commented] (ARTEMIS-422) Implement appendRollbackRecord in o.a.a.a.c.j.i.FileWrapperJournal

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-422:


Github user asfgit closed the pull request at:

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


> Implement appendRollbackRecord in o.a.a.a.c.j.i.FileWrapperJournal
> --
>
> Key: ARTEMIS-422
> URL: https://issues.apache.org/jira/browse/ARTEMIS-422
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>
> There are situations where replica will receive a 
> org.apache.activemq.artemis.core.protocol.core.impl.wireformat.ReplicationCommitMessage
>  where rollback = true which means 
> org.apache.activemq.artemis.core.journal.impl.FileWrapperJournal should 
> support appendRollbackRecord rather than throwing an 
> org.apache.activemq.artemis.api.core.ActiveMQUnsupportedPacketException.



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

[jira] [Commented] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-359:


Github user mnovak1 commented on the pull request:

https://github.com/apache/activemq-artemis/pull/404#issuecomment-188689872
  
Can we find a way to make this work in IDEA and IBM JDK as well? 


> [TestSuite] IBM JDK does not allow to instrument classes
> 
>
> Key: ARTEMIS-359
> URL: https://issues.apache.org/jira/browse/ARTEMIS-359
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Miroslav Novak
> Fix For: 1.3.0
>
>
> IBM JDK 6/7/8 does not allow byteman agent to modify classes. For example 
> "extra-tests" will fail with following exception:
> {code}
> Running 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> byteman jar is 
> /home/mnovak/.m2/repository/org/jboss/byteman/byteman/2.2.0/byteman-2.2.0.jar
> com.ibm.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:401)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.attachTarget(VirtualMachineImpl.java:94)
>   at 
> com.ibm.tools.attach.javaSE.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:37)
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:55)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:472)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:98)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.net.SocketTimeoutException: Accept timed out
>   at 
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:445)
>   at java.net.ServerSocket.implAccept(ServerSocket.java:620)
>   at java.net.ServerSocket.accept(ServerSocket.java:579)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:396)
>   ... 17 more
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 291.094 sec 
> <<< FAILURE! - in 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest(org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest)
>   Time elapsed: 291.094 sec  <<< ERROR!
> com.sun.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:472)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:98)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 

[jira] [Commented] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-359:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/404#issuecomment-188816973
  
Of. Course 


> [TestSuite] IBM JDK does not allow to instrument classes
> 
>
> Key: ARTEMIS-359
> URL: https://issues.apache.org/jira/browse/ARTEMIS-359
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Miroslav Novak
> Fix For: 1.3.0
>
>
> IBM JDK 6/7/8 does not allow byteman agent to modify classes. For example 
> "extra-tests" will fail with following exception:
> {code}
> Running 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> byteman jar is 
> /home/mnovak/.m2/repository/org/jboss/byteman/byteman/2.2.0/byteman-2.2.0.jar
> com.ibm.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:401)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.attachTarget(VirtualMachineImpl.java:94)
>   at 
> com.ibm.tools.attach.javaSE.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:37)
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:55)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:472)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:98)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.net.SocketTimeoutException: Accept timed out
>   at 
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:445)
>   at java.net.ServerSocket.implAccept(ServerSocket.java:620)
>   at java.net.ServerSocket.accept(ServerSocket.java:579)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:396)
>   ... 17 more
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 291.094 sec 
> <<< FAILURE! - in 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest(org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest)
>   Time elapsed: 291.094 sec  <<< ERROR!
> com.sun.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:472)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:98)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> 

[jira] [Commented] (ARTEMIS-416) Netty Acceptor allows transfer of connections when paused

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-416:


GitHub user andytaylor opened a pull request:

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

ARTEMIS-416 - Netty Acceptor allows transfer of connections when paused

Throw an exception if the acceptor is paused or not started

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

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

$ git pull https://github.com/andytaylor/activemq-artemis master

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

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


commit 3e9320a73ea16d8d74dc669b8beb64510fa58307
Author: Andy Taylor 
Date:   2016-02-22T14:26:59Z

ARTEMIS-416 - Netty Acceptor allows transfer of connections when paused

Throw an exception if the acceptor is paused or not started

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




> Netty Acceptor allows transfer of connections when paused
> -
>
> Key: ARTEMIS-416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-416
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>
> we should handle this with an exception or something similar



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

[jira] [Commented] (ARTEMIS-416) Netty Acceptor allows transfer of connections when paused

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-416:


Github user asfgit closed the pull request at:

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


> Netty Acceptor allows transfer of connections when paused
> -
>
> Key: ARTEMIS-416
> URL: https://issues.apache.org/jira/browse/ARTEMIS-416
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>
> we should handle this with an exception or something similar



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

[jira] [Commented] (ARTEMIS-415) [Artemis Testsuite] NettyPagingSendTest#testPagingDoesNotDuplicateBatchMessages

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-415:


Github user asfgit closed the pull request at:

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


> [Artemis Testsuite] 
> NettyPagingSendTest#testPagingDoesNotDuplicateBatchMessages
> ---
>
> Key: ARTEMIS-415
> URL: https://issues.apache.org/jira/browse/ARTEMIS-415
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> java.lang.AssertionError: expected:<20> but was:<13>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:743)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:555)
>   at org.junit.Assert.assertEquals(Assert.java:542)
>   at 
> org.apache.activemq.artemis.tests.integration.paging.PagingSendTest.testPagingDoesNotDuplicateBatchMessages(PagingSendTest.java:242)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   at java.lang.reflect.Method.invoke(Method.java:507)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:275)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:149)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
> This failure happens when {{Queue.deliverAsync}} is too slow and the iterator 
> is created before that aforementioned method add references to internal 
> structures.



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

[jira] [Commented] (ARTEMIS-350) possible OOM in replication manager

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-350:


GitHub user jbertram opened a pull request:

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

ARTEMIS-350 fix for potential race

It's possible for the latch used for flow control here to get out of sync. 
In
other words, multiple count-downs can occur between count-ups so that the 
latch
always has a count > 0. When this situation arises then every single packet
sent to the replica is delayed by 5 seconds.

The solution here essentially is to reset the latch back to zero every time
instead of decrementing it by one with a normal count-down. This should 
still
maintain overall flow-control, but also avoid this race condition.

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

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

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

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


commit 366316352f1e0169effb1b455832a9188aed671c
Author: jbertram 
Date:   2016-02-16T16:45:25Z

ARTEMIS-350 fix for potential race

It's possible for the latch used for flow control here to get out of sync. 
In
other words, multiple count-downs can occur between count-ups so that the 
latch
always has a count > 0. When this situation arises then every single packet
sent to the replica is delayed by 5 seconds.

The solution here essentially is to reset the latch back to zero every time
instead of decrementing it by one with a normal count-down. This should 
still
maintain overall flow-control, but also avoid this race condition.




> possible OOM in replication manager
> ---
>
> Key: ARTEMIS-350
> URL: https://issues.apache.org/jira/browse/ARTEMIS-350
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.3.0
>
>
> This is becausee we have no flow control, we need to throttle back when the 
> channel is not writable



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

[jira] [Commented] (AMQ-6181) Upgrade to Joda-time 2.9

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-6181:
-

GitHub user oscerd opened a pull request:

https://github.com/apache/activemq/pull/169

https://issues.apache.org/jira/browse/AMQ-6181 - Upgrade to Joda-time 2.9

Hi,

This PR is related to:
https://issues.apache.org/jira/browse/AMQ-6181

Thanks
Andrea

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

$ git pull https://github.com/oscerd/activemq AMQ-6181

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

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


commit 98c866817d639b596756094ed7f61279d3564afc
Author: Andrea Cosentino 
Date:   2016-02-23T14:47:52Z

AMQ-6181 - Upgrade to Joda-time 2.9




> Upgrade to Joda-time 2.9
> 
>
> Key: AMQ-6181
> URL: https://issues.apache.org/jira/browse/AMQ-6181
> Project: ActiveMQ
>  Issue Type: Task
>  Components: karaf
>Reporter: Andrea Cosentino
>Priority: Minor
> Fix For: 5.14.0
>
>
> Since joda-time is stable on 2.9.x I think it is good to upgrade the bundle 
> used in activemq-karaf



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

[jira] [Commented] (ARTEMIS-351) Report an Exception if a journal file cannot be created rather than blocking forever

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-351:


Github user asfgit closed the pull request at:

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


> Report an Exception if a journal file cannot be created rather than blocking 
> forever
> 
>
> Key: ARTEMIS-351
> URL: https://issues.apache.org/jira/browse/ARTEMIS-351
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Tom Jenkinson
>
> The architecture of the journal component is such that the next journal file 
> to create fails (executed async) then the application thread will block 
> forever in an append call and the journal will become unusable during that 
> JVM execution. 
> The error was reported as a warning but the loop is not broken out of after a 
> recent change (ARTEMIS-321), a callback IO handler will now be invoked and 
> the business logic can elect to make a decision such as shutdown. 
> However, if you know that the error may be transient, unless this callback 
> throws an unhandled exception the journal will remain blocked forever. Even 
> if an unhandled exception is thrown from your handler to unblock the thread, 
> there is an issue in that subsequent calls to appendRecord will add the file 
> name into the queue of files to create every time it is invoked. This can 
> easily result in the same file name appearing twice in the queue. Once this 
> happens, the logic to check if a record does not fit in the current file then 
> it will fit in the next file triggers and an exception is thrown.



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

[jira] [Commented] (ARTEMIS-352) Correct readme.html in security examples

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-352:


Github user asfgit closed the pull request at:

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


> Correct readme.html in security examples
> 
>
> Key: ARTEMIS-352
> URL: https://issues.apache.org/jira/browse/ARTEMIS-352
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Commented] (ARTEMIS-350) possible OOM in replication manager

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-350:


Github user asfgit closed the pull request at:

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


> possible OOM in replication manager
> ---
>
> Key: ARTEMIS-350
> URL: https://issues.apache.org/jira/browse/ARTEMIS-350
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>
> This is becausee we have no flow control, we need to throttle back when the 
> channel is not writable



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

[jira] [Commented] (ARTEMIS-350) possible OOM in replication manager

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-350:


GitHub user andytaylor opened a pull request:

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

ARTEMIS-350 - add timeout to avoid deadlock

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

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

$ git pull https://github.com/andytaylor/activemq-artemis master

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

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


commit a24dc5b61aec4c0bf71173056915a09187c216ea
Author: Andy Taylor 
Date:   2016-01-21T10:02:24Z

ARTEMIS-350 - add timeout to avoid deadlock

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




> possible OOM in replication manager
> ---
>
> Key: ARTEMIS-350
> URL: https://issues.apache.org/jira/browse/ARTEMIS-350
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.3.0
>
>
> This is becausee we have no flow control, we need to throttle back when the 
> channel is not writable



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

[jira] [Commented] (ARTEMIS-350) possible OOM in replication manager

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-350:


Github user asfgit closed the pull request at:

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


> possible OOM in replication manager
> ---
>
> Key: ARTEMIS-350
> URL: https://issues.apache.org/jira/browse/ARTEMIS-350
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
> Fix For: 1.3.0
>
>
> This is becausee we have no flow control, we need to throttle back when the 
> channel is not writable



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

[jira] [Commented] (ARTEMIS-354) login.config not set properly for Windows service

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-354:


Github user asfgit closed the pull request at:

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


> login.config not set properly for Windows service
> -
>
> Key: ARTEMIS-354
> URL: https://issues.apache.org/jira/browse/ARTEMIS-354
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Commented] (ARTEMIS-354) login.config not set properly for Windows service

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-354:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/335#issuecomment-173657108
  
Looks good


> login.config not set properly for Windows service
> -
>
> Key: ARTEMIS-354
> URL: https://issues.apache.org/jira/browse/ARTEMIS-354
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>




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

[jira] [Commented] (ARTEMIS-357) Possible encoding race over many destinations

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-357:


GitHub user clebertsuconic opened a pull request:

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

ARTEMIS-357 Avoiding possible races on encoding messages

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

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

$ git pull https://github.com/clebertsuconic/activemq-artemis master

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

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


commit d87700c95228b014e975b5f1506bb0e8f5a3eab5
Author: Clebert Suconic 
Date:   2016-01-23T05:06:05Z

ARTEMIS-357 Avoiding possible races on encoding messages

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




> Possible encoding race over many destinations
> -
>
> Key: ARTEMIS-357
> URL: https://issues.apache.org/jira/browse/ARTEMIS-357
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 1.3.0
>
>
> There seems to be a possibility of a race on messageImpl:encodeToBuffer
> The current implementation try to reuse the buffer sent on producer on an 
> optimization that was used when we were on Netty Blocking.
> We have been reported of cases where the client can't decode the message:



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

[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-358:


Github user scop commented on the pull request:

https://github.com/apache/activemq-artemis/pull/341#issuecomment-174532025
  
You seem to be missing that it's the *topic* (not subscription) that kind 
of goes away; trying to send to the topic starts to produce error messages.


> Topic disappears when STOMP subscriber client disconnects without unsubscribe
> -
>
> Key: ARTEMIS-358
> URL: https://issues.apache.org/jira/browse/ARTEMIS-358
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Ville Skyttä
>
> When a STOMP client which has a subscription to a topic disconnects without 
> unsubscribing first, the topic seems to disappear.
> Reproducer:
> # configure a server with a topic (e.g. jms.topic.testtopic) and start it
> # STOMP: connect to the server
> # STOMP: subscribe to the topic
> # STOMP: disconnect from the server (without unsubscribing first)
> # STOMP: connect to the server again
> # STOMP: send a message to the topic
> At this point the server responds with "AMQ339001: Destination does not 
> exist: jms.topic.testtopic"
> At this point the topic is still visible in jconsole though so maybe it has 
> not disappeared entirely, but anyway, messages cannot be sent to it with 
> STOMP any more. Restarting the server makes it possible to send to it again.



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

[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-358:


Github user scop commented on the pull request:

https://github.com/apache/activemq-artemis/pull/341#issuecomment-174532317
  
(Well, the subscription goes away too, but that's expected.)


> Topic disappears when STOMP subscriber client disconnects without unsubscribe
> -
>
> Key: ARTEMIS-358
> URL: https://issues.apache.org/jira/browse/ARTEMIS-358
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Ville Skyttä
>
> When a STOMP client which has a subscription to a topic disconnects without 
> unsubscribing first, the topic seems to disappear.
> Reproducer:
> # configure a server with a topic (e.g. jms.topic.testtopic) and start it
> # STOMP: connect to the server
> # STOMP: subscribe to the topic
> # STOMP: disconnect from the server (without unsubscribing first)
> # STOMP: connect to the server again
> # STOMP: send a message to the topic
> At this point the server responds with "AMQ339001: Destination does not 
> exist: jms.topic.testtopic"
> At this point the topic is still visible in jconsole though so maybe it has 
> not disappeared entirely, but anyway, messages cannot be sent to it with 
> STOMP any more. Restarting the server makes it possible to send to it again.



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

[jira] [Commented] (ARTEMIS-360) [Testsuite] PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails on timeout waiting for stop paging

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-360:


GitHub user MartinStyk opened a pull request:

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

ARTEMIS-360 - PagingTest.testSpreadMessagesWithFilterWithDeadConsumer…

… fails on timeout waiting for stop paging

extended waiting time

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

$ git pull https://github.com/MartinStyk/activemq-artemis master

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

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


commit 812abe0626a79f2611a5161cc8cb0e87bfd7
Author: Martin Styk 
Date:   2016-01-25T13:37:43Z

ARTEMIS-360 - PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails 
on timeout waiting for stop paging

extended waiting time




> [Testsuite] PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails on 
> timeout waiting for stop paging
> 
>
> Key: ARTEMIS-360
> URL: https://issues.apache.org/jira/browse/ARTEMIS-360
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: RHEL7, IBM JDK 1.6
>Reporter: Martin Styk
>
> Execution of test package 
> org.apache.activemq.artemis.tests.integration.client.PagingTest.testSpreadMessagesWithFilterWithDeadConsumer
>  on slower machine timeouts during waiting for server to stop paging.



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

[jira] [Commented] (ARTEMIS-360) [Testsuite] PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails on timeout waiting for stop paging

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-360:


Github user asfgit closed the pull request at:

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


> [Testsuite] PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails on 
> timeout waiting for stop paging
> 
>
> Key: ARTEMIS-360
> URL: https://issues.apache.org/jira/browse/ARTEMIS-360
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: RHEL7, IBM JDK 1.6
>Reporter: Martin Styk
>
> Execution of test package 
> org.apache.activemq.artemis.tests.integration.client.PagingTest.testSpreadMessagesWithFilterWithDeadConsumer
>  on slower machine timeouts during waiting for server to stop paging.



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

[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-358:


Github user asfgit closed the pull request at:

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


> Topic disappears when STOMP subscriber client disconnects without unsubscribe
> -
>
> Key: ARTEMIS-358
> URL: https://issues.apache.org/jira/browse/ARTEMIS-358
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Ville Skyttä
>
> When a STOMP client which has a subscription to a topic disconnects without 
> unsubscribing first, the topic seems to disappear.
> Reproducer:
> # configure a server with a topic (e.g. jms.topic.testtopic) and start it
> # STOMP: connect to the server
> # STOMP: subscribe to the topic
> # STOMP: disconnect from the server (without unsubscribing first)
> # STOMP: connect to the server again
> # STOMP: send a message to the topic
> At this point the server responds with "AMQ339001: Destination does not 
> exist: jms.topic.testtopic"
> At this point the topic is still visible in jconsole though so maybe it has 
> not disappeared entirely, but anyway, messages cannot be sent to it with 
> STOMP any more. Restarting the server makes it possible to send to it again.



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

[jira] [Commented] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-359:


Github user asfgit closed the pull request at:

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


> [TestSuite] IBM JDK does not allow to instrument classes
> 
>
> Key: ARTEMIS-359
> URL: https://issues.apache.org/jira/browse/ARTEMIS-359
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Miroslav Novak
>
> IBM JDK 6/7/8 does not allow byteman agent to modify classes. For example 
> "extra-tests" will fail with following exception:
> {code}
> Running 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> byteman jar is 
> /home/mnovak/.m2/repository/org/jboss/byteman/byteman/2.2.0/byteman-2.2.0.jar
> com.ibm.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:401)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.attachTarget(VirtualMachineImpl.java:94)
>   at 
> com.ibm.tools.attach.javaSE.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:37)
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:55)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:472)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:98)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.net.SocketTimeoutException: Accept timed out
>   at 
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:445)
>   at java.net.ServerSocket.implAccept(ServerSocket.java:620)
>   at java.net.ServerSocket.accept(ServerSocket.java:579)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:396)
>   ... 17 more
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 291.094 sec 
> <<< FAILURE! - in 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest(org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest)
>   Time elapsed: 291.094 sec  <<< ERROR!
> com.sun.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:472)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:98)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> 

[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-358:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/341#issuecomment-174561872
  
I am merging the test


> Topic disappears when STOMP subscriber client disconnects without unsubscribe
> -
>
> Key: ARTEMIS-358
> URL: https://issues.apache.org/jira/browse/ARTEMIS-358
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Ville Skyttä
>
> When a STOMP client which has a subscription to a topic disconnects without 
> unsubscribing first, the topic seems to disappear.
> Reproducer:
> # configure a server with a topic (e.g. jms.topic.testtopic) and start it
> # STOMP: connect to the server
> # STOMP: subscribe to the topic
> # STOMP: disconnect from the server (without unsubscribing first)
> # STOMP: connect to the server again
> # STOMP: send a message to the topic
> At this point the server responds with "AMQ339001: Destination does not 
> exist: jms.topic.testtopic"
> At this point the topic is still visible in jconsole though so maybe it has 
> not disappeared entirely, but anyway, messages cannot be sent to it with 
> STOMP any more. Restarting the server makes it possible to send to it again.



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

[jira] [Commented] (ARTEMIS-361) Improve encoding on ServerLocator's properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-361:


GitHub user clebertsuconic opened a pull request:

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

ARTEMIS-361 Fixing URI Encoding of Connection Factory properties

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

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

$ git pull https://github.com/clebertsuconic/activemq-artemis master

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

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


commit e8c3bfa11f9bd6f598d85592d7449c772ea4f6ff
Author: Clebert Suconic 
Date:   2016-01-25T22:02:24Z

ARTEMIS-361 Fixing URI Encoding of Connection Factory properties

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




> Improve encoding on ServerLocator's properties
> --
>
> Key: ARTEMIS-361
> URL: https://issues.apache.org/jira/browse/ARTEMIS-361
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> If you add any weird encoding on properties (such as % and space) the 
> ConnectionFactory serialization might be broken due to these encodings.
> We should be using URLEncoder.encode(STRING, "UTF-8") and 
> URLDecoder.decode(STRING, "UTF-8") for all the Query properties on the 
> URISchema.



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

[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-358:


Github user jbertram commented on the pull request:

https://github.com/apache/activemq-artemis/pull/346#issuecomment-174705757
  
I think @howardgao should take a look at this before it's merged.


> Topic disappears when STOMP subscriber client disconnects without unsubscribe
> -
>
> Key: ARTEMIS-358
> URL: https://issues.apache.org/jira/browse/ARTEMIS-358
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Ville Skyttä
>Assignee: Justin Bertram
>
> When a STOMP client which has a subscription to a topic disconnects without 
> unsubscribing first, the topic seems to disappear.
> Reproducer:
> # configure a server with a topic (e.g. jms.topic.testtopic) and start it
> # STOMP: connect to the server
> # STOMP: subscribe to the topic
> # STOMP: disconnect from the server (without unsubscribing first)
> # STOMP: connect to the server again
> # STOMP: send a message to the topic
> At this point the server responds with "AMQ339001: Destination does not 
> exist: jms.topic.testtopic"
> At this point the topic is still visible in jconsole though so maybe it has 
> not disappeared entirely, but anyway, messages cannot be sent to it with 
> STOMP any more. Restarting the server makes it possible to send to it again.



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

[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-358:


GitHub user jbertram opened a pull request:

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

ARTEMIS-358 topic mistakenly removed with sub

The problem here is that the management notification listener was mistakenly
removing the topic itself instead of just the non-durable subscription. In
general I can't see why StompProtocolManager even needs to keep track of the
destinations when the broker already does that. As far as I can tell it is
redundant and it's clearly error-prone. Therefore I'm removing the 
destination
tracking from StompProtocolManager altogether.

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

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

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

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


commit 960e29afadcd3b5848a95406ad14d48099fb6c3c
Author: jbertram 
Date:   2016-01-25T22:36:02Z

ARTEMIS-358 topic mistakenly removed with sub

The problem here is that the management notification listener was mistakenly
removing the topic itself instead of just the non-durable subscription. In
general I can't see why StompProtocolManager even needs to keep track of the
destinations when the broker already does that. As far as I can tell it is
redundant and it's clearly error-prone. Therefore I'm removing the 
destination
tracking from StompProtocolManager altogether.




> Topic disappears when STOMP subscriber client disconnects without unsubscribe
> -
>
> Key: ARTEMIS-358
> URL: https://issues.apache.org/jira/browse/ARTEMIS-358
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Ville Skyttä
>Assignee: Justin Bertram
>
> When a STOMP client which has a subscription to a topic disconnects without 
> unsubscribing first, the topic seems to disappear.
> Reproducer:
> # configure a server with a topic (e.g. jms.topic.testtopic) and start it
> # STOMP: connect to the server
> # STOMP: subscribe to the topic
> # STOMP: disconnect from the server (without unsubscribing first)
> # STOMP: connect to the server again
> # STOMP: send a message to the topic
> At this point the server responds with "AMQ339001: Destination does not 
> exist: jms.topic.testtopic"
> At this point the topic is still visible in jconsole though so maybe it has 
> not disappeared entirely, but anyway, messages cannot be sent to it with 
> STOMP any more. Restarting the server makes it possible to send to it again.



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

[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-358:


Github user jbertram commented on the pull request:

https://github.com/apache/activemq-artemis/pull/346#issuecomment-174735323
  
Not sure why this was reported as failed.  Everything looks good to me: 
https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/962/console.


> Topic disappears when STOMP subscriber client disconnects without unsubscribe
> -
>
> Key: ARTEMIS-358
> URL: https://issues.apache.org/jira/browse/ARTEMIS-358
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Ville Skyttä
>Assignee: Justin Bertram
>
> When a STOMP client which has a subscription to a topic disconnects without 
> unsubscribing first, the topic seems to disappear.
> Reproducer:
> # configure a server with a topic (e.g. jms.topic.testtopic) and start it
> # STOMP: connect to the server
> # STOMP: subscribe to the topic
> # STOMP: disconnect from the server (without unsubscribing first)
> # STOMP: connect to the server again
> # STOMP: send a message to the topic
> At this point the server responds with "AMQ339001: Destination does not 
> exist: jms.topic.testtopic"
> At this point the topic is still visible in jconsole though so maybe it has 
> not disappeared entirely, but anyway, messages cannot be sent to it with 
> STOMP any more. Restarting the server makes it possible to send to it again.



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

[jira] [Commented] (ARTEMIS-346) Add Management send text message functionality similar to ActiveMQ

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-346:


Github user asfgit closed the pull request at:

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


> Add Management send text message functionality similar to ActiveMQ
> --
>
> Key: ARTEMIS-346
> URL: https://issues.apache.org/jira/browse/ARTEMIS-346
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>




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

[jira] [Commented] (ARTEMIS-353) Calling jmap -heap over artemis will interrupt its execution.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-353:


GitHub user clebertsuconic opened a pull request:

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

ARTEMIS-353 retrying after interrupts on the native layer



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

$ git pull https://github.com/clebertsuconic/activemq-artemis master

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

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


commit 2af34a0a53fced144221e437999eadce8a30efe5
Author: Clebert Suconic 
Date:   2016-01-20T19:07:47Z

ARTEMIS-353 retrying after interrupts on the native layer because of jmap 
issuing weird interrupts

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




> Calling jmap -heap over artemis will interrupt its execution.
> -
>
> Key: ARTEMIS-353
> URL: https://issues.apache.org/jira/browse/ARTEMIS-353
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> jmap is issuing some weird signals that is interrupting io_getevents call. 
> any attempt to use jmap -heap over artemis while using libaio will interrupt 
> the server.



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

[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-358:


GitHub user scop opened a pull request:

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

ARTEMIS-358 test case for topic disappearing on disconnect without unsub

Test case (not a fix) demonstrating the issue.

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

$ git pull https://github.com/scop/activemq-artemis topic-disappears

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

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


commit c84f9c644c15cafeb02526c9343c17d538cdade9
Author: Ville Skyttä 
Date:   2016-01-24T13:50:53Z

ARTEMIS-358 test case for topic disappearing on disconnect without 
unsubscribe




> Topic disappears when STOMP subscriber client disconnects without unsubscribe
> -
>
> Key: ARTEMIS-358
> URL: https://issues.apache.org/jira/browse/ARTEMIS-358
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Stomp
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Ville Skyttä
>
> When a STOMP client which has a subscription to a topic disconnects without 
> unsubscribing first, the topic seems to disappear.
> Reproducer:
> # configure a server with a topic (e.g. jms.topic.testtopic) and start it
> # STOMP: connect to the server
> # STOMP: subscribe to the topic
> # STOMP: disconnect from the server (without unsubscribing first)
> # STOMP: connect to the server again
> # STOMP: send a message to the topic
> At this point the server responds with "AMQ339001: Destination does not 
> exist: jms.topic.testtopic"
> At this point the topic is still visible in jconsole though so maybe it has 
> not disappeared entirely, but anyway, messages cannot be sent to it with 
> STOMP any more. Restarting the server makes it possible to send to it again.



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

[jira] [Commented] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-359:


GitHub user mnovak1 opened a pull request:

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

ARTEMIS-359 - test suite fix - IBM JDK 6/7/8 does not allow byteman a…

…gent to modify classes.

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

$ git pull https://github.com/mnovak1/activemq-artemis master

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

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


commit 65ccf56c78026b9e00a6e9dfcfca74b3b735bec9
Author: Miroslav Novak 
Date:   2016-01-25T09:47:14Z

ARTEMIS-359 - test suite fix - IBM JDK 6/7/8 does not allow byteman agent 
to modify classes.




> [TestSuite] IBM JDK does not allow to instrument classes
> 
>
> Key: ARTEMIS-359
> URL: https://issues.apache.org/jira/browse/ARTEMIS-359
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Miroslav Novak
>
> IBM JDK 6/7/8 does not allow byteman agent to modify classes. For example 
> "extra-tests" will fail with following exception:
> {code}
> Running 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> byteman jar is 
> /home/mnovak/.m2/repository/org/jboss/byteman/byteman/2.2.0/byteman-2.2.0.jar
> com.ibm.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:401)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.attachTarget(VirtualMachineImpl.java:94)
>   at 
> com.ibm.tools.attach.javaSE.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:37)
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:55)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:472)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:98)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.net.SocketTimeoutException: Accept timed out
>   at 
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:445)
>   at java.net.ServerSocket.implAccept(ServerSocket.java:620)
>   at java.net.ServerSocket.accept(ServerSocket.java:579)
>   at 
> com.ibm.tools.attach.javaSE.VirtualMachineImpl.tryAttachTarget(VirtualMachineImpl.java:396)
>   ... 17 more
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 291.094 sec 
> <<< FAILURE! - in 
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest
> org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest(org.apache.activemq.artemis.tests.extras.byteman.ActiveMQMessageHandlerTest)
>   Time elapsed: 291.094 sec  <<< ERROR!
> com.sun.tools.attach.AttachNotSupportedException: acknowledgement timeout 
> from 21654 on port 42521
>   at 
> ibm.tools.attach.J9AttachProvider.attachVirtualMachine(J9AttachProvider.java:60)
>   at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:231)
>   at org.jboss.byteman.agent.install.Install.attach(Install.java:374)
>   at org.jboss.byteman.agent.install.Install.install(Install.java:113)
>   at 
> org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:340)
>   at 
> 

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-362:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/348#issuecomment-175096224
  
I would like to see a description on the commit about what is being 
changed...

It's fairly common having to do a git log to figure out when things got 
broken... and having to open the JIRA to see what happened is not very 
practical.


I can change the commit description before merging though if you don't 
mind... but if you can ammend with a description such as 

___
ARTEMIS-362 Only sending UDP packets bytes as needed

You can use the next lines to explain things.. etc...
_


Looking at the website (JIRA on this case) should be an extra step to 
eventually look for discussions.


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-362:


Github user l-dobrev commented on the pull request:

https://github.com/apache/activemq-artemis/pull/348#issuecomment-17508
  
Amended.
How's that?


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-362:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/348#issuecomment-175112492
  
much better.. thanks


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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

[jira] [Commented] (ARTEMIS-362) BroadcastGroupImpl sends datagrams big datagrams full of zero bytes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-362:


Github user clebertsuconic commented on the pull request:

https://github.com/apache/activemq-artemis/pull/348#issuecomment-175148138
  
It seems nice and clear to be merged.. but I am running the entire 
testsuite on my box before merging this.. .just to be safe.


> BroadcastGroupImpl sends datagrams big datagrams full of zero bytes
> ---
>
> Key: ARTEMIS-362
> URL: https://issues.apache.org/jira/browse/ARTEMIS-362
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
> Environment: OS: Linux
> JVM: Oracle or OpenJDK, 1.7 or 1.8 
>Reporter: Lachezar Dobrev
>  Labels: newbie, patch, test
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The BroadcastGroupImpl uses improper buffer handling to generate packages for 
> broadcasting to a cluster. This results in sending 4096 byte packages (the 
> size of the buffer) full of zero bytes with only about 250-300 bytes actual 
> payload.
> This incurs needless weight on any underlying network equipment.
> This also may result in loss of service as large packages may be silently 
> discarded.



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