[jira] [Commented] (AMQ-5881) AMQ accepts MQTT connect with password without username

2016-02-25 Thread ASF subversion and git services (JIRA) 

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

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

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

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

Fail the connect if the password is set but the username bit is not as
per the V3.1.1 spec requirements. 

> AMQ accepts MQTT connect with password without username
> ---
>
> Key: AMQ-5881
> URL: https://issues.apache.org/jira/browse/AMQ-5881
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.11.1
> Environment: OSX 10.10
> https://github.com/ckrey/MQTT-Client-Framework testcases
>Reporter: Christoph Krey
>Priority: Minor
>
> MQTT spec says:
> [MQTT-3.1.2-22]
> If the User Name Flag is set to 0, the Password Flag MUST be set to 0.



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

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

2016-02-25 Thread Justin Bertram (JIRA) 

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

Justin Bertram resolved ARTEMIS-422.

   Resolution: Fixed
Fix Version/s: 1.3.0

> 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
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>
> 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] [Updated] (ARTEMIS-422) Implement appendRollbackRecord in o.a.a.a.c.j.i.FileWrapperJournal

2016-02-25 Thread Justin Bertram (JIRA) 

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

Justin Bertram updated ARTEMIS-422:
---
Affects Version/s: 1.2.0

> 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
>Affects Versions: 1.2.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>
> 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

2016-02-25 Thread 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-422) Implement appendRollbackRecord in o.a.a.a.c.j.i.FileWrapperJournal

2016-02-25 Thread ASF subversion and git services (JIRA) 

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

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

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

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

2016-02-25 Thread 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] [Created] (ARTEMIS-422) Implement appendRollbackRecord in o.a.a.a.c.j.i.FileWrapperJournal

2016-02-25 Thread Justin Bertram (JIRA) 
Justin Bertram created ARTEMIS-422:
--

 Summary: 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] [Resolved] (AMQ-6167) examples/other/perfharness misses readme and uses broken link.

2016-02-25 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQ-6167.
---
   Resolution: Fixed
 Assignee: Timothy Bish
Fix Version/s: 5.14.0

Removed the broken example

> examples/other/perfharness misses readme and uses broken link.
> --
>
> Key: AMQ-6167
> URL: https://issues.apache.org/jira/browse/AMQ-6167
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: demo
>Affects Versions: 5.13.0
>Reporter: Torsten Mielke
>Assignee: Timothy Bish
>  Labels: demo
> Fix For: 5.14.0
>
>
> The Perfharness demo in examples/other/perfharness 
> * misses a short readme.md that describes the demo
> * refers to broker link http://www.alphaworks.ibm.com/tech/perfharness in 
> perfharness-activemq.sh



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

[jira] [Commented] (AMQ-6167) examples/other/perfharness misses readme and uses broken link.

2016-02-25 Thread ASF subversion and git services (JIRA) 

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

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

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

AMQ-6167 Remove old example that used the now defunct IBM perfharness.

> examples/other/perfharness misses readme and uses broken link.
> --
>
> Key: AMQ-6167
> URL: https://issues.apache.org/jira/browse/AMQ-6167
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: demo
>Affects Versions: 5.13.0
>Reporter: Torsten Mielke
>  Labels: demo
>
> The Perfharness demo in examples/other/perfharness 
> * misses a short readme.md that describes the demo
> * refers to broker link http://www.alphaworks.ibm.com/tech/perfharness in 
> perfharness-activemq.sh



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

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

2016-02-25 Thread 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] [Assigned] (AMQ-6182) disable TRACE method in apache activeMQ Server

2016-02-25 Thread Christopher L. Shannon (JIRA) 

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

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

Assignee: Christopher L. Shannon

> disable TRACE method in apache activeMQ Server
> --
>
> Key: AMQ-6182
> URL: https://issues.apache.org/jira/browse/AMQ-6182
> Project: ActiveMQ
>  Issue Type: Task
>Affects Versions: 5.11.1, 5.13.0
> Environment: linux operating system
>Reporter: Vidya Sagar D
>Assignee: Christopher L. Shannon
>Priority: Critical
>  Labels: activemq, activemq-web-console,, jetty
> Fix For: 5.14.0, 5.13.2
>
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> For security reasons, have to disable TRACE method in Apache ActiveMQ Server, 
> unable to do it.
> Could you please help me to disable TRACE method in Apache ActiveMQ server ( 
> Jetty 7.x - Internal Server)



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

[jira] [Updated] (AMQ-6182) disable TRACE method in apache activeMQ Server

2016-02-25 Thread Christopher L. Shannon (JIRA) 

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

Christopher L. Shannon updated AMQ-6182:

