[jira] [Closed] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe
[ 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
[ 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)
[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (AMQ-6143) Security Vulnerabilities in 5.13.0
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] [Closed] (ARTEMIS-361) Improve encoding on ServerLocator's properties
[ 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] [Commented] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-361) Improve encoding on ServerLocator's properties
[ https://issues.apache.org/jira/browse/ARTEMIS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/ARTEMIS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-361) Improve encoding on ServerLocator's properties
[ https://issues.apache.org/jira/browse/ARTEMIS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116242#comment-15116242 ] ASF GitHub Bot commented on ARTEMIS-361: Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/345 > 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
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116218#comment-15116218 ] ASF GitHub Bot commented on ARTEMIS-358: Github user jbertram commented on the pull request: https://github.com/apache/activemq-artemis/pull/346#issuecomment-174705757 I think @howardgao should take a look at this before it's merged. > Topic disappears when STOMP subscriber client disconnects without unsubscribe > - > > Key: ARTEMIS-358 > URL: https://issues.apache.org/jira/browse/ARTEMIS-358 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Stomp >Affects Versions: 1.2.0, 1.3.0 >Reporter: Ville Skyttä >Assignee: Justin Bertram > > When a STOMP client which has a subscription to a topic disconnects without > unsubscribing first, the topic seems to disappear. > Reproducer: > # configure a server with a topic (e.g. jms.topic.testtopic) and start it > # STOMP: connect to the server > # STOMP: subscribe to the topic > # STOMP: disconnect from the server (without unsubscribing first) > # STOMP: connect to the server again > # STOMP: send a message to the topic > At this point the server responds with "AMQ339001: Destination does not > exist: jms.topic.testtopic" > At this point the topic is still visible in jconsole though so maybe it has > not disappeared entirely, but anyway, messages cannot be sent to it with > STOMP any more. Restarting the server makes it possible to send to it again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116215#comment-15116215 ] ASF GitHub Bot commented on ARTEMIS-358: GitHub user jbertram opened a pull request: https://github.com/apache/activemq-artemis/pull/346 ARTEMIS-358 topic mistakenly removed with sub The problem here is that the management notification listener was mistakenly removing the topic itself instead of just the non-durable subscription. In general I can't see why StompProtocolManager even needs to keep track of the destinations when the broker already does that. As far as I can tell it is redundant and it's clearly error-prone. Therefore I'm removing the destination tracking from StompProtocolManager altogether. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-358 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/346.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #346 commit 960e29afadcd3b5848a95406ad14d48099fb6c3c Author: jbertram Date: 2016-01-25T22:36:02Z ARTEMIS-358 topic mistakenly removed with sub The problem here is that the management notification listener was mistakenly removing the topic itself instead of just the non-durable subscription. In general I can't see why StompProtocolManager even needs to keep track of the destinations when the broker already does that. As far as I can tell it is redundant and it's clearly error-prone. Therefore I'm removing the destination tracking from StompProtocolManager altogether. > Topic disappears when STOMP subscriber client disconnects without unsubscribe > - > > Key: ARTEMIS-358 > URL: https://issues.apache.org/jira/browse/ARTEMIS-358 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Stomp >Affects Versions: 1.2.0, 1.3.0 >Reporter: Ville Skyttä >Assignee: Justin Bertram > > When a STOMP client which has a subscription to a topic disconnects without > unsubscribing first, the topic seems to disappear. > Reproducer: > # configure a server with a topic (e.g. jms.topic.testtopic) and start it > # STOMP: connect to the server > # STOMP: subscribe to the topic > # STOMP: disconnect from the server (without unsubscribing first) > # STOMP: connect to the server again > # STOMP: send a message to the topic > At this point the server responds with "AMQ339001: Destination does not > exist: jms.topic.testtopic" > At this point the topic is still visible in jconsole though so maybe it has > not disappeared entirely, but anyway, messages cannot be sent to it with > STOMP any more. Restarting the server makes it possible to send to it again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-361) Improve encoding on ServerLocator's properties
[ https://issues.apache.org/jira/browse/ARTEMIS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (ARTEMIS-361) Improve encoding on ServerLocator's properties
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] [Updated] (AMQCPP-492) Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)
[ 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 > activemq::wireformat::openwire::OpenWireFormat::tightUnmarshalNestedObject ( > this=0x109ccf0, dis=0x109d0e0, bs=0x7f03aaf11b50) at > activemq/wireformat/openwire/OpenW
[jira] [Commented] (AMQCPP-492) Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)
[ https://issues.apache.org/jira/browse/AMQCPP-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=, dis=0x109d0e0) at > activemq/wireformat/openwire/OpenWireFormat.cpp:230 > #17 0x7f04ae9c8350 in activemq::transp
[jira] [Updated] (AMQCPP-492) Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)
[ https://issues.apache.org/jira/browse/AMQCPP-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Schwartz updated AMQCPP-492: - Attachment: core.8681-gdb.log core.2740-gdb.log These core analysis files show a complete thread dump for two separate instances of this issue. > 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=, dis=0x109d0e0) at > activemq/wireformat/openwire/OpenWireFormat.cpp:230 > #17 0x7f04ae9c8350 in activemq::transport::IOTran
[jira] [Updated] (AMQCPP-492) Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)
[ https://issues.apache.org/jira/browse/AMQCPP-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Schwartz updated AMQCPP-492: - Affects Version/s: 3.8.4 > 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 > > 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=, dis=0x109d0e0) at > activemq/wireformat/openwire/OpenWireFormat.cpp:230 > #17 0x7f04ae9c8350 in activemq::transport::IOTransport::run > (this=0xf6d6f0) > at activemq/transport/IOTransport.cpp:247 > #18 0x7f04aeafa84f in (anonymous namespace)::runCallback (arg=0x13afa20) > at decaf/internal/util/concurrent/Th
[jira] [Reopened] (AMQCPP-492) Seg fault in decaf::util::concurrent::Mutex::Mutex MutexProperties (memcpy)
[ 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 activemq/wireformat/openwire/OpenWireFormat.cpp:295 > #16 0x7f04aea65fb7 in > activemq::wireformat::openwire::OpenWireFormat::unmarshal (this=0x109ccf0, > trans
[jira] [Assigned] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-358: -- Assignee: Justin Bertram > 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] [Comment Edited] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Commented] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-359) [TestSuite] IBM JDK does not allow to instrument classes
[ https://issues.apache.org/jira/browse/ARTEMIS-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-359) [TestSuite] IBM JDK does not allow to instrument classes
[ https://issues.apache.org/jira/browse/ARTEMIS-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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) >
[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15115471#comment-15115471 ] ASF GitHub Bot commented on ARTEMIS-358: Github user clebertsuconic commented on the pull request: https://github.com/apache/activemq-artemis/pull/341#issuecomment-174561872 I am merging the test > Topic disappears when STOMP subscriber client disconnects without unsubscribe > - > > Key: ARTEMIS-358 > URL: https://issues.apache.org/jira/browse/ARTEMIS-358 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Stomp >Affects Versions: 1.2.0, 1.3.0 >Reporter: Ville Skyttä > > When a STOMP client which has a subscription to a topic disconnects without > unsubscribing first, the topic seems to disappear. > Reproducer: > # configure a server with a topic (e.g. jms.topic.testtopic) and start it > # STOMP: connect to the server > # STOMP: subscribe to the topic > # STOMP: disconnect from the server (without unsubscribing first) > # STOMP: connect to the server again > # STOMP: send a message to the topic > At this point the server responds with "AMQ339001: Destination does not > exist: jms.topic.testtopic" > At this point the topic is still visible in jconsole though so maybe it has > not disappeared entirely, but anyway, messages cannot be sent to it with > STOMP any more. Restarting the server makes it possible to send to it again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-360) [Testsuite] PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails on timeout waiting for stop paging
[ https://issues.apache.org/jira/browse/ARTEMIS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-360) [Testsuite] PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails on timeout waiting for stop paging
[ https://issues.apache.org/jira/browse/ARTEMIS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (ARTEMIS-360) [Testsuite] PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails on timeout waiting for stop paging
[ https://issues.apache.org/jira/browse/ARTEMIS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Styk resolved ARTEMIS-360. - Resolution: Fixed > [Testsuite] PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails on > timeout waiting for stop paging > > > Key: ARTEMIS-360 > URL: https://issues.apache.org/jira/browse/ARTEMIS-360 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.1.0 > Environment: RHEL7, IBM JDK 1.6 >Reporter: Martin Styk > > Execution of test package > org.apache.activemq.artemis.tests.integration.client.PagingTest.testSpreadMessagesWithFilterWithDeadConsumer > on slower machine timeouts during waiting for server to stop paging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15115328#comment-15115328 ] ASF GitHub Bot commented on ARTEMIS-358: Github user scop commented on the pull request: https://github.com/apache/activemq-artemis/pull/341#issuecomment-174532317 (Well, the subscription goes away too, but that's expected.) > Topic disappears when STOMP subscriber client disconnects without unsubscribe > - > > Key: ARTEMIS-358 > URL: https://issues.apache.org/jira/browse/ARTEMIS-358 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Stomp >Affects Versions: 1.2.0, 1.3.0 >Reporter: Ville Skyttä > > When a STOMP client which has a subscription to a topic disconnects without > unsubscribing first, the topic seems to disappear. > Reproducer: > # configure a server with a topic (e.g. jms.topic.testtopic) and start it > # STOMP: connect to the server > # STOMP: subscribe to the topic > # STOMP: disconnect from the server (without unsubscribing first) > # STOMP: connect to the server again > # STOMP: send a message to the topic > At this point the server responds with "AMQ339001: Destination does not > exist: jms.topic.testtopic" > At this point the topic is still visible in jconsole though so maybe it has > not disappeared entirely, but anyway, messages cannot be sent to it with > STOMP any more. Restarting the server makes it possible to send to it again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Comment Edited] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 | j
[jira] [Commented] (ARTEMIS-358) Topic disappears when STOMP subscriber client disconnects without unsubscribe
[ https://issues.apache.org/jira/browse/ARTEMIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15115247#comment-15115247 ] ASF GitHub Bot commented on ARTEMIS-358: Github user clebertsuconic commented on the pull request: https://github.com/apache/activemq-artemis/pull/341#issuecomment-174519897 it looks a non durable subscriber. The subscription should go away as expected, right? Or am I missing something? > 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] [Comment Edited] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 | j
[jira] [Updated] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check
[ 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] [Updated] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check
[ 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] [Updated] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check
[ 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] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check
[ https://issues.apache.org/jira/browse/AMQ-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check
[ https://issues.apache.org/jira/browse/AMQ-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ment
[jira] [Commented] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check
[ https://issues.apache.org/jira/browse/AMQ-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (AMQ-6142) ActiveMQBytesMessage decompress throws DataFormatException incorrect header check
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] (ARTEMIS-360) [Testsuite] PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails on timeout waiting for stop paging
[ https://issues.apache.org/jira/browse/ARTEMIS-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (ARTEMIS-360) [Testsuite] PagingTest.testSpreadMessagesWithFilterWithDeadConsumer fails on timeout waiting for stop paging
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] [Commented] (AMQ-5100) PKCS11 (NSS-FIPS) support in A-MQ/ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 org.apa
[jira] [Commented] (AMQ-6118) ActiveMQ SSL CRL Checking via OCSP
[ https://issues.apache.org/jira/browse/AMQ-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes
[ https://issues.apache.org/jira/browse/ARTEMIS-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pu
[jira] [Resolved] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes
[ 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 > org.apache.maven.surefire.booter.F
[jira] [Created] (ARTEMIS-359) [TestSuite] IBM JDK does not allow to instrument classes
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)