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

[Martin Styk (JIRA)]

Martin Styk created ARTEMIS-360:
---

 Summary: [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] [Updated] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check

[Claudio Tagliola (JIRA)]

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

Claudio Tagliola updated AMQ-6142:
--
Description: 
In our environment we use an embedded broker. On one topic where compression is 
enabled, the server is also listening in on the messages. From ActiveMQ 5.10.0 
up to 5.13.0, we encounter DataFormatException: incorrect header check 
exceptions on the tcp clients due to corruption of the payload. Attached are a 
test server and client. At some point, the client will exit due to mentioned 
exception. Increase chances by running multiple clients.

If the server has multiple consumers on the same topic, they will encounter 
corruption as well, but this has other side-effects.

  was:
In our environment we use an embedded broker. On one topic, the server is also 
listening in on the messages. From ActiveMQ 5.10.0 up to 5.13.0, we encounter 
DataFormatException: incorrect header check exceptions on the tcp clients due 
to corruption of the payload. Attached are a test server and client. At some 
point, the client will exit due to mentioned exception. Increase chances by 
running multiple clients.

If the server has multiple consumers on the same topic, they will encounter 
corruption as well, but this has other side-effects.


> ActiveMQBytesMessage decompress throws DataFormatException incorrect header 
> check
> -
>
> Key: AMQ-6142
> URL: https://issues.apache.org/jira/browse/AMQ-6142
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.10.2, 5.12.1, 5.11.3, 5.13.0
>Reporter: Claudio Tagliola
> Attachments: Client.java, MessageListener.java, Server.java, pom.xml
>
>
> In our environment we use an embedded broker. On one topic where compression 
> is enabled, the server is also listening in on the messages. From ActiveMQ 
> 5.10.0 up to 5.13.0, we encounter DataFormatException: incorrect header check 
> exceptions on the tcp clients due to corruption of the payload. Attached are 
> a test server and client. At some point, the client will exit due to 
> mentioned exception. Increase chances by running multiple clients.
> If the server has multiple consumers on the same topic, they will encounter 
> corruption as well, but this has other side-effects.



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

[jira] [Comment Edited] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ

[Tristan Leask (JIRA)]

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

Tristan Leask edited comment on AMQ-5100 at 1/25/16 2:15 PM:
-

Ok, I am trying to do this as well, and came across the same error.  I got 
passed this error by editing the SSLContext definition like so...



Even though you get past this error, you then come across a "Transport 
Connector could not be registered in JMX" due to the random number generator 
and FIPS Mode...

{code}
INFO   | jvm 1| 2016/01/25 12:57:11 | 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in class 
path resource [activemq.xml]: Invocation of init method failed; nested 
exception is java.io.IOException: Transport Connector could not be registered 
in JMX: FIPS mode: SecureRandom must be from provider SunPKCS11-NSSfips
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:64)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:52)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory$1.(XBeanBrokerFactory.java:108)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory.createApplicationContext(XBeanBrokerFactory.java:108)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:72)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:71)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:54)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:115)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:74)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:148)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:90)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
java.lang.reflect.Method.invoke(Unknown Source)
INFO   | jvm 1| 

[jira] [Commented] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check

[Claudio Tagliola (JIRA)]

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

Claudio Tagliola commented on AMQ-6142:
---

Prior thread on activemq-users: 
http://activemq.2283324.n4.nabble.com/ActiveMQBytesMessage-decompress-throws-DataFormatException-incorrect-header-check-tp4706292.html

> ActiveMQBytesMessage decompress throws DataFormatException incorrect header 
> check
> -
>
> Key: AMQ-6142
> URL: https://issues.apache.org/jira/browse/AMQ-6142
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.10.2, 5.12.1, 5.11.3, 5.13.0
>Reporter: Claudio Tagliola
> Attachments: Client.java, MessageListener.java, Server.java, pom.xml
>
>
> In our environment we use an embedded broker. On one topic, the server is 
> also listening in on the messages. From ActiveMQ 5.10.0 up to 5.13.0, we 
> encounter DataFormatException: incorrect header check exceptions on the tcp 
> clients due to corruption of the payload. Attached are a test server and 
> client. At some point, the client will exit due to mentioned exception. 
> Increase chances by running multiple clients.
> If the server has multiple consumers on the same topic, they will encounter 
> corruption as well, but this has other side-effects.



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

[jira] [Comment Edited] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ

[Tristan Leask (JIRA)]

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

Tristan Leask edited comment on AMQ-5100 at 1/25/16 2:24 PM:
-

Ok, I am trying to do this as well, and came across the same error.  I got 
passed this error by editing the SSLContext definition like so...



Note, my wrapper.conf file had all the trust and key store entries commented 
out (running on Windows).

Even though you get past this error, you then come across a "Transport 
Connector could not be registered in JMX" due to the random number generator 
and FIPS Mode...

{code}
INFO   | jvm 1| 2016/01/25 12:57:11 | 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in class 
path resource [activemq.xml]: Invocation of init method failed; nested 
exception is java.io.IOException: Transport Connector could not be registered 
in JMX: FIPS mode: SecureRandom must be from provider SunPKCS11-NSSfips
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:64)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:52)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory$1.(XBeanBrokerFactory.java:108)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory.createApplicationContext(XBeanBrokerFactory.java:108)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:72)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:71)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:54)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:115)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:74)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:148)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:90)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1| 

[jira] [Commented] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ

[Tristan Leask (JIRA)]

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

Tristan Leask commented on AMQ-5100:


Ok, I am trying to do this as well, and came across the same error.  I got 
passed this error by editing the SSLContext definition like so...



Even though you get past this error, you then come across a "Transport 
Connector could not be registered in JMX" due to the random number generator 
and FIPS Mode...

{code}
INFO   | jvm 1| 2016/01/25 12:57:11 | 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in class 
path resource [activemq.xml]: Invocation of init method failed; nested 
exception is java.io.IOException: Transport Connector could not be registered 
in JMX: FIPS mode: SecureRandom must be from provider SunPKCS11-NSSfips
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:64)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:52)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory$1.(XBeanBrokerFactory.java:108)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory.createApplicationContext(XBeanBrokerFactory.java:108)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:72)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:71)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:54)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:115)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:74)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:148)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:90)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
java.lang.reflect.Method.invoke(Unknown Source)
INFO   | jvm 1| 2016/01/25 12:57:11 |   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=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] [Created] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check

[Claudio Tagliola (JIRA)]

Claudio Tagliola created AMQ-6142:
-

 Summary: ActiveMQBytesMessage decompress throws 
DataFormatException incorrect header check
 Key: AMQ-6142
 URL: https://issues.apache.org/jira/browse/AMQ-6142
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.13.0, 5.11.3, 5.12.1, 5.10.2
Reporter: Claudio Tagliola


In our environment we use an embedded broker. On one topic, the server is also 
listening in on the messages. From ActiveMQ 5.10.0 up to 5.13.0, we encounter 
DataFormatException: incorrect header check exceptions on the tcp clients due 
to corruption of the payload. Attached are a test server and client. At some 
point, the client will exit due to mentioned exception. Increase chances by 
running multiple clients.

If the server has multiple consumers on the same topic, they will encounter 
corruption as well, but this has other side-effects.



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

[jira] [Commented] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check

[Claudio Tagliola (JIRA)]

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

Claudio Tagliola commented on AMQ-6142:
---

Stack trace:
{noformat}
javax.jms.JMSException: java.util.zip.DataFormatException: incorrect header 
check
at 
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:72)
at 
org.apache.activemq.command.ActiveMQBytesMessage.initializeReading(ActiveMQBytesMessage.java:884)
at 
org.apache.activemq.command.ActiveMQBytesMessage.getBodyLength(ActiveMQBytesMessage.java:198)
at 
com.imc.activemqtest.MessageListener.onMessage(MessageListener.java:11)
at 
org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1393)
at 
org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:131)
at 
org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:202)
at 
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at 
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: java.util.zip.DataFormatException: incorrect 
header check
at 
org.apache.activemq.command.ActiveMQBytesMessage.decompress(ActiveMQBytesMessage.java:902)
at 
org.apache.activemq.command.ActiveMQBytesMessage.initializeReading(ActiveMQBytesMessage.java:876)
... 10 more
Caused by: java.util.zip.DataFormatException: incorrect header check
at java.util.zip.Inflater.inflateBytes(Native Method)
at java.util.zip.Inflater.inflate(Inflater.java:259)
at java.util.zip.Inflater.inflate(Inflater.java:280)
at 
org.apache.activemq.command.ActiveMQBytesMessage.decompress(ActiveMQBytesMessage.java:898)
... 11 more
{noformat}

> ActiveMQBytesMessage decompress throws DataFormatException incorrect header 
> check
> -
>
> Key: AMQ-6142
> URL: https://issues.apache.org/jira/browse/AMQ-6142
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.10.2, 5.12.1, 5.11.3, 5.13.0
>Reporter: Claudio Tagliola
>
> In our environment we use an embedded broker. On one topic, the server is 
> also listening in on the messages. From ActiveMQ 5.10.0 up to 5.13.0, we 
> encounter DataFormatException: incorrect header check exceptions on the tcp 
> clients due to corruption of the payload. Attached are a test server and 
> client. At some point, the client will exit due to mentioned exception. 
> Increase chances by running multiple clients.
> If the server has multiple consumers on the same topic, they will encounter 
> corruption as well, but this has other side-effects.



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

[jira] [Comment Edited] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check

[Claudio Tagliola (JIRA)]

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

Claudio Tagliola edited comment on AMQ-6142 at 1/25/16 2:02 PM:


Stack trace:
{noformat}
javax.jms.JMSException: java.util.zip.DataFormatException: incorrect header 
check
at 
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:72)
at 
org.apache.activemq.command.ActiveMQBytesMessage.initializeReading(ActiveMQBytesMessage.java:884)
at 
org.apache.activemq.command.ActiveMQBytesMessage.getBodyLength(ActiveMQBytesMessage.java:198)
at 
com.foo.bar.activemqtest.MessageListener.onMessage(MessageListener.java:11)
at 
org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1393)
at 
org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:131)
at 
org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:202)
at 
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at 
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: java.util.zip.DataFormatException: incorrect 
header check
at 
org.apache.activemq.command.ActiveMQBytesMessage.decompress(ActiveMQBytesMessage.java:902)
at 
org.apache.activemq.command.ActiveMQBytesMessage.initializeReading(ActiveMQBytesMessage.java:876)
... 10 more
Caused by: java.util.zip.DataFormatException: incorrect header check
at java.util.zip.Inflater.inflateBytes(Native Method)
at java.util.zip.Inflater.inflate(Inflater.java:259)
at java.util.zip.Inflater.inflate(Inflater.java:280)
at 
org.apache.activemq.command.ActiveMQBytesMessage.decompress(ActiveMQBytesMessage.java:898)
... 11 more
{noformat}