Fix Version/s: 5.13.2
   5.14.0

> disable TRACE method in apache activeMQ Server
> --
>
> Key: AMQ-6182
> URL: https://issues.apache.org/jira/browse/AMQ-6182
> Project: ActiveMQ
>  Issue Type: Task
>Affects Versions: 5.11.1, 5.13.0
> Environment: linux operating system
>Reporter: Vidya Sagar D
>Assignee: Christopher L. Shannon
>Priority: Critical
>  Labels: activemq, activemq-web-console,, jetty
> Fix For: 5.14.0, 5.13.2
>
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> For security reasons, have to disable TRACE method in Apache ActiveMQ Server, 
> unable to do it.
> Could you please help me to disable TRACE method in Apache ActiveMQ server ( 
> Jetty 7.x - Internal Server)



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

[jira] [Commented] (AMQ-6182) disable TRACE method in apache activeMQ Server

2016-02-25 Thread Christopher L. Shannon (JIRA) 

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

Christopher L. Shannon commented on AMQ-6182:
-

There's no way to configure this right now but I will switch this so that trace 
is turned off by default since it isn't necessary for the transport to run and 
is only useful for debugging.  I will add an option in to re-enable it if 
someone wants to.

> disable TRACE method in apache activeMQ Server
> --
>
> Key: AMQ-6182
> URL: https://issues.apache.org/jira/browse/AMQ-6182
> Project: ActiveMQ
>  Issue Type: Task
>Affects Versions: 5.11.1, 5.13.0
> Environment: linux operating system
>Reporter: Vidya Sagar D
>Priority: Critical
>  Labels: activemq, activemq-web-console,, jetty
> Fix For: 5.14.0, 5.13.2
>
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> For security reasons, have to disable TRACE method in Apache ActiveMQ Server, 
> unable to do it.
> Could you please help me to disable TRACE method in Apache ActiveMQ server ( 
> Jetty 7.x - Internal Server)



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

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

2016-02-25 Thread Erich Duda (JIRA) 

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

Erich Duda resolved ARTEMIS-415.

   Resolution: Fixed
Fix Version/s: 1.3.0

> [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
> Fix For: 1.3.0
>
>
> {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] (AMQ-5742) Destination dispatched count statistic not reflecting redelivery/redispatch

2016-02-25 Thread ruffp (JIRA) 

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

ruffp commented on AMQ-5742:


[~gtully] Because it seems the message queue counters are sometimes 
desynchronized on our AMQ, is it possible that bug is also present in version 
5.10.2?

> Destination dispatched count statistic not reflecting redelivery/redispatch
> ---
>
> Key: AMQ-5742
> URL: https://issues.apache.org/jira/browse/AMQ-5742
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.11.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>  Labels: dispatchedCount, jmx, statistics
> Fix For: 5.11.2, 5.12.0
>
>
> Tracking down in intermittent failure of 
> org.apache.activemq.network.DemandForwardingBridgeTest.testSendThenAddConsumer
> the problem turned out to be a decrement of the dispatched count when the 
> consumer was removed.
> So before the removal, most of the time, the stat was 1, and the test passed. 
> But if the removal was complete, the dispatched count was decremented in 
> error by the unacked message count. This is wrong. The dispatched stat needs 
> to reflect what happened :-) Otherwise it tracks the dequeue count.



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

[jira] [Commented] (AMQ-6184) Improve nio transport scalability

2016-02-25 Thread Christopher L. Shannon (JIRA) 

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

Christopher L. Shannon commented on AMQ-6184:
-

Yep, it's happy again so must have just been my system/jvm with a lower memory 
limit or thread pool limit configured than yours.  We'll see what Jenkins comes 
up with but it's probably fine now.

> Improve nio transport scalability
> -
>
> Key: AMQ-6184
> URL: https://issues.apache.org/jira/browse/AMQ-6184
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.13.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.14.0
>
>
> NIO transport uses unbounded thread pool executor to handle read operation. 
> Under large number of connections and load, this could lead to large number 
> of threads and eventually OOM errors. Which is the exact problem that nio 
> transport is supposed to solve. Some work has been done in [AMQ-5480], to 
> make this configurable, but there's still more work to make it more robust. 
> Creating a fixed thread pool with a queue in front gives much better results 
> in my tests.
> Additionally, the same thread pool is used for accepting connections 
> ([AMQ-5269]). This can lead to the broker not being able to accept new 
> connections under the load. I got much better results when experimenting with 
> implementing acceptor logic directly and handling it in the same thread 
> (without reintroducing the old problem). 
> With these two improvements in place, the broker accept and handle the number 
> of connections up to the system limits.



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

