[jira] [Created] (ARTEMIS-410) STOMP destination prefixes should be configurable

[Lionel Cons (JIRA)]

Lionel Cons created ARTEMIS-410:
---

 Summary: STOMP destination prefixes should be configurable
 Key: ARTEMIS-410
 URL: https://issues.apache.org/jira/browse/ARTEMIS-410
 Project: ActiveMQ Artemis
  Issue Type: Improvement
  Components: Stomp
Reporter: Lionel Cons


Although the STOMP protocol does not attach any semantics to the destination 
names, most implementations do.

ActiveMQ 5.x, Apollo and RabbitMQ (at least) use the {{/queue/}} and 
{{/topic/}} prefixes to identify destinations that should behave like JMS 
queues and topics. Artemis differs.

To ease interoperability, it would be good to control the destination prefixes 
used by Artemis.

FWIW, this is what Apollo does. Its STOMP manual contains:

{quote}
The stomp configuration element can also be used to control how the destination 
headers are parsed and interpreted. The supported attributes are:
 - queue_prefix : Defaults to /queue/
 - topic_prefix : Defaults to /topic/
 - path_separator : Defaults to .
 - destination_separator : Defaults to ,
 - any_child_wildcard : Defaults to *
 - regex_wildcard_start : Defaults to \{
 - regex_wildcard_end : Defaults to \}
 - any_descendant_wildcard : Defaults to **
{quote}




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

[jira] [Created] (ARTEMIS-409) Authentication failures in STOMP should be clearly reported

[Lionel Cons (JIRA)]

Lionel Cons created ARTEMIS-409:
---

 Summary: Authentication failures in STOMP should be clearly 
reported
 Key: ARTEMIS-409
 URL: https://issues.apache.org/jira/browse/ARTEMIS-409
 Project: ActiveMQ Artemis
  Issue Type: Improvement
  Components: Stomp
Reporter: Lionel Cons


When supplying incorrect credentials to a STOMP connection, Artemis simply 
returns a generic {{Failed to connect}} ERROR frame.

To ease identifying the real cause of the failure, a more precise error message 
should be returned.

FWIW, here is what ActiveMQ 5.x returns: {{Security Error occurred: User name 
[dummy] or password is invalid}}.



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

[jira] [Created] (ARTEMIS-408) Version 1.2.0 information is incorrect in Jira

[Lionel Cons (JIRA)]

Lionel Cons created ARTEMIS-408:
---

 Summary: Version 1.2.0 information is incorrect in Jira
 Key: ARTEMIS-408
 URL: https://issues.apache.org/jira/browse/ARTEMIS-408
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: Lionel Cons
Priority: Minor