was (Author: tagliola):
Stack trace:
{noformat}
javax.jms.JMSException: java.util.zip.DataFormatException: incorrect header 
check
at 
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:72)
at 
org.apache.activemq.command.ActiveMQBytesMessage.initializeReading(ActiveMQBytesMessage.java:884)
at 
org.apache.activemq.command.ActiveMQBytesMessage.getBodyLength(ActiveMQBytesMessage.java:198)
at 
com.imc.activemqtest.MessageListener.onMessage(MessageListener.java:11)
at 
org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1393)
at 
org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:131)
at 
org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:202)
at 
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at 
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: java.util.zip.DataFormatException: incorrect 
header check
at 
org.apache.activemq.command.ActiveMQBytesMessage.decompress(ActiveMQBytesMessage.java:902)
at 
org.apache.activemq.command.ActiveMQBytesMessage.initializeReading(ActiveMQBytesMessage.java:876)
... 10 more
Caused by: java.util.zip.DataFormatException: incorrect header check
at java.util.zip.Inflater.inflateBytes(Native Method)
at java.util.zip.Inflater.inflate(Inflater.java:259)
at java.util.zip.Inflater.inflate(Inflater.java:280)
at 
org.apache.activemq.command.ActiveMQBytesMessage.decompress(ActiveMQBytesMessage.java:898)
... 11 more
{noformat}

> ActiveMQBytesMessage decompress throws DataFormatException incorrect header 
> check
> -
>
> Key: AMQ-6142
> URL: https://issues.apache.org/jira/browse/AMQ-6142
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.10.2, 5.12.1, 5.11.3, 5.13.0
>Reporter: Claudio Tagliola
>
> In our environment we use an embedded broker. On one topic, the server is 
> also listening in on the messages. From ActiveMQ 5.10.0 up to 5.13.0, we 
> encounter DataFormatException: incorrect header check exceptions on the tcp 
> clients due to corruption of the payload. Attached are a test server and 
> client. At some point, the client will exit due to mentioned exception. 

[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] [Comment Edited] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ

[Tristan Leask (JIRA)]

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

Tristan Leask edited comment on AMQ-5100 at 1/25/16 2:15 PM:
-

Ok, I am trying to do this as well, and came across the same error.  I got 
passed this error by editing the SSLContext definition like so...



Even though you get past this error, you then come across a "Transport 
Connector could not be registered in JMX" due to the random number generator 
and FIPS Mode...

{code}
INFO   | jvm 1| 2016/01/25 12:57:11 | 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in class 
path resource [activemq.xml]: Invocation of init method failed; nested 
exception is java.io.IOException: Transport Connector could not be registered 
in JMX: FIPS mode: SecureRandom must be from provider SunPKCS11-NSSfips
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:64)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:52)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory$1.(XBeanBrokerFactory.java:108)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory.createApplicationContext(XBeanBrokerFactory.java:108)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:72)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:71)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:54)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:115)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:74)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:148)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:90)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
java.lang.reflect.Method.invoke(Unknown Source)
INFO   | jvm 1| 

[jira] [Updated] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check

[Claudio Tagliola (JIRA)]

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

Claudio Tagliola updated AMQ-6142:
--
Description: 
In our environment we use an embedded broker. On one topic where compression is 
enabled, the server is also listening in on the messages. From ActiveMQ 5.10.0 
up to 5.13.0, we encounter DataFormatException: incorrect header check 
exceptions on the tcp clients due to corruption of the payload. Attached are a 
test server and client. At some point, the client will exit due to mentioned 
exception. Increase chances by running multiple clients. This scenario works 
with 5.8.0 and 5.9.1.

If the server has multiple consumers on the same topic, they will encounter 
corruption as well, but this has other side-effects.

  was:
In our environment we use an embedded broker. On one topic where compression is 
enabled, the server is also listening in on the messages. From ActiveMQ 5.10.0 
up to 5.13.0, we encounter DataFormatException: incorrect header check 
exceptions on the tcp clients due to corruption of the payload. Attached are a 
test server and client. At some point, the client will exit due to mentioned 
exception. Increase chances by running multiple clients.

If the server has multiple consumers on the same topic, they will encounter 
corruption as well, but this has other side-effects.


> ActiveMQBytesMessage decompress throws DataFormatException incorrect header 
> check
> -
>
> Key: AMQ-6142
> URL: https://issues.apache.org/jira/browse/AMQ-6142
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.10.2, 5.12.1, 5.11.3, 5.13.0
>Reporter: Claudio Tagliola
> Attachments: Client.java, MessageListener.java, Server.java, pom.xml
>
>
> In our environment we use an embedded broker. On one topic where compression 
> is enabled, the server is also listening in on the messages. From ActiveMQ 
> 5.10.0 up to 5.13.0, we encounter DataFormatException: incorrect header check 
> exceptions on the tcp clients due to corruption of the payload. Attached are 
> a test server and client. At some point, the client will exit due to 
> mentioned exception. Increase chances by running multiple clients. This 
> scenario works with 5.8.0 and 5.9.1.
> If the server has multiple consumers on the same topic, they will encounter 
> corruption as well, but this has other side-effects.



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

[jira] [Commented] (AMQ-6118) ActiveMQ SSL CRL Checking via OCSP

[Marko Jovanovic (JIRA)]

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

Marko Jovanovic commented on AMQ-6118:
--

Thank you Christopher.