[jira] [Commented] (AMQ-6184) Improve nio transport scalability

2016-02-25 Thread Dejan Bosanac (JIRA) 

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

Dejan Bosanac commented on AMQ-6184:


Hi [~cshannon], thanks for checking it out. It could be related to the core 
pool size being big before the later fix, although it didn't show up on my 
system during the whole build (I guess it depends on the max thread available 
on the system). Anyways, the smaller default value make much more sense for the 
"normal" cases.

Let me know if you spot any more regressions.

Cheers again!

> Improve nio transport scalability
> -
>
> Key: AMQ-6184
> URL: https://issues.apache.org/jira/browse/AMQ-6184
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.13.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.14.0
>
>
> NIO transport uses unbounded thread pool executor to handle read operation. 
> Under large number of connections and load, this could lead to large number 
> of threads and eventually OOM errors. Which is the exact problem that nio 
> transport is supposed to solve. Some work has been done in [AMQ-5480], to 
> make this configurable, but there's still more work to make it more robust. 
> Creating a fixed thread pool with a queue in front gives much better results 
> in my tests.
> Additionally, the same thread pool is used for accepting connections 
> ([AMQ-5269]). This can lead to the broker not being able to accept new 
> connections under the load. I got much better results when experimenting with 
> implementing acceptor logic directly and handling it in the same thread 
> (without reintroducing the old problem). 
> With these two improvements in place, the broker accept and handle the number 
> of connections up to the system limits.



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

[jira] [Commented] (AMQ-6184) Improve nio transport scalability

2016-02-25 Thread Christopher L. Shannon (JIRA) 

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

Christopher L. Shannon commented on AMQ-6184:
-

Nevermind, your latest commit seems to have sorted the issue.  It must have 
been related to the core pool size :)

> Improve nio transport scalability
> -
>
> Key: AMQ-6184
> URL: https://issues.apache.org/jira/browse/AMQ-6184
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.13.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.14.0
>
>
> NIO transport uses unbounded thread pool executor to handle read operation. 
> Under large number of connections and load, this could lead to large number 
> of threads and eventually OOM errors. Which is the exact problem that nio 
> transport is supposed to solve. Some work has been done in [AMQ-5480], to 
> make this configurable, but there's still more work to make it more robust. 
> Creating a fixed thread pool with a queue in front gives much better results 
> in my tests.
> Additionally, the same thread pool is used for accepting connections 
> ([AMQ-5269]). This can lead to the broker not being able to accept new 
> connections under the load. I got much better results when experimenting with 
> implementing acceptor logic directly and handling it in the same thread 
> (without reintroducing the old problem). 
> With these two improvements in place, the broker accept and handle the number 
> of connections up to the system limits.



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

[jira] [Commented] (AMQ-6184) Improve nio transport scalability

2016-02-25 Thread Christopher L. Shannon (JIRA) 

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

Christopher L. Shannon commented on AMQ-6184:
-

[~dejanb],

I'm seeing a lot of problems with many of the auto+nio transport tests after 
this patch.  The error is always the same, I'm seeing:

 java.ioException: unable to create new native thread, and then an 
OutOfMemoryError that says the same thing. 

For example, I'm seeing this on AutoNIOTransportBrokerTest.  I also see issues 
if I try and run the entire package of org.apache.activemq.transport.auto.nio 
tests from Eclipse together.

> Improve nio transport scalability
> -
>
> Key: AMQ-6184
> URL: https://issues.apache.org/jira/browse/AMQ-6184
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.13.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.14.0
>
>
> NIO transport uses unbounded thread pool executor to handle read operation. 
> Under large number of connections and load, this could lead to large number 
> of threads and eventually OOM errors. Which is the exact problem that nio 
> transport is supposed to solve. Some work has been done in [AMQ-5480], to 
> make this configurable, but there's still more work to make it more robust. 
> Creating a fixed thread pool with a queue in front gives much better results 
> in my tests.
> Additionally, the same thread pool is used for accepting connections 
> ([AMQ-5269]). This can lead to the broker not being able to accept new 
> connections under the load. I got much better results when experimenting with 
> implementing acceptor logic directly and handling it in the same thread 
> (without reintroducing the old problem). 
> With these two improvements in place, the broker accept and handle the number 
> of connections up to the system limits.



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

[jira] [Commented] (AMQ-6184) Improve nio transport scalability

2016-02-25 Thread ASF subversion and git services (JIRA) 

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

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

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

https://issues.apache.org/jira/browse/AMQ-6184 - improve nio transport 
scalability; get back core pool size