Looking at the [Road Map information in 
Jira|https://issues.apache.org/jira/browse/ARTEMIS/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel]
 we see that, for version 1.2.0:
 - 2 out of the 43 issues have not been resolved yet
 - it is not released yet

Jira versions should reflect what has been released.



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

[jira] [Created] (ARTEMIS-407) StompConnect references should be removed

[Lionel Cons (JIRA)]

Lionel Cons created ARTEMIS-407:
---

 Summary: StompConnect references should be removed
 Key: ARTEMIS-407
 URL: https://issues.apache.org/jira/browse/ARTEMIS-407
 Project: ActiveMQ Artemis
  Issue Type: Improvement
  Components: Stomp
Reporter: Lionel Cons
Priority: Minor


The manual contains a whole section on {{StompConnect}} with a broken link to 
{{http://stomp.codehaus.org/StompConnect}}.

AFAIK, {{StompConnect}} is dead so Artemis should not mention it.



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

[jira] [Updated] (ARTEMIS-406) STOMP acknowledgements should support transactions

[Lionel Cons (JIRA)]

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

Lionel Cons updated ARTEMIS-406:

Description: 
Artemis currently does not support transactional acknowledgements:

{quote}
Message acknowledgements are not transactional. The ACK frame can not be part 
of a transaction (it will be ignored if its transaction header is set).
{quote}

The STOMP 1.2 specification contains:

{quote}
Optionally, a transaction header MAY be specified, indicating that the message 
acknowledgment SHOULD be part of the named transaction.
{quote}

And other brokers (such as ActiveMQ 5.x) do support transactional 
acknowledgements.

Artemis should support them too.

  was:
Artemis currently does not support transactional acknowledgements:

{quote}
Message acknowledgements are not transactional. The ACK frame can not be part 
of a transaction (it will be ignored if its transaction header is set).
{quote}

The STOMP 1.2 specification contains:

{quote}
Optionally, a transaction header MAY be specified, indicating that the message 
acknowledgment SHOULD be part of the named transaction.{quote}

And other brokers (such as ActiveMQ 5.x) do support transactional 
acknowledgements.

Artemis should support them too.


> STOMP acknowledgements should support transactions
> --
>
> Key: ARTEMIS-406
> URL: https://issues.apache.org/jira/browse/ARTEMIS-406
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Stomp
>Reporter: Lionel Cons
>
> Artemis currently does not support transactional acknowledgements:
> {quote}
> Message acknowledgements are not transactional. The ACK frame can not be part 
> of a transaction (it will be ignored if its transaction header is set).
> {quote}
> The STOMP 1.2 specification contains:
> {quote}
> Optionally, a transaction header MAY be specified, indicating that the 
> message acknowledgment SHOULD be part of the named transaction.
> {quote}
> And other brokers (such as ActiveMQ 5.x) do support transactional 
> acknowledgements.
> Artemis should support them too.



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

[jira] [Created] (ARTEMIS-406) STOMP acknowledgements should support transactions

[Lionel Cons (JIRA)]

Lionel Cons created ARTEMIS-406:
---

 Summary: STOMP acknowledgements should support transactions
 Key: ARTEMIS-406
 URL: https://issues.apache.org/jira/browse/ARTEMIS-406
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Stomp
Reporter: Lionel Cons


Artemis currently does not support transactional acknowledgements:

{quote}
Message acknowledgements are not transactional. The ACK frame can not be part 
of a transaction (it will be ignored if its transaction header is set).
{quote}

The STOMP 1.2 specification contains:

{quote}
Optionally, a transaction header MAY be specified, indicating that the message 
acknowledgment SHOULD be part of the named transaction.{quote}

And other brokers (such as ActiveMQ 5.x) do support transactional 
acknowledgements.

Artemis should support them too.



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

[jira] [Created] (ARTEMIS-405) JMX attributes should be documented

[Lionel Cons (JIRA)]

Lionel Cons created ARTEMIS-405:
---

 Summary: JMX attributes should be documented
 Key: ARTEMIS-405
 URL: https://issues.apache.org/jira/browse/ARTEMIS-405
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: Lionel Cons
Priority: Minor


Using Jolokia, it is very easy to list all the attributes exposed by Artemis: 

{code}
$ jmx4perl http://localhost:8161/jolokia/ list 
'org.apache.activemq.artemis:brokerName="0.0.0.0",module=JMS,name="DLQ",serviceType=Queue,type=Broker'
 
org.apache.activemq.artemis:brokerName="0.0.0.0",module=JMS,name="DLQ",serviceType=Queue,type=Broker:
 
=
 

Attributes: 
Namejava.lang.String [ro], "Attribute 
exposed for management" 
ExpiryAddress   java.lang.String [ro], "Attribute 
exposed for management" 
RegistryBindings[Ljava.lang.String; [ro], "Attribute 
exposed for management" 
DeliveringCount int [ro], "Attribute exposed for 
management" 
Address java.lang.String [ro], "Attribute 
exposed for management" 
Selectorjava.lang.String [ro], "Attribute 
exposed for management" 
ScheduledCount  long [ro], "Attribute exposed for 
management" 
MessageCountlong [ro], "Attribute exposed for 
management" 
Paused  boolean [ro], "Attribute exposed for 
management" 
DeadLetterAddress   java.lang.String [ro], "Attribute 
exposed for management" 
FirstMessageTimestamp   java.lang.Long [ro], "Attribute exposed 
for management" 
ConsumerCount   int [ro], "Attribute exposed for 
management" 
MessagesAdded   long [ro], "Attribute exposed for 
management" 
FirstMessageAge java.lang.Long [ro], "Attribute exposed 
for management" 
Temporary   boolean [ro], "Attribute exposed for 
management" 
FirstMessageAsJSON  java.lang.String [ro], "Attribute 
exposed for management" 
Operations: 
int retryMessages() "Retry all messages on a DLQ to their 
respective original queues" 
java.lang.String listMessageCounterHistory() "List the message counters 
history" 
java.lang.String listMessageCounterHistoryAsHTML() "List the message 
counters history as HTML" 
java.util.Map listDeliveringMessages() "List all messages being delivered 
per consumer" 
[...] 
{code}

As you see, the operations are documented but not the attributes. They should 
be.



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

[jira] [Commented] (ARTEMIS-404) Having a space on the directory name will prevent the server from starting

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-404:


GitHub user clebertsuconic opened a pull request:

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

ARTEMIS-404 fixing space issues on scripts

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

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

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

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

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


commit a275dda89cf3ad1cfbb93eb53adb24c7af426659
Author: Clebert Suconic 
Date:   2016-02-18T23:16:21Z

ARTEMIS-404 fixing space issues on scripts

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




> Having a space on the directory name will prevent the server from starting
> --
>
> Key: ARTEMIS-404
> URL: https://issues.apache.org/jira/browse/ARTEMIS-404
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>




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

[jira] [Created] (ARTEMIS-404) Having a space on the directory name will prevent the server from starting

[clebert suconic (JIRA)]

clebert suconic created ARTEMIS-404:
---

 Summary: Having a space on the directory name will prevent the 
server from starting
 Key: ARTEMIS-404
 URL: https://issues.apache.org/jira/browse/ARTEMIS-404
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 1.2.0
Reporter: clebert suconic
Assignee: clebert suconic
 Fix For: 1.3.0






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

[jira] [Closed] (AMQ-6175) ActiveMQ webconsole breaks when supressMBean is used

[Jeff Genender (JIRA)]

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

Jeff Genender closed AMQ-6175.
--
Resolution: Fixed

Updates ManagementContext and ManagedRegionBroker to provide protected/public 
access produce filtered lists of the Mbeans for lists/sets.  Changed the 
BrokerView to use the filtered versions.

> ActiveMQ webconsole breaks when supressMBean is used
> 
>
> Key: AMQ-6175
> URL: https://issues.apache.org/jira/browse/AMQ-6175
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: webconsole
>Affects Versions: 5.12.1, 5.13.0, 5.13.1
>Reporter: Jeff Genender
>Priority: Blocker
> Fix For: 5.14.0, 5.13.2
>
>
> AMQ-5656 which included the suppressMBean function broke the web console that 
> comes with ActiveMQ.  The proxied calls to ManagedRegionBroker will obtain 
> objects that are not registered with the MBean server and thus the web 
> console breaks with invalid JSP when executed, which ultimately is caused by 
> javax.management.InstanceNotFoundException.  The fix for this is to have the 
> web calls filter out lists that contain any non-MBeans. 



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

[jira] [Commented] (AMQ-6175) ActiveMQ webconsole breaks when supressMBean is used

[ASF subversion and git services (JIRA)]

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

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

Commit 9224f27ba3bdf8001dae5930e994f42125d70a1c in activemq's branch 
refs/heads/activemq-5.13.x from [~jgenender]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=9224f27 ]

AMQ-6175 - Web console needs to only obtain lists of MBeans that are not 
suppressed.


> ActiveMQ webconsole breaks when supressMBean is used
> 
>
> Key: AMQ-6175
> URL: https://issues.apache.org/jira/browse/AMQ-6175
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: webconsole
>Affects Versions: 5.12.1, 5.13.0, 5.13.1
>Reporter: Jeff Genender
>Priority: Blocker
> Fix For: 5.14.0, 5.13.2
>
>
> AMQ-5656 which included the suppressMBean function broke the web console that 
> comes with ActiveMQ.  The proxied calls to ManagedRegionBroker will obtain 
> objects that are not registered with the MBean server and thus the web 
> console breaks with invalid JSP when executed, which ultimately is caused by 
> javax.management.InstanceNotFoundException.  The fix for this is to have the 
> web calls filter out lists that contain any non-MBeans. 



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

[jira] [Commented] (AMQ-6175) ActiveMQ webconsole breaks when supressMBean is used

[ASF subversion and git services (JIRA)]

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

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

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

AMQ-6175 - Web console needs to only obtain lists of MBeans that are not
suppressed.


> ActiveMQ webconsole breaks when supressMBean is used
> 
>
> Key: AMQ-6175
> URL: https://issues.apache.org/jira/browse/AMQ-6175
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: webconsole
>Affects Versions: 5.12.1, 5.13.0, 5.13.1
>Reporter: Jeff Genender
>Priority: Blocker
> Fix For: 5.14.0, 5.13.2
>
>
> AMQ-5656 which included the suppressMBean function broke the web console that 
> comes with ActiveMQ.  The proxied calls to ManagedRegionBroker will obtain 
> objects that are not registered with the MBean server and thus the web 
> console breaks with invalid JSP when executed, which ultimately is caused by 
> javax.management.InstanceNotFoundException.  The fix for this is to have the 
> web calls filter out lists that contain any non-MBeans. 



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

[jira] [Closed] (AMQ-5656) Support selective MBean creation

[Jeff Genender (JIRA)]

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

Jeff Genender closed AMQ-5656.
--
Resolution: Fixed

Will close this issue and track it in AMQ-6175

> Support selective MBean creation
> 
>
> Key: AMQ-5656
> URL: https://issues.apache.org/jira/browse/AMQ-5656
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, JMX
>Reporter: Martin Lichtin
>Assignee: Gary Tully
>Priority: Blocker
>  Labels: jmx, scalability
> Fix For: 5.12.0
>
>
> A continuation of 
> http://activemq.2283324.n4.nabble.com/How-to-disable-MBeans-creation-tp4692863p4692904.html
>  where I asked about a feature to suppress MBean creation for certain 
> objects, such as sessions, producers, consumers.
> Quoting Gary:
> {quote}
> There is a single code entry point 
> ([ManagementContext.registerMBean|https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/jmx/ManagementContext.java#L391])
>  for all MBean registration in the broker so gating that on a filter or 
> regexp match may be all that we need.
> {quote}



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

[jira] [Created] (AMQ-6175) ActiveMQ webconsole breaks when supressMBean is used

[Jeff Genender (JIRA)]

Jeff Genender created AMQ-6175:
--

 Summary: ActiveMQ webconsole breaks when supressMBean is used
 Key: AMQ-6175
 URL: https://issues.apache.org/jira/browse/AMQ-6175
 Project: ActiveMQ
  Issue Type: Bug
  Components: webconsole
Affects Versions: 5.13.1, 5.13.0, 5.12.1
Reporter: Jeff Genender
Priority: Blocker
 Fix For: 5.14.0, 5.13.2


AMQ-5656 which included the suppressMBean function broke the web console that 
comes with ActiveMQ.  The proxied calls to ManagedRegionBroker will obtain 
objects that are not registered with the MBean server and thus the web console 
breaks with invalid JSP when executed, which ultimately is caused by 
javax.management.InstanceNotFoundException.  The fix for this is to have the 
web calls filter out lists that contain any non-MBeans. 



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

[jira] [Commented] (AMQ-6147) AMQP: Update Proton-J to 0.12.0

[ASF subversion and git services (JIRA)]

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

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

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

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

Add a test that can reproduce an issue seen when emitFlowOnSend is
disabled on the proton transport to allow for further investigation.

> AMQP: Update Proton-J to 0.12.0
> ---
>
> Key: AMQ-6147
> URL: https://issues.apache.org/jira/browse/AMQ-6147
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: AMQP
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 5.14.0, 5.13.2
>
> Attachments: AMQ-6147.patch
>
>
> Update proton to latest version



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

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

[Jens Hadlich (JIRA)]

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

Jens Hadlich updated AMQ-6160:
--
Affects Version/s: 5.13.1

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

[jira] [Updated] (AMQ-5656) Support selective MBean creation

[Jeff Genender (JIRA)]

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

Jeff Genender updated AMQ-5656:
---
  Priority: Blocker  (was: Major)
Issue Type: Bug  (was: Improvement)

> Support selective MBean creation
> 
>
> Key: AMQ-5656
> URL: https://issues.apache.org/jira/browse/AMQ-5656
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker, JMX
>Reporter: Martin Lichtin
>Assignee: Gary Tully
>Priority: Blocker
>  Labels: jmx, scalability
> Fix For: 5.12.0
>
>
> A continuation of 
> http://activemq.2283324.n4.nabble.com/How-to-disable-MBeans-creation-tp4692863p4692904.html
>  where I asked about a feature to suppress MBean creation for certain 
> objects, such as sessions, producers, consumers.
> Quoting Gary:
> {quote}
> There is a single code entry point 
> ([ManagementContext.registerMBean|https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/jmx/ManagementContext.java#L391])
>  for all MBean registration in the broker so gating that on a filter or 
> regexp match may be all that we need.
> {quote}



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

[jira] [Reopened] (AMQ-5656) Support selective MBean creation

[Jeff Genender (JIRA)]

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

Jeff Genender reopened AMQ-5656:


This change breaks the webconsole and is not complete.  When selectively 
allowing JMX entires, the ManagementContext still sends back a list onjects 
even though those MBeans are not allowed to register.  Hence the webconsole 
blows up with:

org.apache.jasper.JasperException: An exception occurred processing JSP page 
/topics.jsp at line 55

52: 
53: 
54: 
55: 
56: ">
57: 
58: 

The mbeans need to be filtered on request for their lists for what is being 
supressed through the ManagedRegionBroker, or the webconsole will need 
filtering code everywhere for MBean calls that have no ability to be called.

> Support selective MBean creation
> 
>
> Key: AMQ-5656
> URL: https://issues.apache.org/jira/browse/AMQ-5656
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker, JMX
>Reporter: Martin Lichtin
>Assignee: Gary Tully
>  Labels: jmx, scalability
> Fix For: 5.12.0
>
>
> A continuation of 
> http://activemq.2283324.n4.nabble.com/How-to-disable-MBeans-creation-tp4692863p4692904.html
>  where I asked about a feature to suppress MBean creation for certain 
> objects, such as sessions, producers, consumers.
> Quoting Gary:
> {quote}
> There is a single code entry point 
> ([ManagementContext.registerMBean|https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/jmx/ManagementContext.java#L391])
>  for all MBean registration in the broker so gating that on a filter or 
> regexp match may be all that we need.
> {quote}



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

[jira] [Commented] (ARTEMIS-391) Connection Limit doesn't log when over the limit

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-391 log WARN on cxn limit


> Connection Limit doesn't log when over the limit
> 
>
> Key: ARTEMIS-391
> URL: https://issues.apache.org/jira/browse/ARTEMIS-391
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: clebert suconic
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>
> The current security limit doesn't log anything when going beyond the limit:
> there is a Log.DEBUG, and an empty exception that is not shown anywhere.
>else {
> if (ActiveMQServerLogger.LOGGER.isDebugEnabled()) {
>ActiveMQServerLogger.LOGGER.debug(new 
> StringBuilder().append("Connection limit of 
> ").append(connectionsAllowed).append(" reached. Refusing connection from 
> ").append(ctx.channel().remoteAddress()));
> }
> throw new Exception();
>  }
> The conneciton should be closed, and proper log should be printed. I think 
> this is a situation for log.warn as the admins will need to be aware of it.



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

[jira] [Commented] (AMQ-6155) Spurious InvalidDestinationException publishing to a temp queue from a new connection

[Kevin Bowman (JIRA)]

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

Kevin Bowman commented on AMQ-6155:
---

That's a fairly damning log sequence.  But because there appear to be two 
threads involved, the order in which things are logged are not necessarily the 
order in which they occurred.  The first two lines have the same exact 
timestamp but different threads, so the order in which they are logged is more 
up to chance than anything else.

Still, I think the fact that you're able to see the issue without the "unusual" 
application structure I was using is a good enough reason to reopen this.  
However, I suspect the answer will be the same; to just disable 
watchTopicAdvisories.  I'm currently recommending to everyone who uses temp 
queues with ActiveMQ to add 'jms.watchTopicAdvisories=false' to their URL.

> Spurious InvalidDestinationException publishing to a temp queue from a new 
> connection
> -
>
> Key: AMQ-6155
> URL: https://issues.apache.org/jira/browse/AMQ-6155
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.10.2, 5.13.0
> Environment: Windows, OS X
>Reporter: Kevin Bowman
> Attachments: AmqTempRaceConditionMinimalTest.java
>
>
> When a new connection is opened for the purpose of sending a message to a 
> temporary queue it sometimes fails with the following exception (stack trace 
> is from v5.13.0):
>  javax.jms.InvalidDestinationException: Cannot publish to a deleted 
> Destination: temp-queue://ID:Potomac.local-59943-1454448412194-1:1:96
>   at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1904)
>   at 
> org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:288)
>   at 
> org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:223)
>   at 
> org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:241)
> The actual problem appears to be in ActiveMQConnection.isDeleted().  Because 
> the connection being used to send to the temp queue is not the connection 
> under which the temp queue was created, it's dependent on AdvisoryConsumer to 
> populate the activeTempDestinations map before the send() call is made.  The 
> AdvisoryConsumer gets called in a separate thread, asynchronous with the main 
> thread, so this constitutes a race condition.  If the send() call is made 
> before AdvisoryConsumer can notify the new connection of all existing temp 
> queues then it will throw an InvalidDestinationException even though the temp 
> queue does actually exist.
> Calling setWatchTopicAdvisories(false) on the sending connection's factory 
> alleviates the problem and the program can run indefinitely with no errors.  
> Also, adding a delay before the MessageProducer.send() call can alleviate the 
> error somewhat, but with a small enough delay it will still happen eventually.
> I noticed this first in an environment I don't have full control over.  It 
> happened the first time, every time, for reasons I still don't quite 
> understand.  I have written a small test program that reproduces the error 
> outside of the original environment, but it runs in a loop and it takes a few 
> hundred iterations for it to occur.



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

[jira] [Commented] (AMQ-6174) LevelDB gets corrupted when Primary ActiveMQ server is shutdown while messages are queued to it

[Sunil Vishwanath (JIRA)]

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

Sunil Vishwanath commented on AMQ-6174:
---

Here is the Persistence Adapter configuration:

   

> LevelDB gets corrupted when Primary ActiveMQ server is shutdown while 
> messages are queued to it
> ---
>
> Key: AMQ-6174
> URL: https://issues.apache.org/jira/browse/AMQ-6174
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.13.0
> Environment: Virtual type detected as xen-para.
> Last rubix: Mon Feb  1 11:02:37 2016 release: 74867 version: 2.0.7
> Installed kernel: 2.6.18-308.0.0.0.1.el5xen x86_64
>Reporter: Sunil Vishwanath
>Priority: Critical
>
> Currently I am testing the following setup:
> ActiveMQ 5.13.0 with LevelDB (3 node cluster).
> Zookeeper 3.4.6 (3 node cluster).
> File system: NFSv3
> Started up all 3 Zookeeper nodes. (aamqzk1, aamqzk2 and aamqzk3)
> Started up all 5 ActiveMQ nodes. (aamql1, aamql2, aamql3, aamql4 and aamql5)
> I started aamql1 first and all others in order. aamql1 is the master and I am 
> able to see all the queue statistics for aamql1 via ActiveMQ Web Console.
> I am also watching all 5 AMQ's "application.log" file using "tail -f 
> application.log” command.
> The message producer starts sending messages (about 120,000 of them).  While 
> the messages are being queued and also being consumed, I stopped the master 
> instance (aamql1).  Now aamql2 becomes the master. About 10 seconds later 
> after all the slave aamq reports to the new master, aamql2 throws the 
> following exception and the instance dies.  This keeps repeating as it 
> failover to the next instance.
> 2016-02-17T15:43:48.358885-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-02-17 15:43:48,354 thread=LevelDB IOException handler. 
> category=org.apache.activemq.util.DefaultIOExceptionHandler Stopping 
> BrokerService[localhost] due to exception, java.io.EOFException: File 
> '/aamql/local/activemq/data/leveldb/38409848.log' offset: 477491777
> 2016-02-17T15:43:48.370881-08:00 aamql2.bus.jetqa1.syseng.tmcs 
> java.io.EOFException: File 
> '/aamql/local/activemq/data/leveldb/38409848.log' offset: 477491777
> 2016-02-17T15:43:48.371003-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.RecordLog$LogReader.read(RecordLog.scala:389)
> 2016-02-17T15:43:48.371082-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.RecordLog$$anonfun$read$2.apply(RecordLog.scala:654)
> 2016-02-17T15:43:48.371148-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.RecordLog$$anonfun$read$2.apply(RecordLog.scala:654)
> 2016-02-17T15:43:48.371219-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.RecordLog.get_reader(RecordLog.scala:644)
> 2016-02-17T15:43:48.371380-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.RecordLog.read(RecordLog.scala:654)
> 2016-02-17T15:43:48.371454-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.LevelDBClient.getMessage(LevelDBClient.scala:1335)
> 2016-02-17T15:43:48.371526-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1274)
> 2016-02-17T15:43:48.371604-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1271)
> 2016-02-17T15:43:48.371675-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1359)
> 2016-02-17T15:43:48.371746-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1358)
> 2016-02-17T15:43:48.371818-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.LevelDBClient$RichDB.check$4(LevelDBClient.scala:323)
> 2016-02-17T15:43:48.371888-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.LevelDBClient$RichDB.cursorRange(LevelDBClient.scala:325)
> 2016-02-17T15:43:48.371960-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply$mcV$sp(LevelDBClient.scala:1358)
> 2016-02-17T15:43:48.372034-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1358)
> 2016-02-17T15:43:48.372104-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
> 

[jira] [Commented] (ARTEMIS-391) Connection Limit doesn't log when over the limit

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-391 log WARN on cxn limit


> Connection Limit doesn't log when over the limit
> 
>
> Key: ARTEMIS-391
> URL: https://issues.apache.org/jira/browse/ARTEMIS-391
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: clebert suconic
>Assignee: Justin Bertram
> Fix For: 1.3.0
>
>
> The current security limit doesn't log anything when going beyond the limit:
> there is a Log.DEBUG, and an empty exception that is not shown anywhere.
>else {
> if (ActiveMQServerLogger.LOGGER.isDebugEnabled()) {
>ActiveMQServerLogger.LOGGER.debug(new 
> StringBuilder().append("Connection limit of 
> ").append(connectionsAllowed).append(" reached. Refusing connection from 
> ").append(ctx.channel().remoteAddress()));
> }
> throw new Exception();
>  }
> The conneciton should be closed, and proper log should be printed. I think 
> this is a situation for log.warn as the admins will need to be aware of it.



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

[jira] [Commented] (ARTEMIS-401) Support parameters on Acceptors

[ASF subversion and git services (JIRA)]

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

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

Commit 9ebc6786b6cb7e025f98ecf69b0173ee1ee9fa84 in activemq-artemis's branch 
refs/heads/refactor-openwire from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=9ebc678 ]

ARTEMIS-401 Refactoring Acceptors and ProtocolManager to support parameters

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


> Support parameters on Acceptors
> ---
>
> Key: ARTEMIS-401
> URL: https://issues.apache.org/jira/browse/ARTEMIS-401
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> I have a couple of places where I need to support parameters per Protocol 
> Manager inside the acceptor.
> that means that the protocol manager needs to be instantiated by acceptor,
> and the parameters from the URI need to be parsed through BeanUtils into the 
> ProtocolManager as well.



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

[jira] [Created] (AMQ-6174) LevelDB gets corrupted when Primary ActiveMQ server is shutdown while messages are queued to it

[Sunil Vishwanath (JIRA)]

Sunil Vishwanath created AMQ-6174:
-

 Summary: LevelDB gets corrupted when Primary ActiveMQ server is 
shutdown while messages are queued to it
 Key: AMQ-6174
 URL: https://issues.apache.org/jira/browse/AMQ-6174
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-leveldb-store
Affects Versions: 5.13.0
 Environment: Virtual type detected as xen-para.
Last rubix: Mon Feb  1 11:02:37 2016 release: 74867 version: 2.0.7
Installed kernel: 2.6.18-308.0.0.0.1.el5xen x86_64
Reporter: Sunil Vishwanath
Priority: Critical


Currently I am testing the following setup:

ActiveMQ 5.13.0 with LevelDB (3 node cluster).
Zookeeper 3.4.6 (3 node cluster).
File system: NFSv3

Started up all 3 Zookeeper nodes. (aamqzk1, aamqzk2 and aamqzk3)
Started up all 5 ActiveMQ nodes. (aamql1, aamql2, aamql3, aamql4 and aamql5)
I started aamql1 first and all others in order. aamql1 is the master and I am 
able to see all the queue statistics for aamql1 via ActiveMQ Web Console.

I am also watching all 5 AMQ's "application.log" file using "tail -f 
application.log” command.

The message producer starts sending messages (about 120,000 of them).  While 
the messages are being queued and also being consumed, I stopped the master 
instance (aamql1).  Now aamql2 becomes the master. About 10 seconds later after 
all the slave aamq reports to the new master, aamql2 throws the following 
exception and the instance dies.  This keeps repeating as it failover to the 
next instance.
2016-02-17T15:43:48.358885-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-02-17 15:43:48,354 thread=LevelDB IOException handler. 
category=org.apache.activemq.util.DefaultIOExceptionHandler Stopping 
BrokerService[localhost] due to exception, java.io.EOFException: File 
'/aamql/local/activemq/data/leveldb/38409848.log' offset: 477491777
2016-02-17T15:43:48.370881-08:00 aamql2.bus.jetqa1.syseng.tmcs 
java.io.EOFException: File 
'/aamql/local/activemq/data/leveldb/38409848.log' offset: 477491777
2016-02-17T15:43:48.371003-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.RecordLog$LogReader.read(RecordLog.scala:389)
2016-02-17T15:43:48.371082-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.RecordLog$$anonfun$read$2.apply(RecordLog.scala:654)
2016-02-17T15:43:48.371148-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.RecordLog$$anonfun$read$2.apply(RecordLog.scala:654)
2016-02-17T15:43:48.371219-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.RecordLog.get_reader(RecordLog.scala:644)
2016-02-17T15:43:48.371380-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.RecordLog.read(RecordLog.scala:654)
2016-02-17T15:43:48.371454-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient.getMessage(LevelDBClient.scala:1335)
2016-02-17T15:43:48.371526-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1274)
2016-02-17T15:43:48.371604-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1271)
2016-02-17T15:43:48.371675-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1359)
2016-02-17T15:43:48.371746-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1358)
2016-02-17T15:43:48.371818-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient$RichDB.check$4(LevelDBClient.scala:323)
2016-02-17T15:43:48.371888-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient$RichDB.cursorRange(LevelDBClient.scala:325)
2016-02-17T15:43:48.371960-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply$mcV$sp(LevelDBClient.scala:1358)
2016-02-17T15:43:48.372034-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1358)
2016-02-17T15:43:48.372104-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1358)
2016-02-17T15:43:48.372175-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient.usingIndex(LevelDBClient.scala:1038)
2016-02-17T15:43:48.372259-08:00 aamql2.bus.jetqa1.syseng.tmcs at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$might_fail_using_index$1.apply(LevelDBClient.scala:1044)
2016-02-17T15:43:48.372334-08:00 aamql2.bus.jetqa1.syseng.tmcs at 