Do you mean to set it like this in activemq.bat:
set ACTIVEMQ_SSL_OPTS="-Dcom.sun.security.enableCRLDP=true -Docsp.enable=true 
-Docsp.responderURL=http://myOCSP-url;
When I echo the ACTIVEMQ_SSL_OPTS, I get exactly my configured line.
Could you please tell me when I have to execute the activemq.bat? Also I asked 
myself when does Activemq check the CRL via OCSP (when Client is connecting or 
earlier)?
Sorry for that many questions but I got no luck on the mailinglists.

many thanks in advance,
Marko


> ActiveMQ SSL CRL Checking via OCSP
> --
>
> Key: AMQ-6118
> URL: https://issues.apache.org/jira/browse/AMQ-6118
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.12.1
> Environment: Windows Server 2012R2 with ActiveMQ Windows Distribution
>Reporter: Marko Jovanovic
>
> For some unknown reason, the CRL Check via OCSP isn't working in Windows 
> ActiveMQ 5.12.1
> After reviewing the Linux distribution of Activemq there was a configuration 
> line found in the file bin/env.
> The Config in Linux Distribution looked like:
> # Set additional JSE arguments
> #ACTIVEMQ_SSL_OPTS="-Dcom.sun.security.enableCRLDP=true -Docsp.enable=true 
> -Docsp.responderURL=http://ocsp.example.net:80;
> Where to set it in Windows file distribution? 
> Tried to set it in activemq file but no success. I couldn't see any request 
> going to the responder URL which I configured.
> Think there is a general Problem with the code concerning OCSP functionality.



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

[jira] [Updated] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check

[Claudio Tagliola (JIRA)]

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

Claudio Tagliola updated AMQ-6142:
--
Attachment: pom.xml
Server.java
MessageListener.java
Client.java

> ActiveMQBytesMessage decompress throws DataFormatException incorrect header 
> check
> -
>
> Key: AMQ-6142
> URL: https://issues.apache.org/jira/browse/AMQ-6142
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.10.2, 5.12.1, 5.11.3, 5.13.0
>Reporter: Claudio Tagliola
> Attachments: Client.java, MessageListener.java, Server.java, pom.xml
>
>
> In our environment we use an embedded broker. On one topic, the server is 
> also listening in on the messages. From ActiveMQ 5.10.0 up to 5.13.0, we 
> encounter DataFormatException: incorrect header check exceptions on the tcp 
> clients due to corruption of the payload. Attached are a test server and 
> client. At some point, the client will exit due to mentioned exception. 
> Increase chances by running multiple clients.
> If the server has multiple consumers on the same topic, they will encounter 
> corruption as well, but this has other side-effects.



--
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 subversion and git services (JIRA)]

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

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

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

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-359) [TestSuite] IBM JDK does not allow to instrument classes

[ASF subversion and git services (JIRA)]

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

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

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

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 
> 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 
> 

[jira] [Comment Edited] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ

[Tristan Leask (JIRA)]

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

Tristan Leask edited comment on AMQ-5100 at 1/25/16 5:10 PM:
-

Ok, I am trying to do this as well, and came across the same error.  I got 
passed this error by editing the SSLContext definition like so...

{code}

{code}

Note, my wrapper.conf file had all the trust and key store entries commented 
out (running on Windows).

Even though you get past this error, you then come across a "Transport 
Connector could not be registered in JMX" due to the random number generator 
and FIPS Mode...

{code}
INFO   | jvm 1| 2016/01/25 12:57:11 | 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'org.apache.activemq.xbean.XBeanBrokerService#0' defined in class 
path resource [activemq.xml]: Invocation of init method failed; nested 
exception is java.io.IOException: Transport Connector could not be registered 
in JMX: FIPS mode: SecureRandom must be from provider SunPKCS11-NSSfips
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:64)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.xbean.spring.context.ResourceXmlApplicationContext.(ResourceXmlApplicationContext.java:52)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory$1.(XBeanBrokerFactory.java:108)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory.createApplicationContext(XBeanBrokerFactory.java:108)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:72)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:71)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:54)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:115)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:74)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:148)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:90)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1| 2016/01/25 12:57:11 |   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
INFO   

[jira] [Commented] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ

[Tristan Leask (JIRA)]

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

Tristan Leask commented on AMQ-5100:


Resolved

Managed to get past that previous error and now the ActiveMQ is starting under 
Java running in FIPS Mode, and thus hopefully, ActiveMQ is running ok with 
FIPS.  Had to edit the SSLContext to the following...

{code}

{code}

Basically, the stores should be pointing to the NSS certificate DB, and the 
Store Types and Secure Random Number Generator Algorithms should be set to 
PKCS11.

Note, I have disabled JMX on my broker as I don't need it, not sure if this has 
any affect.

> PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
> --
>
> Key: AMQ-5100
> URL: https://issues.apache.org/jira/browse/AMQ-5100
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Reporter: Jesse Sightler
>
> I have attempted to configure PKCS11/NSS support in ActiveMQ, however, I am 
> receiving the following exception:
> Caused by: java.io.FileNotFoundException: class path resource [NONE] cannot 
> be opened because it does not exist
> at 
> org.springframework.core.io.ClassPathResource.getInputStream(ClassPathResource.java:157)
> at 
> org.apache.activemq.spring.SpringSslContext.createKeyManagerKeyStore(SpringSslContext.java:119)
> at 
> org.apache.activemq.spring.SpringSslContext.createKeyManagers(SpringSslContext.java:88)
> at 
> org.apache.activemq.spring.SpringSslContext.afterPropertiesSet(SpringSslContext.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1581)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1522)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
> ... 40 more
> My configured sslContext for the broker looks like this:
> 
>  keyStore="NONE" keyStoreType="PKCS11" 
> keyStorePassword="password"
> trustStore="/etc/activemqssl/truststore.jks" 
> trustStorePassword="password"
> />
> 
> AFAIK, setting keyStore to "NONE" is the generally accepted way to do with 
> with PKCS11. The code should generate a warning at most for this, but instead 
> I receive the above exception and a failure to load the keystore.
> The activemq code looks like this (in 
> org.apache.activemq.spring.SpringSslContext):
> private KeyStore createKeyManagerKeyStore() throws Exception {
> if( keyStore ==null ) {
> return null;
> }
> KeyStore ks = KeyStore.getInstance(keyStoreType);
> InputStream is=Utils.resourceFromString(keyStore).getInputStream();
> try {
> ks.load(is, keyStorePassword==null? null : 
> keyStorePassword.toCharArray());
> } finally {
> is.close();
> }
> return ks;
> }
> It looks like this should just be setting "is" to null, generating a warning, 
> and then calling ks.load with the null inputstream (the nss library will load 
> the nss files based upon the nss.cfg file).



--
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-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[ASF subversion and git services (JIRA)]

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

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

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

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=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] [Reopened] (AMQCPP-492) Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)

[Josh Schwartz (JIRA)]

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

Josh Schwartz reopened AMQCPP-492:
--

I saw this issue again with ActiveMQ-CPP 3.8.4 and have additional information 
which I hope to be able to attach to the issue (complete thread dumps for two 
occurrences.)  I looked through all the release notes for ActiveMQ-CPP 3.9.0 
and 3.9.1 and I don't see anything which looks like this issue but I will begin 
the process of upgrading to 3.9.1 none-the-less.

> Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)
> ---
>
> Key: AMQCPP-492
> URL: https://issues.apache.org/jira/browse/AMQCPP-492
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf
>Affects Versions: 3.5.0
> Environment: $ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 6.3 (Santiago)
> $ cat /proc/version
> Linux version 2.6.32-279.el6.x86_64 (mockbu...@x86-008.build.bos.redhat.com) 
> (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Wed Jun 13 
> 18:24:36 EDT 2012
>Reporter: Josh Schwartz
>Assignee: Timothy Bish
>
> This happened during a failover test so it's likely that there were 
> non-nominal things occurring such as connections being terminated abruptly.
> I looked at the release notes for 3.6.0 and 3.7.0 and I don't see a fix for 
> this issue.
> Program terminated with signal 11, Segmentation fault.
> #0  0x003eec888ea3 in memcpy () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install 
> apr-util-1.3.9-3.el6_0.1.x86_64 cyrus-sasl-lib-2.1.23-13.el6.x86_64 
> db4-4.7.25-17.el6.x86_64 expat-2.0.1-11.el6_2.x86_64 
> glibc-2.12-1.80.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 
> krb5-libs-1.9-33.el6.x86_64 libcom_err-1.41.12-12.el6.x86_64 
> libgcc-4.4.6-4.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 
> libstdc++-4.4.6-4.el6.x86_64 libuuid-2.17.2-12.7.el6.x86_64 
> nspr-devel-4.9-1.el6.x86_64 nss-3.13.3-6.el6.x86_64 
> nss-softokn-freebl-3.12.9-11.el6.x86_64 nss-util-3.13.3-2.el6.x86_64 
> openssl-1.0.0-20.el6_2.5.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) where
> #0  0x003eec888ea3 in memcpy () from /lib64/libc.so.6
> #1  0x003ef489d1c6 in std::basic_string std::allocator >::_Rep::_M_clone(std::allocator const&, unsigned 
> long) () from /usr/lib64/libstdc++.so.6
> #2  0x003ef489d26c in std::basic_string std::allocator >::basic_string(std::basic_string std::char_traits, std::allocator > const&) ()
>from /usr/lib64/libstdc++.so.6
> #3  0x0041d75a in std::basic_string std::allocator > std::operator+ std::allocator >(std::basic_string std::allocator > const&, std::basic_string std::char_traits, std::allocator > const&) ()
> #4  0x7f04aeb66a0b in MutexProperties (this=) at 
> decaf/util/concurrent/Mutex.cpp:48
> #5  decaf::util::concurrent::Mutex::Mutex (this=) at 
> decaf/util/concurrent/Mutex.cpp:72
> #6  0x7f04ae7db9e0 in AbstractCollection (this=0x7f0398002530) at 
> ./decaf/util/AbstractCollection.h:65
> #7  AbstractList (this=0x7f0398002530) at ./decaf/util/AbstractList.h:341
> #8  ArrayList (this=0x7f0398002530) at ./decaf/util/ArrayList.h:49
> #9  activemq::commands::ActiveMQDestination::ActiveMQDestination 
> (this=0x7f0398002530)
> at activemq/commands/ActiveMQDestination.cpp:74
> #10 0x7f04ae827d49 in activemq::commands::ActiveMQTopic::ActiveMQTopic 
> (this=0x7f0398002530)
> at activemq/commands/ActiveMQTopic.cpp:26
> #11 0x7f04aea7a15a in 
> activemq::wireformat::openwire::marshal::generated::ActiveMQTopicMarshaller::createObject
>  (this=)
> at 
> activemq/wireformat/openwire/marshal/generated/ActiveMQTopicMarshaller.cpp:45
> #12 0x7f04aea64c8b in 
> activemq::wireformat::openwire::OpenWireFormat::tightUnmarshalNestedObject (
> this=0x109ccf0, dis=0x109d0e0, bs=0x7f03aaf11b50) at 
> activemq/wireformat/openwire/OpenWireFormat.cpp:400
> #13 0x7f04aea6bccc in 
> activemq::wireformat::openwire::marshal::BaseDataStreamMarshaller::tightUnmarshalCachedObject
>  (this=, wireFormat=, dataIn= optimized out>,
> bs=) at 
> activemq/wireformat/openwire/marshal/BaseDataStreamMarshaller.cpp:51
> #14 0x7f04aea99c16 in 
> activemq::wireformat::openwire::marshal::generated::MessageDispatchMarshaller::tightUnmarshal
>  (this=0x1140910, wireFormat=0x109ccf0, dataStructure=, 
> dataIn=0x109d0e0,
> bs=0x7f03aaf11b50) at 
> activemq/wireformat/openwire/marshal/generated/MessageDispatchMarshaller.cpp:65
> #15 0x7f04aea65bb1 in 
> activemq::wireformat::openwire::OpenWireFormat::doUnmarshal (this=0x109ccf0,
> dis=0x109d0e0) at 