> Improve nio transport scalability
> -
>
> Key: AMQ-6184
> URL: https://issues.apache.org/jira/browse/AMQ-6184
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.13.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.14.0
>
>
> NIO transport uses unbounded thread pool executor to handle read operation. 
> Under large number of connections and load, this could lead to large number 
> of threads and eventually OOM errors. Which is the exact problem that nio 
> transport is supposed to solve. Some work has been done in [AMQ-5480], to 
> make this configurable, but there's still more work to make it more robust. 
> Creating a fixed thread pool with a queue in front gives much better results 
> in my tests.
> Additionally, the same thread pool is used for accepting connections 
> ([AMQ-5269]). This can lead to the broker not being able to accept new 
> connections under the load. I got much better results when experimenting with 
> implementing acceptor logic directly and handling it in the same thread 
> (without reintroducing the old problem). 
> With these two improvements in place, the broker accept and handle the number 
> of connections up to the system limits.



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

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

2016-02-25 Thread Howard Gao (JIRA) 

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

Howard Gao resolved ARTEMIS-421.

Resolution: Fixed

> 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] (AMQ-6184) Improve nio transport scalability

2016-02-25 Thread Dejan Bosanac (JIRA) 

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

Dejan Bosanac commented on AMQ-6184:


More documentation pending

> Improve nio transport scalability
> -
>
> Key: AMQ-6184
> URL: https://issues.apache.org/jira/browse/AMQ-6184
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.13.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.14.0
>
>
> NIO transport uses unbounded thread pool executor to handle read operation. 
> Under large number of connections and load, this could lead to large number 
> of threads and eventually OOM errors. Which is the exact problem that nio 
> transport is supposed to solve. Some work has been done in [AMQ-5480], to 
> make this configurable, but there's still more work to make it more robust. 
> Creating a fixed thread pool with a queue in front gives much better results 
> in my tests.
> Additionally, the same thread pool is used for accepting connections 
> ([AMQ-5269]). This can lead to the broker not being able to accept new 
> connections under the load. I got much better results when experimenting with 
> implementing acceptor logic directly and handling it in the same thread 
> (without reintroducing the old problem). 
> With these two improvements in place, the broker accept and handle the number 
> of connections up to the system limits.



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

[jira] [Commented] (AMQ-6184) Improve nio transport scalability

2016-02-25 Thread ASF subversion and git services (JIRA) 

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

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

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

https://issues.apache.org/jira/browse/AMQ-6184 - improve nio transport 
scalability


> Improve nio transport scalability
> -
>
> Key: AMQ-6184
> URL: https://issues.apache.org/jira/browse/AMQ-6184
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.13.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.14.0
>
>
> NIO transport uses unbounded thread pool executor to handle read operation. 
> Under large number of connections and load, this could lead to large number 
> of threads and eventually OOM errors. Which is the exact problem that nio 
> transport is supposed to solve. Some work has been done in [AMQ-5480], to 
> make this configurable, but there's still more work to make it more robust. 
> Creating a fixed thread pool with a queue in front gives much better results 
> in my tests.
> Additionally, the same thread pool is used for accepting connections 
> ([AMQ-5269]). This can lead to the broker not being able to accept new 
> connections under the load. I got much better results when experimenting with 
> implementing acceptor logic directly and handling it in the same thread 
> (without reintroducing the old problem). 
> With these two improvements in place, the broker accept and handle the number 
> of connections up to the system limits.



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

[jira] [Created] (AMQ-6184) Improve nio transport scalability

2016-02-25 Thread Dejan Bosanac (JIRA) 
Dejan Bosanac created AMQ-6184:
--

 Summary: Improve nio transport scalability
 Key: AMQ-6184
 URL: https://issues.apache.org/jira/browse/AMQ-6184
 Project: ActiveMQ
  Issue Type: Improvement
Affects Versions: 5.13.0
Reporter: Dejan Bosanac
Assignee: Dejan Bosanac
 Fix For: 5.14.0


NIO transport uses unbounded thread pool executor to handle read operation. 
Under large number of connections and load, this could lead to large number of 
threads and eventually OOM errors. Which is the exact problem that nio 
transport is supposed to solve. Some work has been done in [AMQ-5480], to make 
this configurable, but there's still more work to make it more robust. Creating 
a fixed thread pool with a queue in front gives much better results in my tests.

Additionally, the same thread pool is used for accepting connections 
([AMQ-5269]). This can lead to the broker not being able to accept new 
connections under the load. I got much better results when experimenting with 
implementing acceptor logic directly and handling it in the same thread 
(without reintroducing the old problem). 

With these two improvements in place, the broker accept and handle the number 
of connections up to the system limits.



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

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

2016-02-25 Thread 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