[jira] [Commented] (ARTEMIS-401) Support parameters on Acceptors

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-401 Refactoring Acceptors and ProtocolManager to support parameters

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


> Support parameters on Acceptors
> ---
>
> Key: ARTEMIS-401
> URL: https://issues.apache.org/jira/browse/ARTEMIS-401
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> I have a couple of places where I need to support parameters per Protocol 
> Manager inside the acceptor.
> that means that the protocol manager needs to be instantiated by acceptor,
> and the parameters from the URI need to be parsed through BeanUtils into the 
> ProtocolManager as well.



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

[jira] [Commented] (ARTEMIS-401) Support parameters on Acceptors

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-401 Refactoring Acceptors and ProtocolManager to support parameters

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


> Support parameters on Acceptors
> ---
>
> Key: ARTEMIS-401
> URL: https://issues.apache.org/jira/browse/ARTEMIS-401
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 1.3.0
>
>
> I have a couple of places where I need to support parameters per Protocol 
> Manager inside the acceptor.
> that means that the protocol manager needs to be instantiated by acceptor,
> and the parameters from the URI need to be parsed through BeanUtils into the 
> ProtocolManager as well.



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

[jira] [Commented] (ARTEMIS-403) [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest#testTransactional fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-403:


Github user asfgit closed the pull request at:

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


> [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest#testTransactional 
> fails
> ---
>
> Key: ARTEMIS-403
> URL: https://issues.apache.org/jira/browse/ARTEMIS-403
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> Test didn't complete successful, thread still running
> java.lang.AssertionError: Test didn't complete successful, thread still 
> running
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.runTest(AsynchronousFailoverTest.java:188)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.testTransactional(AsynchronousFailoverTest.java:77)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   at java.lang.reflect.Method.invoke(Method.java:507)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

[jira] [Commented] (ARTEMIS-403) [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest#testTransactional fails

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-403 - [Artemis Testsuite] 
AlmostLargeAsynchronousFailoverTest#testTransactional fails


> [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest#testTransactional 
> fails
> ---
>
> Key: ARTEMIS-403
> URL: https://issues.apache.org/jira/browse/ARTEMIS-403
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> Test didn't complete successful, thread still running
> java.lang.AssertionError: Test didn't complete successful, thread still 
> running
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.runTest(AsynchronousFailoverTest.java:188)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.testTransactional(AsynchronousFailoverTest.java:77)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   at java.lang.reflect.Method.invoke(Method.java:507)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

[jira] [Created] (AMQ-6173) ActiveMQ with replicated LevelDB using NFSv4 corrupts on failover back to the initial instance

[Sunil Vishwanath (JIRA)]

Sunil Vishwanath created AMQ-6173:
-

 Summary: ActiveMQ with replicated LevelDB using NFSv4 corrupts on 
failover back to the initial instance
 Key: AMQ-6173
 URL: https://issues.apache.org/jira/browse/AMQ-6173
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-leveldb-store
Affects Versions: 5.13.0
 Environment: Linux: Installed kernel: 2.6.18-308.0.0.0.1.el5xen x86_64 
with NFSv4

Reporter: Sunil Vishwanath


I have setup the following to test with NFSv4 file system:

ActiveMQ 5.13.0 with LevelDB (3 node cluster).
Zookeeper 3.4.6 (3 node cluster).
NFSv4 file system local to each server. (not shared)

Started up all 3 Zookeeper nodes.
Started up all 3 ActiveMQ nodes.
As I started aamq2 first, it became the master. I am able to see all the queue 
statistics via ActiveMQ Web Console.

I am watching all 3 AMQ "application.log" file using "tail -f application.log” 
command.

Now I stopped the aamq2 instance.  Aamq3 is now promoted to master as per the 
messages in the aamq3’s application.log
I restarted aamq2 and its levelDB caught up.
Now I stopped the aamq3 instance.  Aamq1 is now promoted to master as per the 
message in the application log.
I restarted aamq3 and its levelDB caught up.
Now I stopped the aamq1 instance.  Aamq2 is now promoted to master as per the 
messages below and it encounters errors:

2016-01-31T16:39:20.097313-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-01-31 16:39:20,097 thread=hawtdispatch-DEFAULT-3 
category=org.apache.activemq.leveldb.replicated.SlaveLevelDBStore Attaching... 
Downloaded 66.47/258.72 kb and 5/6 files
2016-01-31T16:39:20.103037-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-01-31 16:39:20,102 thread=hawtdispatch-DEFAULT-3 
category=org.apache.activemq.leveldb.replicated.SlaveLevelDBStore Attaching... 
Downloaded 258.72/258.72 kb and 6/6 files
2016-01-31T16:39:20.104353-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-01-31 16:39:20,104 thread=hawtdispatch-DEFAULT-3 
category=org.apache.activemq.leveldb.replicated.SlaveLevelDBStore Attached
2016-01-31T16:46:45.021281-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-01-31 16:46:45,020 thread=main-EventThread 
category=org.apache.activemq.leveldb.replicated.MasterElector Not enough 
cluster members have reported their update positions yet.
2016-01-31T16:46:45.115987-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-01-31 16:46:45,115 thread=main-EventThread 
category=org.apache.activemq.leveldb.replicated.MasterElector Not enough 
cluster members have reported their update positions yet.
2016-01-31T16:46:45.188385-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-01-31 16:46:45,187 thread=ActiveMQ BrokerService[localhost] 
Task-4 category=org.apache.activemq.leveldb.replicated.MasterElector Slave 
stopped
2016-01-31T16:46:45.189199-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-01-31 16:46:45,188 thread=ActiveMQ BrokerService[localhost] 
Task-4 category=org.apache.activemq.leveldb.replicated.MasterElector Not enough 
cluster members have reported their update positions yet.
2016-01-31T16:46:45.214426-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-01-31 16:46:45,214 thread=main-EventThread 
category=org.apache.activemq.leveldb.replicated.MasterElector Promoted to master
2016-01-31T16:46:45.256560-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-01-31 16:46:45,255 thread=ActiveMQ BrokerService[localhost] 
Task-5 category=org.apache.activemq.leveldb.LevelDBClient Using the pure java 
LevelDB implementation.
2016-01-31T16:46:45.729608-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
datetime=2016-01-31 16:46:45,729 thread=LevelDB IOException handler. 
category=org.apache.activemq.broker.BrokerService No IOExceptionHandler 
registered, ignoring IO exception
2016-01-31T16:46:45.735717-08:00 aamql2.bus.jetqa1.syseng.tmcs 
java.io.IOException: java.lang.IllegalArgumentException: File is not a table 
(bad magic number)
2016-01-31T16:46:45.735717-08:00 aamql2.bus.jetqa1.syseng.tmcsat 
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
2016-01-31T16:46:45.735752-08:00 aamql2.bus.jetqa1.syseng.tmcsat 
org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:552)
2016-01-31T16:46:45.735752-08:00 aamql2.bus.jetqa1.syseng.tmcsat 
org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1044)
2016-01-31T16:46:45.735858-08:00 aamql2.bus.jetqa1.syseng.tmcsat 
org.apache.activemq.leveldb.LevelDBClient.listCollections(LevelDBClient.scala:1167)
2016-01-31T16:46:45.735858-08:00 aamql2.bus.jetqa1.syseng.tmcsat 
org.apache.activemq.leveldb.DBManager$$anonfun$3.apply(DBManager.scala:837)
2016-01-31T16:46:45.735877-08:00 aamql2.bus.jetqa1.syseng.tmcsat 

[jira] [Commented] (AMQ-6173) ActiveMQ with replicated LevelDB using NFSv4 corrupts on failover back to the initial instance

[Sunil Vishwanath (JIRA)]

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

Sunil Vishwanath commented on AMQ-6173:
---

I changed the file system to NFSv3 and the issue went away.  It looks like it 
is not doing well with NFSv4.

> ActiveMQ with replicated LevelDB using NFSv4 corrupts on failover back to the 
> initial instance
> --
>
> Key: AMQ-6173
> URL: https://issues.apache.org/jira/browse/AMQ-6173
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.13.0
> Environment: Linux: Installed kernel: 2.6.18-308.0.0.0.1.el5xen 
> x86_64 with NFSv4
>Reporter: Sunil Vishwanath
>
> I have setup the following to test with NFSv4 file system:
> ActiveMQ 5.13.0 with LevelDB (3 node cluster).
> Zookeeper 3.4.6 (3 node cluster).
> NFSv4 file system local to each server. (not shared)
> Started up all 3 Zookeeper nodes.
> Started up all 3 ActiveMQ nodes.
> As I started aamq2 first, it became the master. I am able to see all the 
> queue statistics via ActiveMQ Web Console.
> I am watching all 3 AMQ "application.log" file using "tail -f 
> application.log” command.
> Now I stopped the aamq2 instance.  Aamq3 is now promoted to master as per the 
> messages in the aamq3’s application.log
> I restarted aamq2 and its levelDB caught up.
> Now I stopped the aamq3 instance.  Aamq1 is now promoted to master as per the 
> message in the application log.
> I restarted aamq3 and its levelDB caught up.
> Now I stopped the aamq1 instance.  Aamq2 is now promoted to master as per the 
> messages below and it encounters errors:
> 2016-01-31T16:39:20.097313-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-01-31 16:39:20,097 thread=hawtdispatch-DEFAULT-3 
> category=org.apache.activemq.leveldb.replicated.SlaveLevelDBStore 
> Attaching... Downloaded 66.47/258.72 kb and 5/6 files
> 2016-01-31T16:39:20.103037-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-01-31 16:39:20,102 thread=hawtdispatch-DEFAULT-3 
> category=org.apache.activemq.leveldb.replicated.SlaveLevelDBStore 
> Attaching... Downloaded 258.72/258.72 kb and 6/6 files
> 2016-01-31T16:39:20.104353-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-01-31 16:39:20,104 thread=hawtdispatch-DEFAULT-3 
> category=org.apache.activemq.leveldb.replicated.SlaveLevelDBStore Attached
> 2016-01-31T16:46:45.021281-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-01-31 16:46:45,020 thread=main-EventThread 
> category=org.apache.activemq.leveldb.replicated.MasterElector Not enough 
> cluster members have reported their update positions yet.
> 2016-01-31T16:46:45.115987-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-01-31 16:46:45,115 thread=main-EventThread 
> category=org.apache.activemq.leveldb.replicated.MasterElector Not enough 
> cluster members have reported their update positions yet.
> 2016-01-31T16:46:45.188385-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-01-31 16:46:45,187 thread=ActiveMQ BrokerService[localhost] 
> Task-4 category=org.apache.activemq.leveldb.replicated.MasterElector Slave 
> stopped
> 2016-01-31T16:46:45.189199-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-01-31 16:46:45,188 thread=ActiveMQ BrokerService[localhost] 
> Task-4 category=org.apache.activemq.leveldb.replicated.MasterElector Not 
> enough cluster members have reported their update positions yet.
> 2016-01-31T16:46:45.214426-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-01-31 16:46:45,214 thread=main-EventThread 
> category=org.apache.activemq.leveldb.replicated.MasterElector Promoted to 
> master
> 2016-01-31T16:46:45.256560-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-01-31 16:46:45,255 thread=ActiveMQ BrokerService[localhost] 
> Task-5 category=org.apache.activemq.leveldb.LevelDBClient Using the pure java 
> LevelDB implementation.
> 2016-01-31T16:46:45.729608-08:00 aamql2.bus.jetqa1.syseng.tmcs severity=INFO 
> datetime=2016-01-31 16:46:45,729 thread=LevelDB IOException handler. 
> category=org.apache.activemq.broker.BrokerService No IOExceptionHandler 
> registered, ignoring IO exception
> 2016-01-31T16:46:45.735717-08:00 aamql2.bus.jetqa1.syseng.tmcs 
> java.io.IOException: java.lang.IllegalArgumentException: File is not a table 
> (bad magic number)
> 2016-01-31T16:46:45.735717-08:00 aamql2.bus.jetqa1.syseng.tmcsat 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:39)
> 2016-01-31T16:46:45.735752-08:00 aamql2.bus.jetqa1.syseng.tmcsat 
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:552)
> 2016-01-31T16:46:45.735752-08:00 

