[jira] [Commented] (AMQ-5284) InvalidClassException when migrating LevelDB store from 5.9.1 to 5.10.0
[
https://issues.apache.org/jira/browse/AMQ-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14502955#comment-14502955
]
Christian Posta commented on AMQ-5284:
--
[~vhle01] not sure if there's a good way to make this backward compatible at
this point... might have to just drain existing queues in one version of the
broker, and migrate to the newer versions. Does something like that work for
you?
> InvalidClassException when migrating LevelDB store from 5.9.1 to 5.10.0
> ---
>
> Key: AMQ-5284
> URL: https://issues.apache.org/jira/browse/AMQ-5284
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.10.0
> Environment: CentOS 6.5 and Windows 7 x64
>Reporter: Vu Le
>
> This is my first attempt to create an issue for ActiveMQ, so please bear with
> me...
> I first created an instance of ActiveMQ 5.9.1 configured with a LevelDB
> store. I started the broker, then sent in 100,000 persistent test messages to
> a queue, then shut down the broker.
> I then upgraded to ActiveMQ 5.10.0. I started up the broker hoping to reuse
> the LevelDB datastore, and I received the error below.
> It looks like the serialized objects within the 5.9.1 are not compatible with
> the 5.10.0 objects. It occurs with other classes as well (not just the
> LongCounter class listed in the error).
> {code}
> 2014-07-22 21:47:49,700 | INFO | No IOExceptionHandler registered, ignoring
> IO exception | org.apache.activemq.broker.BrokerService | LevelDB IOException
> handler.
> java.io.InvalidClassException: org.apache.activemq.leveldb.util.LongCounter;
> local class incompatible: stream classdesc serialVersionUID =
> -2892799184011566766, local class serialVersionUID = -1093574112128208819
> at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:617
> [:1.7.0_60]
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1622)[:1.7.0_60]
> at
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)[:1.7.0_60]
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)[:1.7.0_60]
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)[:1.7.0_60]
> at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)[:1.7.0_60]
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$loadMap$1$1.apply(LevelDBClient.scala:924)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$loadMap$1$1.apply(LevelDBClient.scala:919)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at scala.Option.foreach(Option.scala:245)[scala-library-2.11.0.jar:]
> at
> org.apache.activemq.leveldb.LevelDBClient.loadMap$1(LevelDBClient.scala:919)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.leveldb.LevelDBClient.org$apache$activemq$leveldb$LevelDBClient$$loadCounters(LevelDBClient.scala:950)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$replay_init$2.apply$mcV$sp(LevelDBClient.scala:684)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$replay_init$2.apply(LevelDBClient.scala:657)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.leveldb.LevelDBClient$$anonfun$replay_init$2.apply(LevelDBClient.scala:657)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:549)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.leveldb.LevelDBClient.replay_init(LevelDBClient.scala:657)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.leveldb.LevelDBClient.start(LevelDBClient.scala:558)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.leveldb.DBManager.start(DBManager.scala:648)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.leveldb.LevelDBStore.doStart(LevelDBStore.scala:235)[activemq-leveldb-store-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)[activemq-client-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerService.java:640)[activemq-broker-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.broker.BrokerService.startPersistenceAdapter(BrokerService.java:629)[activemq-broker-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.broker.BrokerService.start(BrokerService.java:594)[activemq-broker-5.10.0.jar:5.10.0]
> at
> org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBroke
[jira] [Commented] (AMQ-5153) LevelDB does not store subscribedDestination for durable subscriptions
[ https://issues.apache.org/jira/browse/AMQ-5153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14502946#comment-14502946 ] Christian Posta commented on AMQ-5153: -- [~badavis] can you try on a more recent version? I've committed a unit test here: https://github.com/apache/activemq/commit/01f56d0ca255852bf9c12b889abd8d1297a2b5a9 that shows this works correctly. If you can alter that unit test to show failure, then we can take a closer look. let us know! > LevelDB does not store subscribedDestination for durable subscriptions > -- > > Key: AMQ-5153 > URL: https://issues.apache.org/jira/browse/AMQ-5153 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.1 >Reporter: Brian Davis > > LevelDB store does not save the subscribedDestination of the SubscriptionInfo > for a durable subscription. This is important because when a restart happens > you have no clue if this durable subscription goes with the topic or to a > different topic (because of wildcarding). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5672) Add an option to virtual topic selector cache to enforce only a single selector at a given time
[ https://issues.apache.org/jira/browse/AMQ-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482191#comment-14482191 ] Christian Posta commented on AMQ-5672: -- This commit adds a few new features to the selector caching that was previously available: #1 JMX introspection -- you can view and manage the selectors currently applied to specific destinations/Queues. There are three JMX operations that can be applied: * selectorsForDestination(destinationName) * deleteSelectorForDestination(destinationName, selector) * deleteAllSelectorsForDestination(destinationName) Just note, when passing in values to these operations, you need to prefix the destination/queue name with "queue://" + queueName #2 Enforce single selector for a destination -- the assumption is that only a single valid selector expression can be enabled at any one time, and the last consumer to attach with an expression overrides any existing expressions. The one exception is that a consumer with NO selector does not count against the "single selector" enforcement.. that is, you can have a single selector and consumers with no selectors attached at the same time. To enable this feature, you add the "singleSelectorsPerDestination=true" attribute to the plugin element. When consumers that had a selector disconnect from the broker, the broker will cache the selector as expected. If a consumer that has NO selector (that is, it matches everything) disconnects when this singleSelectorsPerDestination=true, then the queue will NO LONGER match against everything. #3 Exclusion of wildcard selectors -- any selectors that match on % or _ can be excluded. To enable this feature, you add the "ignoreWildcardSelectors=true" attribute to the plugin element. > Add an option to virtual topic selector cache to enforce only a single > selector at a given time > --- > > Key: AMQ-5672 > URL: https://issues.apache.org/jira/browse/AMQ-5672 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.11.1 >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.12.0 > > > At the moment, the virtualTopicSelectorCache is pretty bare bones. we should > allow configuration of the persist period, the file location, and some > operational insight via JMX. We should also allow to configure the cache to a > single number of selectors to enforce automatic clean-up for non-used > selectors (and avoid large pileups of messages) and to ensure consistent > usage across the queues that are used in the virtual topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-5672) Add an option to virtual topic selector cache to enforce only a single selector at a given time
[ https://issues.apache.org/jira/browse/AMQ-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta resolved AMQ-5672. -- Resolution: Fixed Fixed with this commit https://github.com/apache/activemq/commit/61da1faa4c4e49191b373049ee36434aaad58897 > Add an option to virtual topic selector cache to enforce only a single > selector at a given time > --- > > Key: AMQ-5672 > URL: https://issues.apache.org/jira/browse/AMQ-5672 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.11.1 >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.12.0 > > > At the moment, the virtualTopicSelectorCache is pretty bare bones. we should > allow configuration of the persist period, the file location, and some > operational insight via JMX. We should also allow to configure the cache to a > single number of selectors to enforce automatic clean-up for non-used > selectors (and avoid large pileups of messages) and to ensure consistent > usage across the queues that are used in the virtual topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5672) Add an option to virtual topic selector cache to enforce only a single selector at a given time
[ https://issues.apache.org/jira/browse/AMQ-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta updated AMQ-5672: - Fix Version/s: 5.12.0 > Add an option to virtual topic selector cache to enforce only a single > selector at a given time > --- > > Key: AMQ-5672 > URL: https://issues.apache.org/jira/browse/AMQ-5672 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.11.1 >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.12.0 > > > At the moment, the virtualTopicSelectorCache is pretty bare bones. we should > allow configuration of the persist period, the file location, and some > operational insight via JMX. We should also allow to configure the cache to a > single number of selectors to enforce automatic clean-up for non-used > selectors (and avoid large pileups of messages) and to ensure consistent > usage across the queues that are used in the virtual topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMQ-5672) Add an option to virtual topic selector cache to enforce only a single selector at a given time
[ https://issues.apache.org/jira/browse/AMQ-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta reassigned AMQ-5672: Assignee: Christian Posta > Add an option to virtual topic selector cache to enforce only a single > selector at a given time > --- > > Key: AMQ-5672 > URL: https://issues.apache.org/jira/browse/AMQ-5672 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.11.1 >Reporter: Christian Posta >Assignee: Christian Posta > > At the moment, the virtualTopicSelectorCache is pretty bare bones. we should > allow configuration of the persist period, the file location, and some > operational insight via JMX. We should also allow to configure the cache to a > single number of selectors to enforce automatic clean-up for non-used > selectors (and avoid large pileups of messages) and to ensure consistent > usage across the queues that are used in the virtual topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
[
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14390759#comment-14390759
]
Christian Posta commented on AMQ-5082:
--
Will be in 5.12 when released. Do you needed it back ported to a 5.11.x?
Or can test with the nightly builds here:
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.12-SNAPSHOT/
> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Fix For: 5.12.0
>
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz,
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure,
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB
> persistence adapter.
> {code}
>
>directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zookeep0:2181"
> zkPath="/activemq/leveldb-stores"/>
>
> {code}
> After about a day or so of sitting idle there are cascading failures and the
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit
> 2360fb859694bacac1e48092e53a56b388e1d2f0). I am going to attach logs from
> the three mq nodes and the zookeeper logs that reflect the time where the
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an
> issue.
> If you need more data it should be pretty easy to get whatever is needed
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a
> separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
[
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14390648#comment-14390648
]
Christian Posta commented on AMQ-5082:
--
Thanks Jim for digging into this. I've committed your PR. Running tests on my
side I've not gotten it to fail. Hopefully jenkins thinks the same thing :)
Thanks again for your contributions!! Look forward to others :)
> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Fix For: 5.12.0
>
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz,
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure,
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB
> persistence adapter.
> {code}
>
>directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zookeep0:2181"
> zkPath="/activemq/leveldb-stores"/>
>
> {code}
> After about a day or so of sitting idle there are cascading failures and the
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit
> 2360fb859694bacac1e48092e53a56b388e1d2f0). I am going to attach logs from
> the three mq nodes and the zookeeper logs that reflect the time where the
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an
> issue.
> If you need more data it should be pretty easy to get whatever is needed
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a
> separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
[
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14387955#comment-14387955
]
Christian Posta commented on AMQ-5082:
--
The very last assert it was failing. I've run it about 10 times in a row and
seems to pass now. Not sure what was up earlier.
> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Fix For: 5.12.0
>
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz,
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure,
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB
> persistence adapter.
> {code}
>
>directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zookeep0:2181"
> zkPath="/activemq/leveldb-stores"/>
>
> {code}
> After about a day or so of sitting idle there are cascading failures and the
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit
> 2360fb859694bacac1e48092e53a56b388e1d2f0). I am going to attach logs from
> the three mq nodes and the zookeeper logs that reflect the time where the
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an
> issue.
> If you need more data it should be pretty easy to get whatever is needed
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a
> separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
[
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14387659#comment-14387659
]
Christian Posta commented on AMQ-5082:
--
After running a handful more times, it seems to pass ~90% of the time. Is that
the same behavior for you? The patch looks fine to me (e.g., rebuilding the ZK
tracking tree on reconnect). I'll keep running to see if it's my env or if
there is a timing issue with the test.
I've applied the patch (w/o using the pull request which had some other merge
noise) as a clean commit here:
https://github.com/apache/activemq/commit/a39e51e0519852332f7779443c3db09b6e691d49
[~scottmf] can you test on the latest master to verify things look good?
> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Fix For: 5.12.0
>
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz,
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure,
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB
> persistence adapter.
> {code}
>
>directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zookeep0:2181"
> zkPath="/activemq/leveldb-stores"/>
>
> {code}
> After about a day or so of sitting idle there are cascading failures and the
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit
> 2360fb859694bacac1e48092e53a56b388e1d2f0). I am going to attach logs from
> the three mq nodes and the zookeeper logs that reflect the time where the
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an
> issue.
> If you need more data it should be pretty easy to get whatever is needed
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a
> separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
[
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Posta updated AMQ-5082:
-
Fix Version/s: 5.12.0
> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Fix For: 5.12.0
>
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz,
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure,
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB
> persistence adapter.
> {code}
>
>directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zookeep0:2181"
> zkPath="/activemq/leveldb-stores"/>
>
> {code}
> After about a day or so of sitting idle there are cascading failures and the
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit
> 2360fb859694bacac1e48092e53a56b388e1d2f0). I am going to attach logs from
> the three mq nodes and the zookeeper logs that reflect the time where the
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an
> issue.
> If you need more data it should be pretty easy to get whatever is needed
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a
> separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
[
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14387628#comment-14387628
]
Christian Posta commented on AMQ-5082:
--
Hey [~jim.robin...@gmail.com] i'm trying to apply your patch but the unit tests
you have doesn't pass w/ or w/o the patch. Can you take a look with the patch
applied to master? https://github.com/apache/activemq/pull/74.diff
> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz,
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure,
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB
> persistence adapter.
> {code}
>
>directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zookeep0:2181"
> zkPath="/activemq/leveldb-stores"/>
>
> {code}
> After about a day or so of sitting idle there are cascading failures and the
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit
> 2360fb859694bacac1e48092e53a56b388e1d2f0). I am going to attach logs from
> the three mq nodes and the zookeeper logs that reflect the time where the
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an
> issue.
> If you need more data it should be pretty easy to get whatever is needed
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a
> separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
[
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14385634#comment-14385634
]
Christian Posta commented on AMQ-5082:
--
Awesome, thanks [~jim.robin...@gmail.com] for the patch. I'll take a look
tomorrow or Monday and get this in.
> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Priority: Critical
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz,
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure,
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB
> persistence adapter.
> {code}
>
>directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zookeep0:2181"
> zkPath="/activemq/leveldb-stores"/>
>
> {code}
> After about a day or so of sitting idle there are cascading failures and the
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit
> 2360fb859694bacac1e48092e53a56b388e1d2f0). I am going to attach logs from
> the three mq nodes and the zookeeper logs that reflect the time where the
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an
> issue.
> If you need more data it should be pretty easy to get whatever is needed
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a
> separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (AMQ-5082) ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
[
https://issues.apache.org/jira/browse/AMQ-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Posta reassigned AMQ-5082:
Assignee: Christian Posta
> ActiveMQ replicatedLevelDB cluster breaks, all nodes stop listening
> ---
>
> Key: AMQ-5082
> URL: https://issues.apache.org/jira/browse/AMQ-5082
> Project: ActiveMQ
> Issue Type: Bug
> Components: activemq-leveldb-store
>Affects Versions: 5.9.0, 5.10.0
>Reporter: Scott Feldstein
>Assignee: Christian Posta
>Priority: Critical
> Attachments: 03-07.tgz, amq_5082_threads.tar.gz,
> mq-node1-cluster.failure, mq-node2-cluster.failure, mq-node3-cluster.failure,
> zookeeper.out-cluster.failure
>
>
> I have a 3 node amq cluster and one zookeeper node using a replicatedLevelDB
> persistence adapter.
> {code}
>
>directory="${activemq.data}/leveldb"
> replicas="3"
> bind="tcp://0.0.0.0:0"
> zkAddress="zookeep0:2181"
> zkPath="/activemq/leveldb-stores"/>
>
> {code}
> After about a day or so of sitting idle there are cascading failures and the
> cluster completely stops listening all together.
> I can reproduce this consistently on 5.9 and the latest 5.10 (commit
> 2360fb859694bacac1e48092e53a56b388e1d2f0). I am going to attach logs from
> the three mq nodes and the zookeeper logs that reflect the time where the
> cluster starts having issues.
> The cluster stops listening Mar 4, 2014 4:56:50 AM (within 5 seconds).
> The OSs are all centos 5.9 on one esx server, so I doubt networking is an
> issue.
> If you need more data it should be pretty easy to get whatever is needed
> since it is consistently reproducible.
> This bug may be related to AMQ-5026, but looks different enough to file a
> separate issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-5689) Queue dispatching hangs when there are redelivered messages that don't match current consumer's selectors
[ https://issues.apache.org/jira/browse/AMQ-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta resolved AMQ-5689. -- Resolution: Fixed Fixed with this commit: https://github.com/apache/activemq/commit/efc9a8d5782143b8c1e86750d34ce74af5a2940a > Queue dispatching hangs when there are redelivered messages that don't match > current consumer's selectors > - > > Key: AMQ-5689 > URL: https://issues.apache.org/jira/browse/AMQ-5689 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.10.2, 5.11.1 >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.12.0 > > > If a queue has messages that it needs to redeliver, it will stall when the > only current consumers have selectors that don't match because dispatching > only takes into account redeliveries until they're empty.. but there may be > other messages that don't match that need to be delivered. > Have patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5689) Queue dispatching hangs when there are redelivered messages that don't match current consumer's selectors
[ https://issues.apache.org/jira/browse/AMQ-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382878#comment-14382878 ] Christian Posta commented on AMQ-5689: -- current patch here https://github.com/christian-posta/activemq/tree/AMQ-5689-dispatch-selector-redelivery running all unit tests to make sure I didn't break too many things :) > Queue dispatching hangs when there are redelivered messages that don't match > current consumer's selectors > - > > Key: AMQ-5689 > URL: https://issues.apache.org/jira/browse/AMQ-5689 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.10.2, 5.11.1 >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.12.0 > > > If a queue has messages that it needs to redeliver, it will stall when the > only current consumers have selectors that don't match because dispatching > only takes into account redeliveries until they're empty.. but there may be > other messages that don't match that need to be delivered. > Have patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQ-5679) Wildcard Selector is Cached Against Virtual Topic when Browsing the Topic
[ https://issues.apache.org/jira/browse/AMQ-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta closed AMQ-5679. Resolution: Duplicate Duplicated by https://issues.apache.org/jira/browse/AMQ-5672 > Wildcard Selector is Cached Against Virtual Topic when Browsing the Topic > - > > Key: AMQ-5679 > URL: https://issues.apache.org/jira/browse/AMQ-5679 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.1 > Environment: Any >Reporter: Justin Reock >Priority: Minor > > The fix for AMQ-4899 seems to have created an undesired side effect. Because > all consumer selectors issued against a Virtual Topic are now cached, this > means that even the Wildcard selector used when browsing the Virtual Topic is > cached as well. This effectively nullifies the selectorAware attribute of > the Virtual Topic, as once the browse happens, every message will be retained > in the Topic, regardless of whether they match a desired consumer selector. > To validate, create a selectorAware Virtual Topic and attach a consumer with > a selector active on the Topic. Produce some messages which don't match the > selector, and note that they are properly discarded. Then, browse the > Virtual Topic using the web console, and produce some messages that don't > match the selector again. They will be retained on the Virtual Topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5679) Wildcard Selector is Cached Against Virtual Topic when Browsing the Topic
[ https://issues.apache.org/jira/browse/AMQ-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382861#comment-14382861 ] Christian Posta commented on AMQ-5679: -- K so i'll close this one as duplicate. there was another issue that needed to get out of the way first (see https://issues.apache.org/jira/browse/AMQ-5672 and https://issues.apache.org/jira/browse/AMQ-5689) I'll also add the exclusion settings when i commit for https://issues.apache.org/jira/browse/AMQ-5672. Thanks! > Wildcard Selector is Cached Against Virtual Topic when Browsing the Topic > - > > Key: AMQ-5679 > URL: https://issues.apache.org/jira/browse/AMQ-5679 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.1 > Environment: Any >Reporter: Justin Reock >Priority: Minor > > The fix for AMQ-4899 seems to have created an undesired side effect. Because > all consumer selectors issued against a Virtual Topic are now cached, this > means that even the Wildcard selector used when browsing the Virtual Topic is > cached as well. This effectively nullifies the selectorAware attribute of > the Virtual Topic, as once the browse happens, every message will be retained > in the Topic, regardless of whether they match a desired consumer selector. > To validate, create a selectorAware Virtual Topic and attach a consumer with > a selector active on the Topic. Produce some messages which don't match the > selector, and note that they are properly discarded. Then, browse the > Virtual Topic using the web console, and produce some messages that don't > match the selector again. They will be retained on the Virtual Topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5689) Queue dispatching hangs when there are redelivered messages that don't match current consumer's selectors
Christian Posta created AMQ-5689: Summary: Queue dispatching hangs when there are redelivered messages that don't match current consumer's selectors Key: AMQ-5689 URL: https://issues.apache.org/jira/browse/AMQ-5689 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.11.1, 5.10.2 Reporter: Christian Posta Assignee: Christian Posta Fix For: 5.12.0 If a queue has messages that it needs to redeliver, it will stall when the only current consumers have selectors that don't match because dispatching only takes into account redeliveries until they're empty.. but there may be other messages that don't match that need to be delivered. Have patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5679) Wildcard Selector is Cached Against Virtual Topic when Browsing the Topic
[ https://issues.apache.org/jira/browse/AMQ-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371311#comment-14371311 ] Christian Posta commented on AMQ-5679: -- k! let me add that to the patch. and still doing some testing at a customer to make sure everything else is kosher... can commit when it all looks good, but will add the exclusion piece. thanks! > Wildcard Selector is Cached Against Virtual Topic when Browsing the Topic > - > > Key: AMQ-5679 > URL: https://issues.apache.org/jira/browse/AMQ-5679 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.1 > Environment: Any >Reporter: Justin Reock >Priority: Minor > > The fix for AMQ-4899 seems to have created an undesired side effect. Because > all consumer selectors issued against a Virtual Topic are now cached, this > means that even the Wildcard selector used when browsing the Virtual Topic is > cached as well. This effectively nullifies the selectorAware attribute of > the Virtual Topic, as once the browse happens, every message will be retained > in the Topic, regardless of whether they match a desired consumer selector. > To validate, create a selectorAware Virtual Topic and attach a consumer with > a selector active on the Topic. Produce some messages which don't match the > selector, and note that they are properly discarded. Then, browse the > Virtual Topic using the web console, and produce some messages that don't > match the selector again. They will be retained on the Virtual Topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5679) Wildcard Selector is Cached Against Virtual Topic when Browsing the Topic
[ https://issues.apache.org/jira/browse/AMQ-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371302#comment-14371302 ] Christian Posta commented on AMQ-5679: -- Yes! i think blacklisting or excluding selectors (specific ones, or even "turn wildcards off") would be reasonable configuration. > Wildcard Selector is Cached Against Virtual Topic when Browsing the Topic > - > > Key: AMQ-5679 > URL: https://issues.apache.org/jira/browse/AMQ-5679 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.1 > Environment: Any >Reporter: Justin Reock >Priority: Minor > > The fix for AMQ-4899 seems to have created an undesired side effect. Because > all consumer selectors issued against a Virtual Topic are now cached, this > means that even the Wildcard selector used when browsing the Virtual Topic is > cached as well. This effectively nullifies the selectorAware attribute of > the Virtual Topic, as once the browse happens, every message will be retained > in the Topic, regardless of whether they match a desired consumer selector. > To validate, create a selectorAware Virtual Topic and attach a consumer with > a selector active on the Topic. Produce some messages which don't match the > selector, and note that they are properly discarded. Then, browse the > Virtual Topic using the web console, and produce some messages that don't > match the selector again. They will be retained on the Virtual Topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5679) Wildcard Selector is Cached Against Virtual Topic when Browsing the Topic
[ https://issues.apache.org/jira/browse/AMQ-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371288#comment-14371288 ] Christian Posta commented on AMQ-5679: -- Would this be of any use for your case: https://issues.apache.org/jira/browse/AMQ-5672 > Wildcard Selector is Cached Against Virtual Topic when Browsing the Topic > - > > Key: AMQ-5679 > URL: https://issues.apache.org/jira/browse/AMQ-5679 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.1 > Environment: Any >Reporter: Justin Reock >Priority: Minor > > The fix for AMQ-4899 seems to have created an undesired side effect. Because > all consumer selectors issued against a Virtual Topic are now cached, this > means that even the Wildcard selector used when browsing the Virtual Topic is > cached as well. This effectively nullifies the selectorAware attribute of > the Virtual Topic, as once the browse happens, every message will be retained > in the Topic, regardless of whether they match a desired consumer selector. > To validate, create a selectorAware Virtual Topic and attach a consumer with > a selector active on the Topic. Produce some messages which don't match the > selector, and note that they are properly discarded. Then, browse the > Virtual Topic using the web console, and produce some messages that don't > match the selector again. They will be retained on the Virtual Topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5678) Would like to be able to limit queue depth by # of messages vs memory limits
[ https://issues.apache.org/jira/browse/AMQ-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14369987#comment-14369987 ] Christian Posta commented on AMQ-5678: -- Damn! I couldn't find it searching the JIRA. Thanks for linking them. > Would like to be able to limit queue depth by # of messages vs memory limits > > > Key: AMQ-5678 > URL: https://issues.apache.org/jira/browse/AMQ-5678 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: Christian Posta >Priority: Minor > > Right now we can place limits on our destinations/brokers based on memory and > messages sizes. It would be useful to reason about a queue depth by # of > messages ... so to be able to limit messages by "# of messages" and "max > message size" in a policy entry. These settings should still respect global > broker memory values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5678) Would like to be able to limit queue depth by # of messages vs memory limits
Christian Posta created AMQ-5678: Summary: Would like to be able to limit queue depth by # of messages vs memory limits Key: AMQ-5678 URL: https://issues.apache.org/jira/browse/AMQ-5678 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: Christian Posta Priority: Minor Right now we can place limits on our destinations/brokers based on memory and messages sizes. It would be useful to reason about a queue depth by # of messages ... so to be able to limit messages by "# of messages" and "max message size" in a policy entry. These settings should still respect global broker memory values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5672) Add an option to virtual topic selector cache to enforce only a single selector at a given time
Christian Posta created AMQ-5672: Summary: Add an option to virtual topic selector cache to enforce only a single selector at a given time Key: AMQ-5672 URL: https://issues.apache.org/jira/browse/AMQ-5672 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.11.1 Reporter: Christian Posta At the moment, the virtualTopicSelectorCache is pretty bare bones. we should allow configuration of the persist period, the file location, and some operational insight via JMX. We should also allow to configure the cache to a single number of selectors to enforce automatic clean-up for non-used selectors (and avoid large pileups of messages) and to ensure consistent usage across the queues that are used in the virtual topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5672) Add an option to virtual topic selector cache to enforce only a single selector at a given time
[ https://issues.apache.org/jira/browse/AMQ-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14365939#comment-14365939 ] Christian Posta commented on AMQ-5672: -- Latest patch here: https://github.com/christian-posta/activemq/tree/selector-cache-hacking > Add an option to virtual topic selector cache to enforce only a single > selector at a given time > --- > > Key: AMQ-5672 > URL: https://issues.apache.org/jira/browse/AMQ-5672 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.11.1 >Reporter: Christian Posta > > At the moment, the virtualTopicSelectorCache is pretty bare bones. we should > allow configuration of the persist period, the file location, and some > operational insight via JMX. We should also allow to configure the cache to a > single number of selectors to enforce automatic clean-up for non-used > selectors (and avoid large pileups of messages) and to ensure consistent > usage across the queues that are used in the virtual topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5603) Consider preallocation of journal files in batch increments
[ https://issues.apache.org/jira/browse/AMQ-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14350448#comment-14350448 ] Christian Posta commented on AMQ-5603: -- NOTE, should do this for leveldb also > Consider preallocation of journal files in batch increments > --- > > Key: AMQ-5603 > URL: https://issues.apache.org/jira/browse/AMQ-5603 > Project: ActiveMQ > Issue Type: New Feature > Components: Message Store >Reporter: Christian Posta >Priority: Minor > Labels: kahaDB, perfomance > > Right now (as of ActiveMQ 5.12 release) we preallocate journal files, but the > only scope is for entire journal file. The [potential] issue with that is if > user configures large journal file sizes, we can end up stalling writes > during log rotation because of the allocation process. There are two ways to > do the allocation, configurable to do it in userspace, or defer to kernel > space, but nevertheless it would be good to avoid this issue altogether by > preallocating in small batch sizes regardless of the journal max file size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta reopened AMQ-5578: -- Sorry for noise on this... but forgot that we should implement this on LevelDB too, so reopening > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > Fix For: 5.12.0 > > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta closed AMQ-5578. Resolution: Fixed > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > Fix For: 5.12.0 > > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349572#comment-14349572 ] Christian Posta commented on AMQ-5578: -- Fixed https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=commitdiff;h=8e551b4c > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > Fix For: 5.12.0 > > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349036#comment-14349036 ] Christian Posta commented on AMQ-5578: -- lol... was just at client yesterday and they pointed this out. missed it. will fix it. > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > Fix For: 5.12.0 > > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333426#comment-14333426 ] Christian Posta commented on AMQ-5578: -- Documented here: https://cwiki.apache.org/confluence/display/ACTIVEMQ/KahaDB > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > Fix For: 5.12.0 > > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5603) Consider preallocation of journal files in batch increments
[ https://issues.apache.org/jira/browse/AMQ-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329131#comment-14329131 ] Christian Posta commented on AMQ-5603: -- work started here https://github.com/christian-posta/activemq/commit/db1335d5883a4943c7d1cb6cef21d534676cafbb#diff-10aa392dba6f176b982ddd0229c2c407R118 > Consider preallocation of journal files in batch increments > --- > > Key: AMQ-5603 > URL: https://issues.apache.org/jira/browse/AMQ-5603 > Project: ActiveMQ > Issue Type: New Feature > Components: Message Store >Reporter: Christian Posta >Priority: Minor > Labels: kahaDB, perfomance > > Right now (as of ActiveMQ 5.12 release) we preallocate journal files, but the > only scope is for entire journal file. The [potential] issue with that is if > user configures large journal file sizes, we can end up stalling writes > during log rotation because of the allocation process. There are two ways to > do the allocation, configurable to do it in userspace, or defer to kernel > space, but nevertheless it would be good to avoid this issue altogether by > preallocating in small batch sizes regardless of the journal max file size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5603) Consider preallocation of journal files in batch increments
Christian Posta created AMQ-5603: Summary: Consider preallocation of journal files in batch increments Key: AMQ-5603 URL: https://issues.apache.org/jira/browse/AMQ-5603 Project: ActiveMQ Issue Type: New Feature Components: Message Store Reporter: Christian Posta Priority: Minor Right now (as of ActiveMQ 5.12 release) we preallocate journal files, but the only scope is for entire journal file. The [potential] issue with that is if user configures large journal file sizes, we can end up stalling writes during log rotation because of the allocation process. There are two ways to do the allocation, configurable to do it in userspace, or defer to kernel space, but nevertheless it would be good to avoid this issue altogether by preallocating in small batch sizes regardless of the journal max file size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta updated AMQ-5578: - Fix Version/s: 5.12.0 > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > Fix For: 5.12.0 > > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQ-5551) The DiskBenchmark util doesn't sync (fsync) to disk for sync writes
[ https://issues.apache.org/jira/browse/AMQ-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta closed AMQ-5551. Resolution: Fixed Fixed with https://github.com/apache/activemq/commit/2c92c34132d72f013ffe4a867187099714f7b231 > The DiskBenchmark util doesn't sync (fsync) to disk for sync writes > --- > > Key: AMQ-5551 > URL: https://issues.apache.org/jira/browse/AMQ-5551 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.10.1 >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.12.0 > > > We added a JVM flag, org.apache.activemq.file.skipMetadataUpdate, to control > whether to force metadata syncs or not when sync'ing to disk. Unfortunately, > that flag was not applied to the section of code that does the sync writes. > Fix on the way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5551) The DiskBenchmark util doesn't sync (fsync) to disk for sync writes
[ https://issues.apache.org/jira/browse/AMQ-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta updated AMQ-5551: - Fix Version/s: 5.12.0 > The DiskBenchmark util doesn't sync (fsync) to disk for sync writes > --- > > Key: AMQ-5551 > URL: https://issues.apache.org/jira/browse/AMQ-5551 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.10.1 >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.12.0 > > > We added a JVM flag, org.apache.activemq.file.skipMetadataUpdate, to control > whether to force metadata syncs or not when sync'ing to disk. Unfortunately, > that flag was not applied to the section of code that does the sync writes. > Fix on the way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMQ-5551) The DiskBenchmark util doesn't sync (fsync) to disk for sync writes
[ https://issues.apache.org/jira/browse/AMQ-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta reassigned AMQ-5551: Assignee: Christian Posta > The DiskBenchmark util doesn't sync (fsync) to disk for sync writes > --- > > Key: AMQ-5551 > URL: https://issues.apache.org/jira/browse/AMQ-5551 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.10.1 >Reporter: Christian Posta >Assignee: Christian Posta > > We added a JVM flag, org.apache.activemq.file.skipMetadataUpdate, to control > whether to force metadata syncs or not when sync'ing to disk. Unfortunately, > that flag was not applied to the section of code that does the sync writes. > Fix on the way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328323#comment-14328323 ] Christian Posta edited comment on AMQ-5578 at 2/19/15 11:37 PM: one more commit: https://github.com/apache/activemq/commit/023b2ac04501a97452eb8a23b6024fd336cb6cf6 added unit tests, logging, and removed the preallocated batch stuff which snuck in with the previous commit (rebased off wrong branch!). should be good to go now. was (Author: ceposta): one more commit: https://github.com/apache/activemq/commit/45e59e6e839ae89ffc099d32a4180ee307543aae added unit tests, logging, and removed the preallocated batch stuff which snuck in with the previous commit (rebased off wrong branch!). should be good to go now. > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328323#comment-14328323 ] Christian Posta commented on AMQ-5578: -- one more commit: https://github.com/apache/activemq/commit/45e59e6e839ae89ffc099d32a4180ee307543aae added unit tests, logging, and removed the preallocated batch stuff which snuck in with the previous commit (rebased off wrong branch!). should be good to go now. > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327803#comment-14327803 ] Christian Posta commented on AMQ-5578: -- okay patch updated and committed here: https://github.com/apache/activemq/commit/45e59e6e839ae89ffc099d32a4180ee307543aae i removed the options to do preallocation in on-demand batches. will do that in a separate jira. with the patch the following functionality is available: preallocationScope=[entire_journal] preallocationStrategy=[sparse_file|os_kernel_copy|zeros] the defaults are "entire_journal", and "sparse_file" the entire_journal option works great with "zeros", it also works great with "os_kernel_copy" but depending on your file system. There is a kernel bug related to using GFS2 that we're fixing at the Red Hat side. basically the difference is between the application zero'ing out the journal file for preallocation, or letting the OS do it in the kernel space. > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta updated AMQ-5578: - Fix Version/s: (was: 5.12.0) > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326758#comment-14326758 ] Christian Posta edited comment on AMQ-5578 at 2/18/15 11:54 PM: with the patch, we can now add: preallocationScope=[batch|entire_journal] preallocationStrategy=[sparse_file|os_kernel_copy|zeros] preallocationBatchSize the defaults are "entire_journal", "sparse_file", and 1048576 the entire_journal option works great with "zeros", it may crash because of a linux kernel bug related to GFS2 at the moment (to be patched) with "os_kernel_copy" but may work better for other file systems still trying to get the batch allocation to work properly, which will allocate space in the journal with zeros in 1 MB batches as the journal grows, without having to do a big-bang preallocation of the journal when it gets rotated. was (Author: ceposta): with the patch, we can now add: preallocationScope=[batch|entire_journal] preallocationStrategy=[sparse_file|os_kernel_copy|zeros] preallocationBatchSize the defaults are "entire_journal", "sparse_file", and 1048576 the entire_journal option works great with "zeros", it may crash because of a kernel bug related to GFS2 at the moment (to be patched) with "os_kernel_copy" but may work better for other file systems still trying to get the batch allocation to work properly, which will allocate space in the journal with zeros in 1 MB batches as the journal grows, without having to do a big-bang preallocation of the journal when it gets rotated. > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > Fix For: 5.12.0 > > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326758#comment-14326758 ] Christian Posta commented on AMQ-5578: -- with the patch, we can now add: preallocationScope=[batch|entire_journal] preallocationStrategy=[sparse_file|os_kernel_copy|zeros] preallocationBatchSize the defaults are "entire_journal", "sparse_file", and 1048576 the entire_journal option works great with "zeros", it may crash because of a kernel bug related to GFS2 at the moment (to be patched) with "os_kernel_copy" but may work better for other file systems still trying to get the batch allocation to work properly, which will allocate space in the journal with zeros in 1 MB batches as the journal grows, without having to do a big-bang preallocation of the journal when it gets rotated. > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > Fix For: 5.12.0 > > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMQ-5578) preallocate journal files
[ https://issues.apache.org/jira/browse/AMQ-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta reopened AMQ-5578: -- reopening... patch does preallocate, but uses sparse file, and does not show any improvement in performance. working on patch here to allow strategy to use preallocated journal files or to batch preallocation depending on need here: https://github.com/christian-posta/activemq/commit/db1335d5883a4943c7d1cb6cef21d534676cafbb patch still in flux > preallocate journal files > - > > Key: AMQ-5578 > URL: https://issues.apache.org/jira/browse/AMQ-5578 > Project: ActiveMQ > Issue Type: Improvement > Components: Message Store >Affects Versions: 5.11.0 >Reporter: Gary Tully >Assignee: Gary Tully > Labels: journal, kahaDB, perfomance > Fix For: 5.12.0 > > > Our journals are append only, however we use the size to track journal > rollover on recovery and replay. We can improve performance if we never > update the size on disk and preallocate on creation. > Rework journal logic to ensure size is never updated. This will allow the > configuration option from https://issues.apache.org/jira/browse/AMQ-4947 to > be the default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5551) The DiskBenchmark util doesn't sync (fsync) to disk for sync writes
Christian Posta created AMQ-5551: Summary: The DiskBenchmark util doesn't sync (fsync) to disk for sync writes Key: AMQ-5551 URL: https://issues.apache.org/jira/browse/AMQ-5551 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 5.10.1 Reporter: Christian Posta We added a JVM flag, org.apache.activemq.file.skipMetadataUpdate, to control whether to force metadata syncs or not when sync'ing to disk. Unfortunately, that flag was not applied to the section of code that does the sync writes. Fix on the way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5290) MQTT clients using durable subscriptions on networked brokers received duplicates
[ https://issues.apache.org/jira/browse/AMQ-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088504#comment-14088504 ] Christian Posta commented on AMQ-5290: -- Actually, it ended being okay (at least what I saw). Test committed: https://github.com/apache/activemq/blob/trunk/activemq-unit-tests/src/test/java/org/apache/activemq/MQTTNetworkOfBrokersFailoverTest.java > MQTT clients using durable subscriptions on networked brokers received > duplicates > - > > Key: AMQ-5290 > URL: https://issues.apache.org/jira/browse/AMQ-5290 > Project: ActiveMQ > Issue Type: Improvement > Components: MQTT >Affects Versions: 5.10.0 >Reporter: Timothy Bish > Fix For: 5.11.0 > > > MQTT clients that create durable subscriptions and that operate in a network > of Brokers can receive duplicate messages when they start failing back and > forth between brokers in the network. > We should investigate using Virtual Destinations under the covers instead of > durable topics subscriptions as this is a known problem with the durable > topic case. With Virtual Destinations the client would be subscribed to a > Queue that would receive all messages sent to the target Topic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5290) MQTT clients using durable subscriptions on networked brokers received duplicates
[ https://issues.apache.org/jira/browse/AMQ-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088484#comment-14088484 ] Christian Posta commented on AMQ-5290: -- I have a unit test that shows this failing before your enhancements and working afterward. Still debugging a little weird issue with the advisory messages+name of these virtual-topic queues, but will post something/commit the test when got it squared away. Looks pretty good on first glance :) > MQTT clients using durable subscriptions on networked brokers received > duplicates > - > > Key: AMQ-5290 > URL: https://issues.apache.org/jira/browse/AMQ-5290 > Project: ActiveMQ > Issue Type: Improvement > Components: MQTT >Affects Versions: 5.10.0 >Reporter: Timothy Bish > Fix For: 5.11.0 > > > MQTT clients that create durable subscriptions and that operate in a network > of Brokers can receive duplicate messages when they start failing back and > forth between brokers in the network. > We should investigate using Virtual Destinations under the covers instead of > durable topics subscriptions as this is a known problem with the durable > topic case. With Virtual Destinations the client would be subscribed to a > Queue that would receive all messages sent to the target Topic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5125) Broker and clients hang
[ https://issues.apache.org/jira/browse/AMQ-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14047662#comment-14047662 ] Christian Posta commented on AMQ-5125: -- Any chance you can see if having producers/consumers on separate connections make a difference? > Broker and clients hang > --- > > Key: AMQ-5125 > URL: https://issues.apache.org/jira/browse/AMQ-5125 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.9.0, 5.10.0 > Environment: Windows 7, Linux > JAVA_HOME=C:\Program Files\Java\jdk1.7.0_07 > ActiveMQ 5.9.0 with LevelDB storage adapter enabled >Reporter: Albert Barmettler >Priority: Blocker > Attachments: Broker-threaddump-1396544622970.tdump, > Clients-threaddump-1396544622970.tdump, VM.PNG, activemq.xml, > broker-threads-blocked.tdump, src.zip > > > JMS clients start to hang after a while in calls such as > session.createObjectMessage(). Both the broker and the hanging clients can't > be easily shut down when this happens - only forcefully applied kill's do the > job. > I'm using queues and transactional sessions. All clients (producers and > consumers) are in the same Java VM. There is only one JMS connection between > the application and the broker. Each client has its own session, but they all > share the same connection. > Normally, the data directory of the LevelDb contains only a few log files. > But in my case, the number of log files is steadily increasing. > Furthermore, I was able to track down the issue to following circumstance: > The problem only occurs, when consumers do a rollback instead of a commit > when they receive the message. The rollback / redelivery works as expected - > the same message is received again after a previous rollback. > As far as I can tell, the problem does not occur with KahaDb. > I'll attach a test program that provokes the error. It sets up a few hundred > queues, consumers and producers. The consumers just receive the message and > commit the session, but they also do "random" rollbacks. It can be observed > immediately that the number of files starts increasing in the data directory. > After a few minutes, the clients hang - sometimes sooner, sometimes later. > I'll also attach the config file for the broker. > I am aware, that heavy rollbacking should not happen in normal operation. But > from a long term stability perspective, this is a blocker for us. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (AMQ-5076) Pooled session creation blocks when maxActive is reached
[ https://issues.apache.org/jira/browse/AMQ-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta resolved AMQ-5076. -- Resolution: Fixed Fix Version/s: 5.10.0 Assignee: Christian Posta Fixed c3d8ca7..dc607bb > Pooled session creation blocks when maxActive is reached > > > Key: AMQ-5076 > URL: https://issues.apache.org/jira/browse/AMQ-5076 > Project: ActiveMQ > Issue Type: Improvement > Components: activemq-pool >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.10.0 > > > Pooled session creation blocks when maxActive is reached. This is > configurable to either block or thrown an exception. We should maybe expose > the config to the generic pool we use under the covers so it can be even more > fine tuned, or at least provide a way to set a timeout on the blocking > behavior so that threads don't sit and block forever. > See > http://commons.apache.org/proper/commons-pool/api-1.6/org/apache/commons/pool/impl/GenericKeyedObjectPool.html > > and > http://commons.apache.org/proper/commons-pool/api-1.6/org/apache/commons/pool/impl/GenericKeyedObjectPool.html#setMaxWait(long) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5076) Pooled session creation blocks when maxActive is reached
Christian Posta created AMQ-5076: Summary: Pooled session creation blocks when maxActive is reached Key: AMQ-5076 URL: https://issues.apache.org/jira/browse/AMQ-5076 Project: ActiveMQ Issue Type: Improvement Components: activemq-pool Reporter: Christian Posta Pooled session creation blocks when maxActive is reached. This is configurable to either block or thrown an exception. We should maybe expose the config to the generic pool we use under the covers so it can be even more fine tuned, or at least provide a way to set a timeout on the blocking behavior so that threads don't sit and block forever. See http://commons.apache.org/proper/commons-pool/api-1.6/org/apache/commons/pool/impl/GenericKeyedObjectPool.html and http://commons.apache.org/proper/commons-pool/api-1.6/org/apache/commons/pool/impl/GenericKeyedObjectPool.html#setMaxWait(long) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"
[ https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13910404#comment-13910404 ] Christian Posta commented on AMQ-3621: -- Les, I've committed this to trunk. Suggestions: Can you please finish documenting the Authentication and Authorization sections toward the bottom (marked "work in progress" at the moment). Maybe add referring links (or details if you have it working) about how to integrate with some of the other system Shiro supports (like LDAP, certs?) For the authorization part would be great to explain the verbs allowed (create, remove, wildcards, etc) Can you also give a note about the default behavior of vm:// connectors being treated as 'system' user? Otherwise, everything looks great. Thanks for all the unit tests, that definitely makes life easier :) Keep an eye out on the next nightly builds that include this commit. Please review that nightly and verify that it's to your liking. Commit: To https://git-wip-us.apache.org/repos/asf/activemq.git e7e317d..f9451e5 trunk -> trunk > Integrate Apache Shiro with ActiveMQ as "security solution" > --- > > Key: AMQ-3621 > URL: https://issues.apache.org/jira/browse/AMQ-3621 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Cservenak, Tamas >Assignee: Christian Posta > Fix For: 5.10.0 > > Attachments: AMQ-3621.git.patch > > > Integrate Apache Shiro with ActiveMQ as "security solution". > This would benefit for ActiveMQ to have support for a vast amount of already > existing solution (Realm implementations) that are out there for Shiro. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"
[ https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905628#comment-13905628 ] Christian Posta commented on AMQ-3621: -- Les, so far what I'm seeing looks great. I am going through it pretty closely, so please bare with me as I'm doing on spare time… I will have this committed by end of week for sure (if not earlier). > Integrate Apache Shiro with ActiveMQ as "security solution" > --- > > Key: AMQ-3621 > URL: https://issues.apache.org/jira/browse/AMQ-3621 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Cservenak, Tamas >Assignee: Christian Posta > Fix For: 5.10.0 > > Attachments: AMQ-3621.git.patch > > > Integrate Apache Shiro with ActiveMQ as "security solution". > This would benefit for ActiveMQ to have support for a vast amount of already > existing solution (Realm implementations) that are out there for Shiro. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"
[ https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904129#comment-13904129 ] Christian Posta commented on AMQ-3621: -- Thx Claus will take a look tonight. > Integrate Apache Shiro with ActiveMQ as "security solution" > --- > > Key: AMQ-3621 > URL: https://issues.apache.org/jira/browse/AMQ-3621 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Cservenak, Tamas >Assignee: Christian Posta > Fix For: 5.10.0 > > Attachments: AMQ-3621.git.patch > > > Integrate Apache Shiro with ActiveMQ as "security solution". > This would benefit for ActiveMQ to have support for a vast amount of already > existing solution (Realm implementations) that are out there for Shiro. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"
[ https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta reassigned AMQ-3621: Assignee: Christian Posta > Integrate Apache Shiro with ActiveMQ as "security solution" > --- > > Key: AMQ-3621 > URL: https://issues.apache.org/jira/browse/AMQ-3621 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Cservenak, Tamas >Assignee: Christian Posta > Fix For: 5.10.0 > > Attachments: AMQ-3621.git.patch > > > Integrate Apache Shiro with ActiveMQ as "security solution". > This would benefit for ActiveMQ to have support for a vast amount of already > existing solution (Realm implementations) that are out there for Shiro. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-3621) Integrate Apache Shiro with ActiveMQ as "security solution"
[ https://issues.apache.org/jira/browse/AMQ-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904107#comment-13904107 ] Christian Posta commented on AMQ-3621: -- This looks awesome Les, thanks for the contribution. I'll let Claus take it from here as he's assigned to it, but I look forward to trying this out. > Integrate Apache Shiro with ActiveMQ as "security solution" > --- > > Key: AMQ-3621 > URL: https://issues.apache.org/jira/browse/AMQ-3621 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Cservenak, Tamas >Assignee: Claus Ibsen > Fix For: 5.10.0 > > Attachments: AMQ-3621.git.patch > > > Integrate Apache Shiro with ActiveMQ as "security solution". > This would benefit for ActiveMQ to have support for a vast amount of already > existing solution (Realm implementations) that are out there for Shiro. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-4966) ActiveMQ 5.9.0 Hawtio is Extremely slow when accessed from http://localhost:8162
[ https://issues.apache.org/jira/browse/AMQ-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13881363#comment-13881363 ] Christian Posta commented on AMQ-4966: -- sure zmhassan, go right ahead and work on it :) by commenting that you're looking into it you've effectively assigned it to yourself :) > ActiveMQ 5.9.0 Hawtio is Extremely slow when accessed from > http://localhost:8162 > > > Key: AMQ-4966 > URL: https://issues.apache.org/jira/browse/AMQ-4966 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.9.0 > Environment: Running on OS X >Reporter: Robert E. Simmons Jr. MSc. >Priority: Minor > > After starting activemq, if I use the URL http://localhost:8161/ to access > the console, it lets me log in then runs extremely slow, an average of 15 to > 30 seconds per click. However if I get my ip from ifconfig and access it > using http://10.10.200.10:8161 then the Hawtio console runs as it should. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-4885) Typos in MessageStore
[ https://issues.apache.org/jira/browse/AMQ-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821958#comment-13821958 ] Christian Posta commented on AMQ-4885: -- Agreed. Fernando, can you clean up the patch? not sure how the package.html patches are necessary for this jira... as well as the binary diffs on the .class files... > Typos in MessageStore > - > > Key: AMQ-4885 > URL: https://issues.apache.org/jira/browse/AMQ-4885 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 > Environment: All supported environments. >Reporter: Fernando Ribeiro >Priority: Minor > Attachments: activemq.patch > > > Thes typos in the "addSubsciption" method and the "memoeyUSage" parameter > need to be fixed. I have also framed the "identity" parameter as a typo > because it doesn't follow the same convention as the other parameters in the > API. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (AMQ-4880) fix web site
[ https://issues.apache.org/jira/browse/AMQ-4880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta resolved AMQ-4880. -- Resolution: Fixed Patch committed on svn r1541592 Caches cleared on svn r886521. Thanks dkulp! > fix web site > > > Key: AMQ-4880 > URL: https://issues.apache.org/jira/browse/AMQ-4880 > Project: ActiveMQ > Issue Type: Bug >Reporter: Daniel Kulp >Assignee: Christian Posta > Attachments: amqsite.patch > > > Just a patch to fix some more issues with the website. > This SHOULD get it and the blog entries rendering completely again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (AMQ-4880) fix web site
[ https://issues.apache.org/jira/browse/AMQ-4880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta reassigned AMQ-4880: Assignee: Christian Posta > fix web site > > > Key: AMQ-4880 > URL: https://issues.apache.org/jira/browse/AMQ-4880 > Project: ActiveMQ > Issue Type: Bug >Reporter: Daniel Kulp >Assignee: Christian Posta > Attachments: amqsite.patch > > > Just a patch to fix some more issues with the website. > This SHOULD get it and the blog entries rendering completely again. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4824) Allow an IOException to be raised when ResourceException has been reached
Christian Posta created AMQ-4824: Summary: Allow an IOException to be raised when ResourceException has been reached Key: AMQ-4824 URL: https://issues.apache.org/jira/browse/AMQ-4824 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.9.0 Reporter: Christian Posta Priority: Minor See from discussion here: http://activemq.2283324.n4.nabble.com/Failover-on-no-allocated-disk-space-left-tt4672138.html#a4673160 We can tie broker usage limits to IOException handler to help clients know to failover when broker has reached limits. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (AMQ-4823) NetworkConnector not registered in JMX when created from Broker View
[ https://issues.apache.org/jira/browse/AMQ-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta resolved AMQ-4823. -- Resolution: Fixed Fixed on trunk. We make sure to register the NC before starting it. > NetworkConnector not registered in JMX when created from Broker View > > > Key: AMQ-4823 > URL: https://issues.apache.org/jira/browse/AMQ-4823 > Project: ActiveMQ > Issue Type: Bug > Components: JMX >Affects Versions: 5.9.0 >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.10.0 > > > When programmatically (or through JConsole) trying to add a network connect, > the connector does get properly added and started, but it does not get > registered in the JMX MBean tree so there is not introspection MBean support. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (AMQ-4823) NetworkConnector not registered in JMX when created from Broker View
Christian Posta created AMQ-4823: Summary: NetworkConnector not registered in JMX when created from Broker View Key: AMQ-4823 URL: https://issues.apache.org/jira/browse/AMQ-4823 Project: ActiveMQ Issue Type: Bug Components: JMX Affects Versions: 5.9.0 Reporter: Christian Posta Assignee: Christian Posta Fix For: 5.10.0 When programmatically (or through JConsole) trying to add a network connect, the connector does get properly added and started, but it does not get registered in the JMX MBean tree so there is not introspection MBean support. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4712) MQTT unit tests fail
[ https://issues.apache.org/jira/browse/AMQ-4712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792401#comment-13792401 ] Christian Posta commented on AMQ-4712: -- Guys, I took a look at this tonight. Goes deep... I won't have time to continue looking at it for a few days because i'll be with family, but if someone else wants to pick it up, here's what I found.. Somehow, the MQTT client is seeing two SUBACK frames for the same messageId (as indicated from the error: Command from server contained an invalid message id: 1). The broker logs that it only sends it once. So I took a peak at the SSLTransport and MQTTProtocolCodec... seems things are okay in that the next action is advanced properly from header to body, but for some reason, the readBuffers actually do have two instances of the SUBACK frame Digging deeper, it seems the SSL Transport is "reading" those frames off the wire, but I suspect incorrectly. It *might* have some issues w/ how it deals with buffer underflow/overflow, but I couldn't pin it down for sure. If nobody else gets to it, i'll pick it up later this weekend when I get a sec. > MQTT unit tests fail > > > Key: AMQ-4712 > URL: https://issues.apache.org/jira/browse/AMQ-4712 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT, Test Cases >Affects Versions: 5.9.0 >Reporter: Jean-Baptiste Onofré >Assignee: Rob Davies > Fix For: 5.9.0 > > > Running org.apache.activemq.transport.mqtt.MQTTNioTest > Tests run: 19, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 160.808 sec > <<< FAILURE! > Running org.apache.activemq.transport.mqtt.MQTTSSLTest > Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 161.426 sec > <<< FAILURE! > Running org.apache.activemq.transport.mqtt.MQTTTest > Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 158.184 sec > <<< FAILURE! > Results : > Tests in error: > testPingOnMQTTNIO(org.apache.activemq.transport.mqtt.MQTTNioTest): The > client id MUST be configured when clean session is set to false > > testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTNioTest): > String index out of range: -6 > > testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTSSLTest): > Command from server contained an invalid message id: 1 > > testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTTest): > Command from server contained an invalid message id: 1 > Tests run: 55, Failures: 0, Errors: 4, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4712) MQTT unit tests fail
[ https://issues.apache.org/jira/browse/AMQ-4712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790017#comment-13790017 ] Christian Posta commented on AMQ-4712: -- Hey JB, can you re-run the tests? I think *at least one (the first one)* of them should be fixed now. When I run the tests, I can only get the one Claus posted about to fail. Let us know what you find. > MQTT unit tests fail > > > Key: AMQ-4712 > URL: https://issues.apache.org/jira/browse/AMQ-4712 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT, Test Cases >Affects Versions: 5.9.0 >Reporter: Jean-Baptiste Onofré >Assignee: Rob Davies > Fix For: 5.9.0 > > > Running org.apache.activemq.transport.mqtt.MQTTNioTest > Tests run: 19, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 160.808 sec > <<< FAILURE! > Running org.apache.activemq.transport.mqtt.MQTTSSLTest > Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 161.426 sec > <<< FAILURE! > Running org.apache.activemq.transport.mqtt.MQTTTest > Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 158.184 sec > <<< FAILURE! > Results : > Tests in error: > testPingOnMQTTNIO(org.apache.activemq.transport.mqtt.MQTTNioTest): The > client id MUST be configured when clean session is set to false > > testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTNioTest): > String index out of range: -6 > > testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTSSLTest): > Command from server contained an invalid message id: 1 > > testReceiveMessageSentWhileOffline(org.apache.activemq.transport.mqtt.MQTTTest): > Command from server contained an invalid message id: 1 > Tests run: 55, Failures: 0, Errors: 4, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (AMQ-4715) Memory issue with ActiveMQ in java
[
https://issues.apache.org/jira/browse/AMQ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763467#comment-13763467
]
Christian Posta commented on AMQ-4715:
--
ritesh,
the correct approach would be to profile your app with yourkit or visualvm or
some java profiler as Tim recommended. you have not demonstrated a memory issue
with what you've presented thus far.
again, as Tim pointed out, garbage collection has its own algorithms for
initiating and reclaiming whatever objects are unreachable. if you use a jvm
profiling tool, you'll be able to see what objects are live, which are
unreachable (and would be gc'd) and can even force the GC to happen.
you should investigate further what your code is doing and what memory
characteristics you're experiencing and post those results here if there is an
apparent problem. additionally, this sort of discussion should be happening on
the mailing list, not this JIRA issue.
i suggest we close this and continue discussion on mailing list and reopen this
if there is conclusive issue to be found.
> Memory issue with ActiveMQ in java
> --
>
> Key: AMQ-4715
> URL: https://issues.apache.org/jira/browse/AMQ-4715
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.6.0, 5.7.0
>Reporter: ritesh
>
> Every time when i start connection and create session i can see “java.exe”
> (in task manger) memory get increase by 1000 to 2000K that’s ok.
> Now, when i closed connection and session expecting to memory go down by
> 1000 to 2000K but nothing happening.
> Here is my sample code.
> {code}
> public static void main(String[] args) {
> try {
> ActiveMQConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection= connectionFactory.createConnection();
> connection.start();
> for(int i=0;i<40;i++) {
> Session session= m_connection.createSession(false,
> Session.CLIENT_ACKNOWLEDGE);
> Destination queueDestination = session.createQueue("TestQueue");
> MessageProducer producer = session.createProducer(queueDestination);
> producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
> TextMessage textMessage = session.createTextMessage();
> textMessage.setText(“some text”);
> String jmsCorrelationId= UUID.randomUUID().toString();
> textMessage.setJMSCorrelationID(m_jmsCorrelationId);
> producer.send(textMessage);
> if (producer != null) {
> producer.close();
> producer=null;
> }
>
> if(m_session != null) {
> session.close();
> session=null;
> }
> } // end for loop
> if (connection!=null) {
> connection.close();
> }
> }
> }
> {code}
> If you will execute this program three to four times you will see significant
> memory get increase in task manger for “java.exe”.
> Thing most bothering me is that… after executing this program all allocated
> memory should get cleaned-up by GC but look like somehow it’s not happening.
> No idea what am I doing wrong?
> Please help me!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4594) Replace web console with hawtio
[ https://issues.apache.org/jira/browse/AMQ-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13758793#comment-13758793 ] Christian Posta commented on AMQ-4594: -- Just played with the latest activemq snapshot, and when I run hawtio the activemq tab doesn't appear at the top ribbon bar. I tried upgrading to the latest (1.2-M10) but still no bueno. Any ideas? I will hack around tomorrow more to find out what's going on, but curious if you see this on your side too. > Replace web console with hawtio > --- > > Key: AMQ-4594 > URL: https://issues.apache.org/jira/browse/AMQ-4594 > Project: ActiveMQ > Issue Type: New Feature >Affects Versions: 5.8.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.9.0 > > > Our administration web console has come to age and we should replace with > hawtio (http://hawt.io) project. Of course, we should make sure that ActiveMQ > plugin is feature compatible with current console. > hawtio provides lots of extra capabilities over the old web console; we can > send messages, move messages, delete messages and easily replay DLQ messages; > together with visualising producer/consumer flows and providing real time > metrics and charting on destinations. Plus hawtio is much smaller than the > old web console; we can also use the hawtio console remotely to connect to > other brokers and JVMs which just contain the tiny jolokia java agent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4695) Cannot connect as Anonymous over MQTT TransportConnector
[ https://issues.apache.org/jira/browse/AMQ-4695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756935#comment-13756935 ] Christian Posta commented on AMQ-4695: -- Fixed on trunk @ https://git-wip-us.apache.org/repos/asf/activemq.git > Cannot connect as Anonymous over MQTT TransportConnector > > > Key: AMQ-4695 > URL: https://issues.apache.org/jira/browse/AMQ-4695 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT >Affects Versions: 5.8.0 >Reporter: Christian Posta >Assignee: Christian Posta > > When configuring for authn/authz and allowing anonymous access, connections > made on the MQTT connector cannot connect via anonymous user. See an example > config here: > http://pastebin.com/91f029Aa -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4695) Cannot connect as Anonymous over MQTT TransportConnector
[ https://issues.apache.org/jira/browse/AMQ-4695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta resolved AMQ-4695. -- Resolution: Fixed Fix Version/s: 5.9.0 > Cannot connect as Anonymous over MQTT TransportConnector > > > Key: AMQ-4695 > URL: https://issues.apache.org/jira/browse/AMQ-4695 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT >Affects Versions: 5.8.0 >Reporter: Christian Posta >Assignee: Christian Posta > Fix For: 5.9.0 > > > When configuring for authn/authz and allowing anonymous access, connections > made on the MQTT connector cannot connect via anonymous user. See an example > config here: > http://pastebin.com/91f029Aa -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4699) Transacted producer does not throw ResourceAllocationException on error
[ https://issues.apache.org/jira/browse/AMQ-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753617#comment-13753617 ] Christian Posta commented on AMQ-4699: -- Spirit of this JIRA is related to: https://issues.apache.org/jira/browse/AMQ-3166 > Transacted producer does not throw ResourceAllocationException on error > --- > > Key: AMQ-4699 > URL: https://issues.apache.org/jira/browse/AMQ-4699 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.8.0 > Environment: ActiveMQ 5.8.0 server > ActiveMQ 5.8.0 client on Java 7 >Reporter: Joakim von Brandis > > Using a transacted producer session, with sendFailIfNoSpace=true or > sendFailIfNoSpaceAfterTimeout=timeout, the producer gets no error on whether > send() or commit(). Thus, the producer may pour out messages in a transacted > session, which are silently discarded by ActiveMQ. > A connection exception listener will receive ResourceAllocationException, but > since this happens in another thread than the sending client, there is no > guarantee that the client can be notified in time to avoid commit(). > Without using sendFailIfNoSpace(AfterTimeout), producer is blocked until > space is available, as expected. > The client should receive error on send() when the resource exhaustion is > reported, and in any case a commit() should not complete without error if the > server has discarded any messages in the transaction. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4693) Add kerberos authentcation for TCP connectors
[ https://issues.apache.org/jira/browse/AMQ-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753605#comment-13753605 ] Christian Posta commented on AMQ-4693: -- You should start by looking at the JAAS plugins and implementing this with JAAS. Then it would fit right in with the other AuthN strategies. May want to check this out as a launch point. http://mschrag.blogspot.com/2008/03/jaas-kerberos-auth.html > Add kerberos authentcation for TCP connectors > - > > Key: AMQ-4693 > URL: https://issues.apache.org/jira/browse/AMQ-4693 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.8.0 > Environment: linux, solaris >Reporter: Bhanu >Priority: Minor > > Hi, > Can kerberos based authentication be added to ActiveMQ's TCP connectors. > Thanks, > Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4695) Cannot connect as Anonymous over MQTT TransportConnector
Christian Posta created AMQ-4695: Summary: Cannot connect as Anonymous over MQTT TransportConnector Key: AMQ-4695 URL: https://issues.apache.org/jira/browse/AMQ-4695 Project: ActiveMQ Issue Type: Bug Components: MQTT Affects Versions: 5.8.0 Reporter: Christian Posta Assignee: Christian Posta When configuring for authn/authz and allowing anonymous access, connections made on the MQTT connector cannot connect via anonymous user. See an example config here: http://pastebin.com/91f029Aa -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4695) Cannot connect as Anonymous over MQTT TransportConnector
[ https://issues.apache.org/jira/browse/AMQ-4695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751560#comment-13751560 ] Christian Posta commented on AMQ-4695: -- I have a test case to demonstrate this and a patch to fix it. Will get it attached here when I get a sec > Cannot connect as Anonymous over MQTT TransportConnector > > > Key: AMQ-4695 > URL: https://issues.apache.org/jira/browse/AMQ-4695 > Project: ActiveMQ > Issue Type: Bug > Components: MQTT >Affects Versions: 5.8.0 >Reporter: Christian Posta >Assignee: Christian Posta > > When configuring for authn/authz and allowing anonymous access, connections > made on the MQTT connector cannot connect via anonymous user. See an example > config here: > http://pastebin.com/91f029Aa -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4378) Documentation on Shared File System Master Slave wrong or out of date
[ https://issues.apache.org/jira/browse/AMQ-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750238#comment-13750238 ] Christian Posta commented on AMQ-4378: -- Awesome, Carl. Thanks for your investigation. I've added a link to this JIRA from the wiki. > Documentation on Shared File System Master Slave wrong or out of date > - > > Key: AMQ-4378 > URL: https://issues.apache.org/jira/browse/AMQ-4378 > Project: ActiveMQ > Issue Type: Bug > Components: Documentation, Message Store >Affects Versions: 5.8.0 > Environment: Linux >Reporter: John Liptak >Priority: Minor > Labels: documentation > > The documentation at > http://activemq.apache.org/shared-file-system-master-slave.html says that > OCFS2 does not work, saying > "OCFS2 only supports locking with 'fcntl' and not 'lockf and flock', > therefore mutex file locking from Java isn't supported." > However, based on my reading of the OpenJDK source, Java uses fcntl, not > flock and this statement is incorrect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4648) fix script created by ./bin/activemq create to be able to pass command line args and run in the background
[ https://issues.apache.org/jira/browse/AMQ-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta resolved AMQ-4648. -- Resolution: Fixed Resolved with svn commit r1506395 > fix script created by ./bin/activemq create to be able to pass command line > args and run in the background > -- > > Key: AMQ-4648 > URL: https://issues.apache.org/jira/browse/AMQ-4648 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 >Reporter: Christian Posta >Assignee: Christian Posta >Priority: Minor > Fix For: 5.9.0 > > > after creating a broker with ./bin/activemq create > and running that broker with additional command lines eg: > ./bin/newbroker start -Dproperty=value > the args are passed to the parent script in such a way to cause the broker to > run in the foreground. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4648) fix script created by ./bin/activemq create to be able to pass command line args and run in the background
Christian Posta created AMQ-4648: Summary: fix script created by ./bin/activemq create to be able to pass command line args and run in the background Key: AMQ-4648 URL: https://issues.apache.org/jira/browse/AMQ-4648 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Reporter: Christian Posta Assignee: Christian Posta Priority: Minor Fix For: 5.9.0 after creating a broker with ./bin/activemq create and running that broker with additional command lines eg: ./bin/newbroker start -Dproperty=value the args are passed to the parent script in such a way to cause the broker to run in the foreground. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4372) WebConsole throw Java Heap Space when browse a queue with more than 100 elements
[ https://issues.apache.org/jira/browse/AMQ-4372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694780#comment-13694780 ] Christian Posta commented on AMQ-4372: -- Most likely 5.9 release. > WebConsole throw Java Heap Space when browse a queue with more than 100 > elements > > > Key: AMQ-4372 > URL: https://issues.apache.org/jira/browse/AMQ-4372 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 > Environment: Linux/Ubuntu >Reporter: Grégory OLIVER >Assignee: Timothy Bish > Labels: web-console > Fix For: 5.9.0 > > > I have a standalone installation of activemq. > When I want to browse a queue with more than 100 elements, the console throw > a Java Heap Space, because he try to show all elements in the queue. > But when I have 40 elements, the page work well, and i can browse messages. > It should be interesting to paginate this page, to only show, for example, > the first 100 elements. > The page : > http://localhost:8161/admin/browse.jsp?JMSDestination=TestQueueOne > Added : > I have tested with the 5.7.0 version of activemq and this bug doesn't exist. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3694) Blocked/Slow advisory consumers in duplex network connector, eventually breaks request/reply with temps
[
https://issues.apache.org/jira/browse/AMQ-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689240#comment-13689240
]
Christian Posta commented on AMQ-3694:
--
Yes, the 5.3.1 is affected. In general, there has been a lot of hardening
around network of brokers and temporary destinations since 5.3.1. Try out your
use cases on the latest 5.8.0.
> Blocked/Slow advisory consumers in duplex network connector, eventually
> breaks request/reply with temps
> ---
>
> Key: AMQ-3694
> URL: https://issues.apache.org/jira/browse/AMQ-3694
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Connector
>Affects Versions: 5.5.0
>Reporter: Gary Tully
>Assignee: Gary Tully
> Labels: activemq, blocking, networkconnector, requestreply, temp
> Fix For: 5.6.0
>
>
> In duplex network connectors, the destinations and temp advisories are not
> acked. This leads to a buildup of advisory messages on the bridging broker
> and missing advisories on the target.
> In the main, when the numbers of destinations is static and there are no temp
> queues per roundtrip this goes unnoticed.
> If request/reply is used over a network with a temp queue per request (a bit
> of an anti pattern, they are typically per connection), the problem is
> quickly visible with the default prefetch. Very quickly advisories for temp
> queue creation and producer consumers get blocked and communication comes to
> a halt.
> The root cause is that advisories are not acked in the duplex case so we can
> only get 750 (.75*prefetch) of them before we block.
> symptom{code}javax.jms.JMSException: The destination
> temp-queue://ID:xxx-xxx-0:7:17 does not exist.
> {code} or replies do not get propagated back because the consumer advisory is
> blocked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4586) ActiveMQConnection leaks executor threads onException
[ https://issues.apache.org/jira/browse/AMQ-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta resolved AMQ-4586. -- Resolution: Not A Problem Solution: either use failover, or make sure to catch all exceptions and clean up properly. > ActiveMQConnection leaks executor threads onException > - > > Key: AMQ-4586 > URL: https://issues.apache.org/jira/browse/AMQ-4586 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 >Reporter: Christian Posta > Attachments: AMQ-4586-fix1.patch, AMQ-4586-fix2.patch, > ClientConnectionThreadLeakTest.java, ClientConnectionThreadLeakTest.java > > > When a broker goes down, and client is not using failover transport, the > client can experience leaked threads because the executor is not properly > cleaned up. The symptoms of this are seeing "ActiveMQ Connection Executor" > threads staying around. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4586) ActiveMQConnection leaks executor threads onException
[ https://issues.apache.org/jira/browse/AMQ-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta updated AMQ-4586: - Attachment: ClientConnectionThreadLeakTest.java Yep, you're right. Updated test case passes every time without the patches. Thanks for your eyes on this.. > ActiveMQConnection leaks executor threads onException > - > > Key: AMQ-4586 > URL: https://issues.apache.org/jira/browse/AMQ-4586 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 >Reporter: Christian Posta > Attachments: AMQ-4586-fix1.patch, AMQ-4586-fix2.patch, > ClientConnectionThreadLeakTest.java, ClientConnectionThreadLeakTest.java > > > When a broker goes down, and client is not using failover transport, the > client can experience leaked threads because the executor is not properly > cleaned up. The symptoms of this are seeing "ActiveMQ Connection Executor" > threads staying around. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4586) ActiveMQConnection leaks executor threads onException
[ https://issues.apache.org/jira/browse/AMQ-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta updated AMQ-4586: - Attachment: AMQ-4586-fix2.patch AMQ-4586-fix1.patch Two options for fixes. #1 explicitly shuts down the ThreadPoolExecutor when AciveMQConnection#onException is called (after the transport is disposed) #2 the second reduces the core thread pool from 1 to 0 and the thread will be clean up after the cleanup time (5s). Thoughts? Any other suggestions? When using failover, we don't see this case come up. > ActiveMQConnection leaks executor threads onException > - > > Key: AMQ-4586 > URL: https://issues.apache.org/jira/browse/AMQ-4586 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 >Reporter: Christian Posta > Attachments: AMQ-4586-fix1.patch, AMQ-4586-fix2.patch, > ClientConnectionThreadLeakTest.java > > > When a broker goes down, and client is not using failover transport, the > client can experience leaked threads because the executor is not properly > cleaned up. The symptoms of this are seeing "ActiveMQ Connection Executor" > threads staying around. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4586) ActiveMQConnection leaks executor threads onException
[ https://issues.apache.org/jira/browse/AMQ-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta updated AMQ-4586: - Attachment: ClientConnectionThreadLeakTest.java Attaching test case > ActiveMQConnection leaks executor threads onException > - > > Key: AMQ-4586 > URL: https://issues.apache.org/jira/browse/AMQ-4586 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 >Reporter: Christian Posta > Attachments: ClientConnectionThreadLeakTest.java > > > When a broker goes down, and client is not using failover transport, the > client can experience leaked threads because the executor is not properly > cleaned up. The symptoms of this are seeing "ActiveMQ Connection Executor" > threads staying around. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4586) ActiveMQConnection leaks executor threads onException
Christian Posta created AMQ-4586: Summary: ActiveMQConnection leaks executor threads onException Key: AMQ-4586 URL: https://issues.apache.org/jira/browse/AMQ-4586 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Reporter: Christian Posta When a broker goes down, and client is not using failover transport, the client can experience leaked threads because the executor is not properly cleaned up. The symptoms of this are seeing "ActiveMQ Connection Executor" threads staying around. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4565) Cannot unsubscribe from virtual topics
[ https://issues.apache.org/jira/browse/AMQ-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673960#comment-13673960 ] Christian Posta commented on AMQ-4565: -- Hi Torsten, It's not the same. AMQ-4356 had to do with true durable subscribers not able to subscribe completely from a virtual topic. This issue I opened as a result of a discussion Scott England-Sullivan and I had about subscribing to a queue which backs the virtual topic, and then not ever being able to unsubscribe from it, ie, there is no good way for the subscriber to announce to the broker "don't keep this subscription around anymore" since it's queue based... > Cannot unsubscribe from virtual topics > -- > > Key: AMQ-4565 > URL: https://issues.apache.org/jira/browse/AMQ-4565 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.8.0 >Reporter: Christian Posta > > Virtual Topics allow us to do things with pub/sub that we cannot otherwise do > with JMS 1.1 spec. However, with durable subs we can "unsubscribe" a consumer > telling the broker we are no longer interested in messages. If we just stop > consuming, the queues can fill up. > With the queue-based impl of VT, we have to wait for the queue to be empty to > delete it... to do that reliably, the producer would have to stop producing? > And/or we have to use some TTL for the messages? Not sure... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4567) JMX operations on broker bypass authorization plugin
[ https://issues.apache.org/jira/browse/AMQ-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673160#comment-13673160 ] Christian Posta commented on AMQ-4567: -- I suppose the original idea was for read/write access to JMX to be a admin-priviledged function... Should we enhance that to enforce authn authz at the jmx level with the thought users might be using JMX? > JMX operations on broker bypass authorization plugin > - > > Key: AMQ-4567 > URL: https://issues.apache.org/jira/browse/AMQ-4567 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 >Reporter: Torsten Mielke > Labels: authorization > > When securing the broker using authentication and authorization, any JMX > operations on the broker completely bypass the authorization plugin. > So anyone can modify the broker bypassing the security checks. Also, because > of this its not possible to define a read only user for the web console. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4565) Cannot unsubscribe from virtual topics
Christian Posta created AMQ-4565: Summary: Cannot unsubscribe from virtual topics Key: AMQ-4565 URL: https://issues.apache.org/jira/browse/AMQ-4565 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.8.0 Reporter: Christian Posta Virtual Topics allow us to do things with pub/sub that we cannot otherwise do with JMS 1.1 spec. However, with durable subs we can "unsubscribe" a consumer telling the broker we are no longer interested in messages. If we just stop consuming, the queues can fill up. With the queue-based impl of VT, we have to wait for the queue to be empty to delete it... to do that reliably, the producer would have to stop producing? And/or we have to use some TTL for the messages? Not sure... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (AMQ-4553) Configure memory limit per group of queues
[ https://issues.apache.org/jira/browse/AMQ-4553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta reassigned AMQ-4553: Assignee: Christian Posta > Configure memory limit per group of queues > -- > > Key: AMQ-4553 > URL: https://issues.apache.org/jira/browse/AMQ-4553 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Liviu Ilea >Assignee: Christian Posta >Priority: Minor > Attachments: AMQ-4553_Configure_memory_limit_per_group_of.patch > > > We recently had a situation where we needed to configure a memory limit per > group of queues (see > http://activemq.2283324.n4.nabble.com/Configuring-Memory-Limit-per-Group-of-Queues-td4667338.html). > > It would be nice to have this feature in AMQ. > Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4553) Configure memory limit per group of queues
[ https://issues.apache.org/jira/browse/AMQ-4553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13670044#comment-13670044 ] Christian Posta commented on AMQ-4553: -- Plan to update the tests to show topics working too... > Configure memory limit per group of queues > -- > > Key: AMQ-4553 > URL: https://issues.apache.org/jira/browse/AMQ-4553 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Liviu Ilea >Priority: Minor > Attachments: AMQ-4553_Configure_memory_limit_per_group_of.patch > > > We recently had a situation where we needed to configure a memory limit per > group of queues (see > http://activemq.2283324.n4.nabble.com/Configuring-Memory-Limit-per-Group-of-Queues-td4667338.html). > > It would be nice to have this feature in AMQ. > Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4553) Configure memory limit per group of queues
[ https://issues.apache.org/jira/browse/AMQ-4553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta updated AMQ-4553: - Attachment: AMQ-4553_Configure_memory_limit_per_group_of.patch Attached first attempt... Gary/Tim, can you review? > Configure memory limit per group of queues > -- > > Key: AMQ-4553 > URL: https://issues.apache.org/jira/browse/AMQ-4553 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Liviu Ilea >Priority: Minor > Attachments: AMQ-4553_Configure_memory_limit_per_group_of.patch > > > We recently had a situation where we needed to configure a memory limit per > group of queues (see > http://activemq.2283324.n4.nabble.com/Configuring-Memory-Limit-per-Group-of-Queues-td4667338.html). > > It would be nice to have this feature in AMQ. > Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4546) kahadbstore nullpointerexception after restart
[
https://issues.apache.org/jira/browse/AMQ-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662292#comment-13662292
]
Christian Posta commented on AMQ-4546:
--
Can you create a unit test to reproduce this? Or at the very least give broker
configs, more detailed logs, and steps to reliably reproduce this? Looks like
the index pageFile is null, but no way to know how that happened.
> kahadbstore nullpointerexception after restart
> --
>
> Key: AMQ-4546
> URL: https://issues.apache.org/jira/browse/AMQ-4546
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.8.0
>Reporter: Matt Baker
>
> Received a null pointer exception after restarting activemq broker (embedded).
> First few messages are ok, then this happens and the broker (using network
> connector) starts to fail indicating remote exceptions.
> [//fathom1.win-fiaflosoa0a#43-1] ServiceDEBUG Error
> occured while processing sync command: Consu
> merInfo {commandId = 4, responseRequired = true, consumerId =
> ID:WIN-FIAFLOSOA0A-55945-1369075855975-4:22:1:1, destinati
> on = queue://fathom1.win-fiaflosoa0a, prefetchSize = 1,
> maximumPendingMessageLimit = 0, browser = false, dispatchAsync =
> true, selector = null, subscriptionName = null, noLocal = false, exclusive =
> false, retroactive = false, priority = 0,
> brokerPath = null, optimizedAcknowledge = false, noRangeAcks = false,
> additionalPredicate = null}, exception: java.lang.
> NullPointerException
> java.lang.NullPointerException
> at
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.getMessageCount(KahaDBStore.java:478)
> at
> org.apache.activemq.store.ProxyMessageStore.getMessageCount(ProxyMessageStore.java:101)
> at org.apache.activemq.broker.region.Queue.initialize(Queue.java:376)
> at
> org.apache.activemq.broker.region.DestinationFactoryImpl.createDestination(DestinationFactoryImpl.java:87)
> at
> org.apache.activemq.broker.region.AbstractRegion.createDestination(AbstractRegion.java:526)
> at
> org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:136)
> at
> org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:277)
> at
> org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:145)
> at
> org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:174)
> at
> org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:145)
> at
> org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:145)
> at
> org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:145)
> at
> org.apache.activemq.broker.MutableBrokerFilter.addDestination(MutableBrokerFilter.java:151)
> at
> org.apache.activemq.broker.region.AbstractRegion.lookup(AbstractRegion.java:452)
> at
> org.apache.activemq.broker.region.AbstractRegion.addConsumer(AbstractRegion.java:265)
> at
> org.apache.activemq.broker.region.RegionBroker.addConsumer(RegionBroker.java:353)
> at
> org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:89)
> at
> org.apache.activemq.advisory.AdvisoryBroker.addConsumer(AdvisoryBroker.java:91)
> at
> org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:89)
> at
> org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:89)
> at
> org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:89)
> at
> org.apache.activemq.broker.MutableBrokerFilter.addConsumer(MutableBrokerFilter.java:95)
> at
> org.apache.activemq.broker.TransportConnection.processAddConsumer(TransportConnection.java:619)
> at
> org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:332)
> at
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:329)
> at
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:184)
> at
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> at
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> at
> org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:241)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav
[jira] [Commented] (AMQ-4545) ActiveMQ Ajax API does not provide support for setting JMS properties.
[ https://issues.apache.org/jira/browse/AMQ-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662104#comment-13662104 ] Christian Posta commented on AMQ-4545: -- We can take a look when time permits, but maybe you can submit a patch for this? > ActiveMQ Ajax API does not provide support for setting JMS properties. > -- > > Key: AMQ-4545 > URL: https://issues.apache.org/jira/browse/AMQ-4545 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 5.8.0 >Reporter: Bhanu > > ActiveMQ Ajax API i.e amq.js does not have any support for setting message > properties. The sendMessage() call accepts only two parameters:- destination > and message. Can this be enhanced to support sending message properties like > JMSReplyTo, JMSCorrelationID etc. > Thanks, > Bhanu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4537) activemq-perftest broken in 5.8.0
[
https://issues.apache.org/jira/browse/AMQ-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Posta resolved AMQ-4537.
--
Resolution: Fixed
Fix Version/s: 5.9.0
Cool. No problem!
> activemq-perftest broken in 5.8.0
> -
>
> Key: AMQ-4537
> URL: https://issues.apache.org/jira/browse/AMQ-4537
> Project: ActiveMQ
> Issue Type: Bug
> Components: Performance Test
>Affects Versions: 5.8.0
> Environment: Ubuntu 12.10
> Maven 3.0.4
>Reporter: Nick Spacek
>Assignee: Christian Posta
> Fix For: 5.9.0
>
>
> I tried setting up my own Maven project to do some ActiveMQ load tests and
> also used the code at
> http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both
> give me the same error below when I execute: mvn activemq-perf:broker
> -Durl=broker:tcp://localhost:61616
> The double-var-encoded string looks strange. I also end up with a folder in
> the project directory: ${${project.build.directory}}.
> I am able to run other Maven plugins in the project and other local projects
> just fine.
> java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
> at java.net.URI$Parser.fail(URI.java:2829)
> at java.net.URI$Parser.checkChars(URI.java:3002)
> at java.net.URI$Parser.parseHierarchical(URI.java:3086)
> at java.net.URI$Parser.parse(URI.java:3044)
> at java.net.URI.(URI.java:595)
> at
> org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> 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:601)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> 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:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> After running mvn --debug, I can also see this being generated:
> [DEBUG] Configuration:
>
>default-value="${basedir}/src/main/resources/broker-conf">${${configDirectory}}
> ${${configFile}}
> ${${configType}}
> ${${project.build.directory}}
> ${${url}}
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more inf
[jira] [Commented] (AMQ-4537) activemq-perftest broken in 5.8.0
[
https://issues.apache.org/jira/browse/AMQ-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658506#comment-13658506
]
Christian Posta commented on AMQ-4537:
--
Probably just missed.. The plugin fixes most likely won't be back-ported.
Well.. when I use the perf plugin, I usually spin up a broker external from the
plugin, and usually external from the machine where the perf tests are taking
place. That might be a better option? That way you can test against any version
of broker you want regardless of what perf plugin version you're using.
> activemq-perftest broken in 5.8.0
> -
>
> Key: AMQ-4537
> URL: https://issues.apache.org/jira/browse/AMQ-4537
> Project: ActiveMQ
> Issue Type: Bug
> Components: Performance Test
>Affects Versions: 5.8.0
> Environment: Ubuntu 12.10
> Maven 3.0.4
>Reporter: Nick Spacek
>Assignee: Christian Posta
>
> I tried setting up my own Maven project to do some ActiveMQ load tests and
> also used the code at
> http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both
> give me the same error below when I execute: mvn activemq-perf:broker
> -Durl=broker:tcp://localhost:61616
> The double-var-encoded string looks strange. I also end up with a folder in
> the project directory: ${${project.build.directory}}.
> I am able to run other Maven plugins in the project and other local projects
> just fine.
> java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
> at java.net.URI$Parser.fail(URI.java:2829)
> at java.net.URI$Parser.checkChars(URI.java:3002)
> at java.net.URI$Parser.parseHierarchical(URI.java:3086)
> at java.net.URI$Parser.parse(URI.java:3044)
> at java.net.URI.(URI.java:595)
> at
> org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> 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:601)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> 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:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> After running mvn --debug, I can also see this being generated:
> [DEBU
[jira] [Commented] (AMQ-4487) java.lang.OutOfMemoryError: Java heap space
[ https://issues.apache.org/jira/browse/AMQ-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658461#comment-13658461 ] Christian Posta commented on AMQ-4487: -- What's the size of your messages? Have you tried on a 5.9 SNAPSHOT? > java.lang.OutOfMemoryError: Java heap space > --- > > Key: AMQ-4487 > URL: https://issues.apache.org/jira/browse/AMQ-4487 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.8.0 > Environment: OS - Linux 2.6.18-238.el5 #1 SMP Sun Dec 19 14:22:44 EST > 2010 x86_64 x86_64 x86_64 GNU/Linux > Activemq - 5.8 >Reporter: Subathra Jayaraman > > Hi, > When we browse a queue in webconsole we are getting > java.lang.OutOfMemoryError: Java heap space. > Memory allocation -> -Xms512m -Xmx3G > When we try to click the queue to view the messages below error is occurring. > We recently moved from 5.7 to 5.8 version. We dint face this issue in 5.7 > version. > Kindly help in fixing the issue. > java.lang.OutOfMemoryError: Java heap space > at java.util.Arrays.copyOf(Arrays.java:2882) > at java.io.CharArrayWriter.write(CharArrayWriter.java:88) > at java.io.PrintWriter.write(PrintWriter.java:382) > at > com.opensymphony.module.sitemesh.filter.RoutablePrintWriter.write(RoutablePrintWriter.java:144) > at > org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:181) > at > org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:449) > at > org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:462) > at > org.apache.jsp.browse_jsp$browse_jspHelper.invoke0(org.apache.jsp.browse_jsp:382) > at > org.apache.jsp.browse_jsp$browse_jspHelper.invoke(org.apache.jsp.browse_jsp:450) > at > org.apache.jsp.tag.web.jms.forEachMessage_tag.doTag(org.apache.jsp.tag.web.jms.forEachMessage_tag:89) > at > org.apache.jsp.browse_jsp._jspx_meth_jms_forEachMessage_0(org.apache.jsp.browse_jsp:170) > at > org.apache.jsp.browse_jsp._jspService(org.apache.jsp.browse_jsp:100) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:389) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1329) > at > org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83) > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300) > at > org.apache.activemq.web.SessionFilter.doFilter(SessionFilter.java:45) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300) > at > org.apache.activemq.web.filter.ApplicationContextFilter.doFilter(ApplicationContextFilter.java:102) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300) > at > com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129) > at > com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1300) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) > Thank you. > Regards, > Subathra. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4537) activemq-perftest broken in 5.8.0
[
https://issues.apache.org/jira/browse/AMQ-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658454#comment-13658454
]
Christian Posta commented on AMQ-4537:
--
Can you try a 5.9-SNAPSHOT? There were some fixes around the perftest maven
plugin especially around running the broker from the perf plugin...
https://issues.apache.org/jira/browse/AMQ-4466
> activemq-perftest broken in 5.8.0
> -
>
> Key: AMQ-4537
> URL: https://issues.apache.org/jira/browse/AMQ-4537
> Project: ActiveMQ
> Issue Type: Bug
> Components: Performance Test
>Affects Versions: 5.8.0
> Environment: Ubuntu 12.10
> Maven 3.0.4
>Reporter: Nick Spacek
>
> I tried setting up my own Maven project to do some ActiveMQ load tests and
> also used the code at
> http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both
> give me the same error below when I execute: mvn activemq-perf:broker
> -Durl=broker:tcp://localhost:61616
> The double-var-encoded string looks strange. I also end up with a folder in
> the project directory: ${${project.build.directory}}.
> I am able to run other Maven plugins in the project and other local projects
> just fine.
> java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
> at java.net.URI$Parser.fail(URI.java:2829)
> at java.net.URI$Parser.checkChars(URI.java:3002)
> at java.net.URI$Parser.parseHierarchical(URI.java:3086)
> at java.net.URI$Parser.parse(URI.java:3044)
> at java.net.URI.(URI.java:595)
> at
> org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> 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:601)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> 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:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> After running mvn --debug, I can also see this being generated:
> [DEBUG] Configuration:
>
>default-value="${basedir}/src/main/resources/broker-conf">${${configDirectory}}
> ${${configFile}}
> ${${configType}}
> ${${project.build.directory}}
> ${${url}}
>
--
This message is automatically
[jira] [Assigned] (AMQ-4537) activemq-perftest broken in 5.8.0
[
https://issues.apache.org/jira/browse/AMQ-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Posta reassigned AMQ-4537:
Assignee: Christian Posta
> activemq-perftest broken in 5.8.0
> -
>
> Key: AMQ-4537
> URL: https://issues.apache.org/jira/browse/AMQ-4537
> Project: ActiveMQ
> Issue Type: Bug
> Components: Performance Test
>Affects Versions: 5.8.0
> Environment: Ubuntu 12.10
> Maven 3.0.4
>Reporter: Nick Spacek
>Assignee: Christian Posta
>
> I tried setting up my own Maven project to do some ActiveMQ load tests and
> also used the code at
> http://svn.apache.org/repos/asf/activemq/sandbox/activemq-perftest/. Both
> give me the same error below when I execute: mvn activemq-perf:broker
> -Durl=broker:tcp://localhost:61616
> The double-var-encoded string looks strange. I also end up with a folder in
> the project directory: ${${project.build.directory}}.
> I am able to run other Maven plugins in the project and other local projects
> just fine.
> java.net.URISyntaxException: Illegal character in path at index 1: ${${url}}
> at java.net.URI$Parser.fail(URI.java:2829)
> at java.net.URI$Parser.checkChars(URI.java:3002)
> at java.net.URI$Parser.parseHierarchical(URI.java:3086)
> at java.net.URI$Parser.parse(URI.java:3044)
> at java.net.URI.(URI.java:595)
> at
> org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:95)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:150)
> at
> org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:57)
> at
> org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:104)
> 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:601)
> at org.apache.activemq.console.Main.runTaskClass(Main.java:262)
> at org.apache.activemq.console.Main.main(Main.java:115)
> at org.apache.activemq.maven.ServerMojo.execute(ServerMojo.java:108)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> 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:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> After running mvn --debug, I can also see this being generated:
> [DEBUG] Configuration:
>
>default-value="${basedir}/src/main/resources/broker-conf">${${configDirectory}}
> ${${configFile}}
> ${${configType}}
> ${${project.build.directory}}
> ${${url}}
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4534) When using ElectingLevelDBStore cannot delete all messages on startup
[ https://issues.apache.org/jira/browse/AMQ-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Posta resolved AMQ-4534. -- Resolution: Fixed Assignee: Christian Posta Fixed w/ r1482180 > When using ElectingLevelDBStore cannot delete all messages on startup > - > > Key: AMQ-4534 > URL: https://issues.apache.org/jira/browse/AMQ-4534 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.9.0 >Reporter: Christian Posta >Assignee: Christian Posta >Priority: Minor > > Cannot call BrokerService#deleteAllMessages() nor > setDeleteAllMessagesOnStartup() when using ElectingLevelDBStore... this is > because the elector has not yet been run, and is null. Simple solution is > override it (like a handful of other methods that are not intended to be > called without having an elected master) and give it a default behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4534) When using ElectingLevelDBStore cannot delete all messages on startup
Christian Posta created AMQ-4534: Summary: When using ElectingLevelDBStore cannot delete all messages on startup Key: AMQ-4534 URL: https://issues.apache.org/jira/browse/AMQ-4534 Project: ActiveMQ Issue Type: Bug Components: activemq-leveldb-store Affects Versions: 5.9.0 Reporter: Christian Posta Priority: Minor Cannot call BrokerService#deleteAllMessages() nor setDeleteAllMessagesOnStartup() when using ElectingLevelDBStore... this is because the elector has not yet been run, and is null. Simple solution is override it (like a handful of other methods that are not intended to be called without having an elected master) and give it a default behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4533) Messages stuck in queue with redelivered=true
[ https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656556#comment-13656556 ] Christian Posta commented on AMQ-4533: -- You may have forgotten to attach the test case? > Messages stuck in queue with redelivered=true > - > > Key: AMQ-4533 > URL: https://issues.apache.org/jira/browse/AMQ-4533 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.7.0 > Environment: Fuse Message Broker 5.7.0 >Reporter: Jason Shepherd >Priority: Minor > > We're getting message stuck in queues with the > redelivery flag set to true. > We used the following test model: put every 1 second 50 messages > sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE > and > while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 > seconds to move the message to RECEIPT_QUEUE, 10 other listeners on > RECEIPT_QUEUE consume and counts them. > We tried making one of the consumer slow by setting the > processing time to 10 seconds (sleep) and putting a heavy load in > 500 threads every 1 ms to some other queues the same time. > Our test case is attached, you might need to install some dependencies > to the local maven repository manually: > mvn install:install-file -DgroupId=org.apache.activemq > -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar > -Dfile=activemq-core-5.7.0.fuse-71-047.jar > mvn install:install-file -DgroupId=org.apache.kahadb > -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar > -Dfile=kahadb-5.7.0.fuse-71-047.jar > mvn install:install-file > -DgroupId=org.apache.geronimo.management.specs > -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 > -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar > mvn install:install-file -DgroupId=org.apache.activemq.pool > -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar > -Dfile=activemq-pool-5.7.0.fuse-71-047.jar > To run the test, simply use the Maven test target: > mvn clean test > If the problem occurs the you'll get a message like this in the test > results, (target/surefire-reports): > java.lang.AssertionError: Still messages in InputQueue expected:<0> > but was:<365> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4527) Add option to sync to disk on replicated stores (master and slave)
Christian Posta created AMQ-4527: Summary: Add option to sync to disk on replicated stores (master and slave) Key: AMQ-4527 URL: https://issues.apache.org/jira/browse/AMQ-4527 Project: ActiveMQ Issue Type: Improvement Affects Versions: 5.9.0 Reporter: Christian Posta Priority: Minor add option to specify sync behavior: syncTo="" where can be space separated list of: * disk - Sync to the local disk * replica - Sync to remote replica's memory * replicaDisk - Sync to remote replicas disk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