[jira] [Commented] (AMQCPP-492) Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)

[Josh Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQCPP-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116117#comment-15116117
 ] 

Josh Schwartz commented on AMQCPP-492:
--

These latest instances of this issue occurred during what was a nominal 
shutdown of the process as far as I can tell.

> Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)
> ---
>
> Key: AMQCPP-492
> URL: https://issues.apache.org/jira/browse/AMQCPP-492
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf
>Affects Versions: 3.5.0, 3.8.4
> Environment: $ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 6.3 (Santiago)
> $ cat /proc/version
> Linux version 2.6.32-279.el6.x86_64 (mockbu...@x86-008.build.bos.redhat.com) 
> (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Wed Jun 13 
> 18:24:36 EDT 2012
>Reporter: Josh Schwartz
>Assignee: Timothy Bish
> Attachments: core.2740-gdb.log, core.8681-gdb.log
>
>
> This happened during a failover test so it's likely that there were 
> non-nominal things occurring such as connections being terminated abruptly.
> I looked at the release notes for 3.6.0 and 3.7.0 and I don't see a fix for 
> this issue.
> Program terminated with signal 11, Segmentation fault.
> #0  0x003eec888ea3 in memcpy () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install 
> apr-util-1.3.9-3.el6_0.1.x86_64 cyrus-sasl-lib-2.1.23-13.el6.x86_64 
> db4-4.7.25-17.el6.x86_64 expat-2.0.1-11.el6_2.x86_64 
> glibc-2.12-1.80.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 
> krb5-libs-1.9-33.el6.x86_64 libcom_err-1.41.12-12.el6.x86_64 
> libgcc-4.4.6-4.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 
> libstdc++-4.4.6-4.el6.x86_64 libuuid-2.17.2-12.7.el6.x86_64 
> nspr-devel-4.9-1.el6.x86_64 nss-3.13.3-6.el6.x86_64 
> nss-softokn-freebl-3.12.9-11.el6.x86_64 nss-util-3.13.3-2.el6.x86_64 
> openssl-1.0.0-20.el6_2.5.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) where
> #0  0x003eec888ea3 in memcpy () from /lib64/libc.so.6
> #1  0x003ef489d1c6 in std::basic_string std::allocator >::_Rep::_M_clone(std::allocator const&, unsigned 
> long) () from /usr/lib64/libstdc++.so.6
> #2  0x003ef489d26c in std::basic_string std::allocator >::basic_string(std::basic_string std::char_traits, std::allocator > const&) ()
>from /usr/lib64/libstdc++.so.6
> #3  0x0041d75a in std::basic_string std::allocator > std::operator+ std::allocator >(std::basic_string std::allocator > const&, std::basic_string std::char_traits, std::allocator > const&) ()
> #4  0x7f04aeb66a0b in MutexProperties (this=) at 
> decaf/util/concurrent/Mutex.cpp:48
> #5  decaf::util::concurrent::Mutex::Mutex (this=) at 
> decaf/util/concurrent/Mutex.cpp:72
> #6  0x7f04ae7db9e0 in AbstractCollection (this=0x7f0398002530) at 
> ./decaf/util/AbstractCollection.h:65
> #7  AbstractList (this=0x7f0398002530) at ./decaf/util/AbstractList.h:341
> #8  ArrayList (this=0x7f0398002530) at ./decaf/util/ArrayList.h:49
> #9  activemq::commands::ActiveMQDestination::ActiveMQDestination 
> (this=0x7f0398002530)
> at activemq/commands/ActiveMQDestination.cpp:74
> #10 0x7f04ae827d49 in activemq::commands::ActiveMQTopic::ActiveMQTopic 
> (this=0x7f0398002530)
> at activemq/commands/ActiveMQTopic.cpp:26
> #11 0x7f04aea7a15a in 
> activemq::wireformat::openwire::marshal::generated::ActiveMQTopicMarshaller::createObject
>  (this=)
> at 
> activemq/wireformat/openwire/marshal/generated/ActiveMQTopicMarshaller.cpp:45
> #12 0x7f04aea64c8b in 
> activemq::wireformat::openwire::OpenWireFormat::tightUnmarshalNestedObject (
> this=0x109ccf0, dis=0x109d0e0, bs=0x7f03aaf11b50) at 
> activemq/wireformat/openwire/OpenWireFormat.cpp:400
> #13 0x7f04aea6bccc in 
> activemq::wireformat::openwire::marshal::BaseDataStreamMarshaller::tightUnmarshalCachedObject
>  (this=, wireFormat=, dataIn= optimized out>,
> bs=) at 
> activemq/wireformat/openwire/marshal/BaseDataStreamMarshaller.cpp:51
> #14 0x7f04aea99c16 in 
> activemq::wireformat::openwire::marshal::generated::MessageDispatchMarshaller::tightUnmarshal
>  (this=0x1140910, wireFormat=0x109ccf0, dataStructure=, 
> dataIn=0x109d0e0,
> bs=0x7f03aaf11b50) at 
> activemq/wireformat/openwire/marshal/generated/MessageDispatchMarshaller.cpp:65
> #15 0x7f04aea65bb1 in 
> activemq::wireformat::openwire::OpenWireFormat::doUnmarshal (this=0x109ccf0,
> dis=0x109d0e0) at activemq/wireformat/openwire/OpenWireFormat.cpp:295
> #16 0x7f04aea65fb7 in 
> activemq::wireformat::openwire::OpenWireFormat::unmarshal (this=0x109ccf0,
> transport=, 

[jira] [Updated] (AMQCPP-492) Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)