[jira] [Commented] (ARTEMIS-403) [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest#testTransactional fails

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-403:


GitHub user dudaerich opened a pull request:

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

ARTEMIS-403 - [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest…

…#testTransactional fails

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

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

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

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


commit 81d57361e84b6a68e11bc910004e6db3cefa244f
Author: Erich Duda 
Date:   2016-02-18T13:45:24Z

ARTEMIS-403 - [Artemis Testsuite] 
AlmostLargeAsynchronousFailoverTest#testTransactional fails




> [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest#testTransactional 
> fails
> ---
>
> Key: ARTEMIS-403
> URL: https://issues.apache.org/jira/browse/ARTEMIS-403
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Erich Duda
>
> {code}
> Test didn't complete successful, thread still running
> java.lang.AssertionError: Test didn't complete successful, thread still 
> running
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.runTest(AsynchronousFailoverTest.java:188)
>   at 
> org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.testTransactional(AsynchronousFailoverTest.java:77)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   at java.lang.reflect.Method.invoke(Method.java:507)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}



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

[jira] [Created] (ARTEMIS-403) [Artemis Testsuite] AlmostLargeAsynchronousFailoverTest#testTransactional fails

[Erich Duda (JIRA)]

Erich Duda created ARTEMIS-403:
--

 Summary: [Artemis Testsuite] 
AlmostLargeAsynchronousFailoverTest#testTransactional fails
 Key: ARTEMIS-403
 URL: https://issues.apache.org/jira/browse/ARTEMIS-403
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Erich Duda


{code}
Test didn't complete successful, thread still running
java.lang.AssertionError: Test didn't complete successful, thread still running
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.runTest(AsynchronousFailoverTest.java:188)
at 
org.apache.activemq.artemis.tests.integration.cluster.failover.AsynchronousFailoverTest.testTransactional(AsynchronousFailoverTest.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}



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

[jira] [Created] (ARTEMIS-402) Retroactive Consumer

[Howard Gao (JIRA)]

Howard Gao created ARTEMIS-402:
--

 Summary: Retroactive Consumer
 Key: ARTEMIS-402
 URL: https://issues.apache.org/jira/browse/ARTEMIS-402
 Project: ActiveMQ Artemis
  Issue Type: Sub-task
  Components: OpenWire
Affects Versions: 1.1.0
Reporter: Howard Gao
Priority: Minor
 Fix For: 1.3.0


ActiveMQ5.x has a feature called "Retroactive" consumers.
http://activemq.apache.org/retroactive-consumer.html

A retroactive consumer is a kind of jms topic subscriber which can receive 
messages sent to the topic before the consumer is created. Normally if a 
message is sent to a topic without a subscription, it will be discarded. This 
kind of consumer however changes this as if it can go "back in time".

Test ref:

org.apache.activemq.broker.BrokerTest#testTopicRetroactiveConsumerSeeMessagesBeforeCreation()



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