[Josh Schwartz (JIRA)]

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

Josh Schwartz updated AMQCPP-492:
-
Environment: 
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.7 (Santiago)
$ cat /proc/version
Linux version 2.6.32-573.7.1.el6.x86_64 
(mockbu...@x86-31.build.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red 
Hat 4.4.7-16) (GCC) ) #1 SMP Thu Sep 10 13:42:16 EDT 2015

(older from 3.5.0 instance)
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
$ cat /proc/version
Linux version 2.6.32-279.el6.x86_64 (mockbu...@x86-008.build.bos.redhat.com) 
(gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Wed Jun 13 
18:24:36 EDT 2012

  was:
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
$ cat /proc/version
Linux version 2.6.32-279.el6.x86_64 (mockbu...@x86-008.build.bos.redhat.com) 
(gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Wed Jun 13 
18:24:36 EDT 2012


> Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)
> ---
>
> Key: AMQCPP-492
> URL: https://issues.apache.org/jira/browse/AMQCPP-492
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: Decaf
>Affects Versions: 3.5.0, 3.8.4
> Environment: $ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 6.7 (Santiago)
> $ cat /proc/version
> Linux version 2.6.32-573.7.1.el6.x86_64 
> (mockbu...@x86-31.build.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red 
> Hat 4.4.7-16) (GCC) ) #1 SMP Thu Sep 10 13:42:16 EDT 2015
> (older from 3.5.0 instance)
> $ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 6.3 (Santiago)
> $ cat /proc/version
> Linux version 2.6.32-279.el6.x86_64 (mockbu...@x86-008.build.bos.redhat.com) 
> (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Wed Jun 13 
> 18:24:36 EDT 2012
>Reporter: Josh Schwartz
>Assignee: Timothy Bish
> Attachments: core.2740-gdb.log, core.8681-gdb.log
>
>
> This happened during a failover test so it's likely that there were 
> non-nominal things occurring such as connections being terminated abruptly.
> I looked at the release notes for 3.6.0 and 3.7.0 and I don't see a fix for 
> this issue.
> Program terminated with signal 11, Segmentation fault.
> #0  0x003eec888ea3 in memcpy () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install 
> apr-util-1.3.9-3.el6_0.1.x86_64 cyrus-sasl-lib-2.1.23-13.el6.x86_64 
> db4-4.7.25-17.el6.x86_64 expat-2.0.1-11.el6_2.x86_64 
> glibc-2.12-1.80.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 
> krb5-libs-1.9-33.el6.x86_64 libcom_err-1.41.12-12.el6.x86_64 
> libgcc-4.4.6-4.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 
> libstdc++-4.4.6-4.el6.x86_64 libuuid-2.17.2-12.7.el6.x86_64 
> nspr-devel-4.9-1.el6.x86_64 nss-3.13.3-6.el6.x86_64 
> nss-softokn-freebl-3.12.9-11.el6.x86_64 nss-util-3.13.3-2.el6.x86_64 
> openssl-1.0.0-20.el6_2.5.x86_64 zlib-1.2.3-27.el6.x86_64
> (gdb) where
> #0  0x003eec888ea3 in memcpy () from /lib64/libc.so.6
> #1  0x003ef489d1c6 in std::basic_string std::allocator >::_Rep::_M_clone(std::allocator const&, unsigned 
> long) () from /usr/lib64/libstdc++.so.6
> #2  0x003ef489d26c in std::basic_string std::allocator >::basic_string(std::basic_string std::char_traits, std::allocator > const&) ()
>from /usr/lib64/libstdc++.so.6
> #3  0x0041d75a in std::basic_string std::allocator > std::operator+ std::allocator >(std::basic_string std::allocator > const&, std::basic_string std::char_traits, std::allocator > const&) ()
> #4  0x7f04aeb66a0b in MutexProperties (this=) at 
> decaf/util/concurrent/Mutex.cpp:48
> #5  decaf::util::concurrent::Mutex::Mutex (this=) at 
> decaf/util/concurrent/Mutex.cpp:72
> #6  0x7f04ae7db9e0 in AbstractCollection (this=0x7f0398002530) at 
> ./decaf/util/AbstractCollection.h:65
> #7  AbstractList (this=0x7f0398002530) at ./decaf/util/AbstractList.h:341
> #8  ArrayList (this=0x7f0398002530) at ./decaf/util/ArrayList.h:49
> #9  activemq::commands::ActiveMQDestination::ActiveMQDestination 
> (this=0x7f0398002530)
> at activemq/commands/ActiveMQDestination.cpp:74
> #10 0x7f04ae827d49 in activemq::commands::ActiveMQTopic::ActiveMQTopic 
> (this=0x7f0398002530)
> at activemq/commands/ActiveMQTopic.cpp:26
> #11 0x7f04aea7a15a in 
> activemq::wireformat::openwire::marshal::generated::ActiveMQTopicMarshaller::createObject
>  (this=)
> at 
> activemq/wireformat/openwire/marshal/generated/ActiveMQTopicMarshaller.cpp:45
> #12 0x7f04aea64c8b in 
> 

[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-361) Improve encoding on ServerLocator's properties

[ASF subversion and git services (JIRA)]

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

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

Commit e5652d39bccaddb0d75f78026eea016243276f56 in activemq-artemis's branch 
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=e5652d3 ]

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-361) Improve encoding on ServerLocator's properties

[ASF subversion and git services (JIRA)]

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

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

Commit e5652d39bccaddb0d75f78026eea016243276f56 in activemq-artemis's branch 
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=e5652d3 ]

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=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] [Closed] (ARTEMIS-361) Improve encoding on ServerLocator's properties

[clebert suconic (JIRA)]

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

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

> 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] [Created] (AMQ-6143) Security Vulnerabilities in 5.13.0

[Kevin Goerlitz (JIRA)]

Kevin Goerlitz created AMQ-6143:
---

 Summary: Security Vulnerabilities in 5.13.0
 Key: AMQ-6143
 URL: https://issues.apache.org/jira/browse/AMQ-6143
 Project: ActiveMQ
  Issue Type: Bug
  Components: Distribution
Affects Versions: 5.13.0
Reporter: Kevin Goerlitz


A security vulnerabilities scan of ActiveMQ 5.13.0 distribution reports issues 
with org.springframework spring-core 4.1.8 and org.apache.taglibs 
taglibs-standard-impl 1.2.1.
Please upgrade org.springframework to at least version 4.1.9 (preferably 
version 4.2.4) and org.apache.taglibs to version 1.2.3 or 1.2.5.



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

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

[clebert suconic (JIRA)]

clebert suconic created ARTEMIS-361:
---

 Summary: 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.1.0, 1.0.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] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ

[Arthur Naseef (JIRA)]

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

Arthur Naseef commented on AMQ-5100:


This seems like a reasonable scenario and fix.  Anytime the SSL context needs 
to be customized, this is how it must be done.

Can we close this ticket?

> PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
> --
>
> Key: AMQ-5100
> URL: https://issues.apache.org/jira/browse/AMQ-5100
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Reporter: Jesse Sightler
>
> I have attempted to configure PKCS11/NSS support in ActiveMQ, however, I am 
> receiving the following exception:
> Caused by: java.io.FileNotFoundException: class path resource [NONE] cannot 
> be opened because it does not exist
> at 
> org.springframework.core.io.ClassPathResource.getInputStream(ClassPathResource.java:157)
> at 
> org.apache.activemq.spring.SpringSslContext.createKeyManagerKeyStore(SpringSslContext.java:119)
> at 
> org.apache.activemq.spring.SpringSslContext.createKeyManagers(SpringSslContext.java:88)
> at 
> org.apache.activemq.spring.SpringSslContext.afterPropertiesSet(SpringSslContext.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1581)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1522)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)
> ... 40 more
> My configured sslContext for the broker looks like this:
> 
>  keyStore="NONE" keyStoreType="PKCS11" 
> keyStorePassword="password"
> trustStore="/etc/activemqssl/truststore.jks" 
> trustStorePassword="password"
> />
> 
> AFAIK, setting keyStore to "NONE" is the generally accepted way to do with 
> with PKCS11. The code should generate a warning at most for this, but instead 
> I receive the above exception and a failure to load the keystore.
> The activemq code looks like this (in 
> org.apache.activemq.spring.SpringSslContext):
> private KeyStore createKeyManagerKeyStore() throws Exception {
> if( keyStore ==null ) {
> return null;
> }
> KeyStore ks = KeyStore.getInstance(keyStoreType);
> InputStream is=Utils.resourceFromString(keyStore).getInputStream();
> try {
> ks.load(is, keyStorePassword==null? null : 
> keyStorePassword.toCharArray());
> } finally {
> is.close();
> }
> return ks;
> }
> It looks like this should just be setting "is" to null, generating a warning, 
> and then calling ks.load with the null inputstream (the nss library will load 
> the nss files based upon the nss.cfg file).



--
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] [Resolved] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes

[Miroslav Novak (JIRA)]

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

Miroslav Novak resolved ARTEMIS-359.

Resolution: Fixed

> [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 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   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=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] [Created] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes

[Miroslav Novak (JIRA)]

Miroslav Novak created ARTEMIS-359:
--

 Summary: [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 
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-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[ASF subversion and git services (JIRA)]

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

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

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

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=15116505#comment-15116505
 ] 

ASF GitHub Bot commented on ARTEMIS-358:


Github user asfgit closed the pull request at:

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


> 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] [Closed] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[clebert suconic (JIRA)]

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

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

> 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
> Fix For: 1.3.0
>
>
> 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] [Updated] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe

[clebert suconic (JIRA)]

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

clebert suconic updated ARTEMIS-358:

Fix Version/s: 1.3.0

> 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
> Fix For: 1.3.0
>
>
> 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)