[jira] [Commented] (AMQ-4970) Deletion of a queue inaffective across broker restart
[ https://issues.apache.org/jira/browse/AMQ-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13877188#comment-13877188 ] james commented on AMQ-4970: Hey Arthur, thanks for tracking this down and figuring out how to fix it. just curious, though, should there be a similar fix applied to Topic.java as well? > Deletion of a queue inaffective across broker restart > - > > Key: AMQ-4970 > URL: https://issues.apache.org/jira/browse/AMQ-4970 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 > Environment: mac osx/mavericks >Reporter: Arthur Naseef > Fix For: 5.10.0 > > Attachments: AMQ4970Test.zip, AMQ4970Test.zip, AMQ4970Test.zip, > amq4970.patch > > > Deleting a queue, it is revived from persistent store after a broker restart. > The following steps reproduce the problem: > * Create a queue (confirmed using the REST client I/F) > * Shutdown the broker > * Startup the broker > * Confirm queue still exists via the hawtio ui (correct operation so far) > * Delete the queue > * Confirm queue removed via the hawtio ui > * Shutdown the broker > * Startup the broker > * Confirm queue was not recreated via hawtio ui (failed: queue still exists) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-4953) Virutal Destination is not auto created when using Composite Destination
[
https://issues.apache.org/jira/browse/AMQ-4953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876935#comment-13876935
]
Jason Shepherd commented on AMQ-4953:
-
In a network or brokers would it be possible for messages to be forwarded to
networked brokers on FOO.BAR before be distributed to virtual destinations?
Could this cause duplicate messages?
> Virutal Destination is not auto created when using Composite Destination
>
>
> Key: AMQ-4953
> URL: https://issues.apache.org/jira/browse/AMQ-4953
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.9.0
> Environment: JBoss A-MQ 6.1.0.redhat-306
>Reporter: Jason Shepherd
>Priority: Minor
>
> When creating a composite queue (by editing activemq.xml) it doesn't seem
> like the queue is actually created.
> When I try to connect to the composite queue (from another server), the
> folowing Exception is thrown:
> Caused by: java.lang.SecurityException: User alice is not authorized to
> create: queue://FOO.BAR
> We doesn't allow the user ('alice') to create queues so this seems to
> indicate that the queue doesn't exist according to A-MQ.
> Part from my activemq.xml:
> {code}
> http://activemq.apache.org/schema/core";
> brokerName="${broker-name}"
> dataDirectory="${data}"
> advisorySupport="false"
> start="false">
> ...
>
>
>
>
> groupClass="org.apache.karaf.jaas.boot.principal.RolePrincipal">
>
> write="admin,alice" admin="admin" />
> write="admin,alice" admin="admin" />
> read="admin,alice" write="admin,alice" admin="admin,alice" />
>
>
>
>
>
> ...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> ** Note: This is destinct from AMQ-4320 which was about the destinations
> contained within the Composite Destinations, not being created.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (AMQ-4953) Virutal Destination is not auto created when using Composite Destination
[
https://issues.apache.org/jira/browse/AMQ-4953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876936#comment-13876936
]
Jason Shepherd commented on AMQ-4953:
-
Also, if a consumer subscribed to the new queue 'FOO.BAR', would it then
compete for messages with the composite destination(s), causing some messages
to not make it through to consumers of the composite destinations?
> Virutal Destination is not auto created when using Composite Destination
>
>
> Key: AMQ-4953
> URL: https://issues.apache.org/jira/browse/AMQ-4953
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.9.0
> Environment: JBoss A-MQ 6.1.0.redhat-306
>Reporter: Jason Shepherd
>Priority: Minor
>
> When creating a composite queue (by editing activemq.xml) it doesn't seem
> like the queue is actually created.
> When I try to connect to the composite queue (from another server), the
> folowing Exception is thrown:
> Caused by: java.lang.SecurityException: User alice is not authorized to
> create: queue://FOO.BAR
> We doesn't allow the user ('alice') to create queues so this seems to
> indicate that the queue doesn't exist according to A-MQ.
> Part from my activemq.xml:
> {code}
> http://activemq.apache.org/schema/core";
> brokerName="${broker-name}"
> dataDirectory="${data}"
> advisorySupport="false"
> start="false">
> ...
>
>
>
>
> groupClass="org.apache.karaf.jaas.boot.principal.RolePrincipal">
>
> write="admin,alice" admin="admin" />
> write="admin,alice" admin="admin" />
> read="admin,alice" write="admin,alice" admin="admin,alice" />
>
>
>
>
>
> ...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> ** Note: This is destinct from AMQ-4320 which was about the destinations
> contained within the Composite Destinations, not being created.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Re: [POLL] - Remove the old ActiveMQ Console
[1] -1 [2] 0 [3] +1 [4] +1 Using the webconsole for development/debugging purposes is extremely helpful. When moving to production systems, it should be a simple matter to turn it off. This is no different than removing debug code from your build when deploying. On Fri, Jan 17, 2014 at 5:33 AM, Robert Davies wrote: > I want to take a straw poll to see where everyone stands, because opinion > has varied, mine included. Straw polls can be a useful tool to move towards > consensus. This isn’t a formal vote, but to reduce the noise, can we keep > it to binding votes only ? > > > 1. Have one distribution with no default console, but make it easy to > deploy a console on demand (the original console - or 3rd party ones). > 2. Have two separate distributions, one with no console - and have a > second distribution with the original console > 3. One distribution, with hawtio as the console - ActiveMQ branded. > 4. One distribution, but uses the original ActiveMQ console only. > > Here’s my vote: > > [1]. +1 > [2] 0 > [3] 0 > [4] -1 > > thanks, > > Rob > >
[jira] [Resolved] (AMQ-3452) add 'stop' goal to the maven-activemq-plugin
[ https://issues.apache.org/jira/browse/AMQ-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-3452. --- Resolution: Fixed Fix Version/s: 5.10.0 Fixed on trunk. https://github.com/apache/activemq/pull/9 > add 'stop' goal to the maven-activemq-plugin > > > Key: AMQ-3452 > URL: https://issues.apache.org/jira/browse/AMQ-3452 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Paulo Siqueira > Fix For: 5.10.0 > > > This would be useful in at least two scenarios. In one of them, we have a > hudson building our system, and somehow the shutdown hook never gets called. > The second scenario is using the maven shell. If we don't stop activemq > explicitly, it will be running already in the next build, and cause an error > when trying to start a new one. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-4509) activemq-maven-plugin should have a stop goal
[ https://issues.apache.org/jira/browse/AMQ-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-4509. --- Resolution: Fixed Fix Version/s: 5.10.0 Fixed on trunk. https://github.com/apache/activemq/pull/9 > activemq-maven-plugin should have a stop goal > - > > Key: AMQ-4509 > URL: https://issues.apache.org/jira/browse/AMQ-4509 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.5.1 > Environment: Maven 3.0.5, Java 6, Plugin configuration: > true >Reporter: Tim Andersen >Priority: Minor > Labels: activemq-maven-plugin, maven-activemq-plugin > Fix For: 5.10.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > The maven-activemq-plugin (aka activemq-maven-plugin) in a multi-module Maven > project, we would like to stop and start ActiveMQ for each module where it is > needed (a "stop" and "start" goal, rather than a "run" goal with a shutdown > hook). We cannot run an individual module of our multi-module project because > we can only start ActiveMQ once for our aggregate pom.xml. This approach > would also resolve AMQ-1628 in a different way than was suggested. The > approach we are suggesting is similar to how the cargo plugin handles tomcat. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
activemq pull request: https://issues.apache.org/jira/browse/AMQ-3452
GitHub user alexcojocaru opened a pull request: https://github.com/apache/activemq/pull/9 https://issues.apache.org/jira/browse/AMQ-3452 As well as https://issues.apache.org/jira/browse/AMQ-4509 Add Maven plugin goal to stop the ActiveMQ broker You can merge this pull request into a Git repository by running: $ git pull https://github.com/alexcojocaru/activemq trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq/pull/9.patch commit 2ec6d3f19213d63ac05c3befce52671442f7e5fa Author: acojocaru Date: 2014-01-20T15:14:27Z https://issues.apache.org/jira/browse/AMQ-3452 As well as https://issues.apache.org/jira/browse/AMQ-4509 Add Maven plugin goal to stop the ActiveMQ broker
activemq pull request: Add a stop goal to the ActiveMQ Maven plugin.
Github user alexcojocaru closed the pull request at: https://github.com/apache/activemq/pull/8
activemq pull request: Activemq 5.5.1.1
Github user alexcojocaru closed the pull request at: https://github.com/apache/activemq/pull/7
activemq pull request: Add a stop goal to the ActiveMQ Maven plugin.
GitHub user alexcojocaru opened a pull request: https://github.com/apache/activemq/pull/8 Add a stop goal to the ActiveMQ Maven plugin. Requested by https://issues.apache.org/jira/browse/AMQ-3452 and https://issues.apache.org/jira/browse/AMQ-4509. You can merge this pull request into a Git repository by running: $ git pull https://github.com/alexcojocaru/activemq trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq/pull/8.patch commit 6aa81e3ee78035e0d9af76b64788585913bc4742 Author: acojocaru Date: 2014-01-20T15:14:27Z https://issues.apache.org/jira/browse/AMQ-3452 As well as https://issues.apache.org/jira/browse/AMQ-4509 Add Maven plugin goal to stop the ActiveMQ broker commit b2d8d2b50ad5abeaf02cad39759b8fc9728680f9 Author: acojocaru Date: 2014-01-20T16:10:47Z Maven plugin: fix the code style
[jira] [Resolved] (AMQ-4970) Deletion of a queue inaffective across broker restart
[ https://issues.apache.org/jira/browse/AMQ-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-4970. --- Resolution: Fixed Fix Version/s: 5.10.0 Fixed on trunk. > Deletion of a queue inaffective across broker restart > - > > Key: AMQ-4970 > URL: https://issues.apache.org/jira/browse/AMQ-4970 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.0 > Environment: mac osx/mavericks >Reporter: Arthur Naseef > Fix For: 5.10.0 > > Attachments: AMQ4970Test.zip, AMQ4970Test.zip, AMQ4970Test.zip, > amq4970.patch > > > Deleting a queue, it is revived from persistent store after a broker restart. > The following steps reproduce the problem: > * Create a queue (confirmed using the REST client I/F) > * Shutdown the broker > * Startup the broker > * Confirm queue still exists via the hawtio ui (correct operation so far) > * Delete the queue > * Confirm queue removed via the hawtio ui > * Shutdown the broker > * Startup the broker > * Confirm queue was not recreated via hawtio ui (failed: queue still exists) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-4979) Put back Jolokia management API
Dejan Bosanac created AMQ-4979: -- Summary: Put back Jolokia management API Key: AMQ-4979 URL: https://issues.apache.org/jira/browse/AMQ-4979 Project: ActiveMQ Issue Type: Improvement Affects Versions: 5.10.0 Reporter: Dejan Bosanac Assignee: Dejan Bosanac Fix For: 5.10.0 Now that hawtio is pulled out, we need to put back standalone Jolokia API as it was in 5.8.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (AMQ-4972) FailoverConsumerTest.testPublisherFailsOver is failing
[ https://issues.apache.org/jira/browse/AMQ-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Earls resolved AMQ-4972. -- Resolution: Fixed Removed this test based on Tim's suggestion. > FailoverConsumerTest.testPublisherFailsOver is failing > -- > > Key: AMQ-4972 > URL: https://issues.apache.org/jira/browse/AMQ-4972 > Project: ActiveMQ > Issue Type: Bug >Reporter: Kevin Earls >Assignee: Kevin Earls >Priority: Minor > > I get the following error for this test: > Running org.apache.activemq.transport.failover.FailoverConsumerTest > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.936 sec <<< > FAILURE! - in org.apache.activemq.transport.failover.FailoverConsumerTest > testPublisherFailsOver(org.apache.activemq.transport.failover.FailoverConsumerTest) > Time elapsed: 5.479 sec <<< FAILURE! > junit.framework.AssertionFailedError: expected:<1> but was:<0> > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.failNotEquals(Assert.java:329) > at junit.framework.Assert.assertEquals(Assert.java:78) > at junit.framework.Assert.assertEquals(Assert.java:234) > at junit.framework.Assert.assertEquals(Assert.java:241) > at junit.framework.TestCase.assertEquals(TestCase.java:409) > at > org.apache.activemq.transport.failover.FailoverConsumerTest.testPublisherFailsOver(FailoverConsumerTest.java:121) > Results : > Failed tests: > > FailoverConsumerTest>CombinationTestSupport.runBare:113->CombinationTestSupport.runBare:107->testPublisherFailsOver:121 > expected:<1> but was:<0> > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-4978) JoramJmsNioTest hangs intermittently
Kevin Earls created AMQ-4978: Summary: JoramJmsNioTest hangs intermittently Key: AMQ-4978 URL: https://issues.apache.org/jira/browse/AMQ-4978 Project: ActiveMQ Issue Type: Bug Components: Test Cases Reporter: Kevin Earls Assignee: Kevin Earls Priority: Minor The JoramJmsNioTest hangs intermittently, particularly on CI nodes. I'll add a stack trace. This is most likely fixed by QPID 0.26. Re-test once that is released. $ jstack 7157 2014-01-20 10:14:31 Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode): "Attach Listener" daemon prio=10 tid=0x7f09f400d800 nid=0x1ca9 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "ActiveMQ BrokerService[localhost] Task-2" daemon prio=10 tid=0x7f09e4029000 nid=0x1c97 waiting on condition [0x7f0a1179d000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xeebf1108> (a java.util.concurrent.SynchronousQueue$TransferStack) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359) at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:942) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) "ActiveMQ BrokerService[localhost] Task-1" daemon prio=10 tid=0x7f09e4028800 nid=0x1c96 waiting on condition [0x7f0a10782000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xeebf1108> (a java.util.concurrent.SynchronousQueue$TransferStack) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359) at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:942) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) "ActiveMQ Transport Server: amqp+nio://localhost:0" daemon prio=10 tid=0x7f0a1c69e800 nid=0x1c93 runnable [0x7f0a10681000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked <0xeec186b0> (a sun.nio.ch.Util$2) - locked <0xeec186a0> (a java.util.Collections$UnmodifiableSet) - locked <0xeec18588> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at sun.nio.ch.ServerSocketAdaptor.accept(ServerSocketAdaptor.java:121) - locked <0xeead9ec8> (a java.lang.Object) at org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.java:301) at java.lang.Thread.run(Thread.java:744) "RMI Reaper" prio=10 tid=0x7f09e4038800 nid=0x1c90 in Object.wait() [0x7f0a1149a000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xf0e6d6c0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) - locked <0xf0e6d6c0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151) at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:351) at java.lang.Thread.run(Thread.java:744) "RMI TCP Accept-1099" daemon prio=10 tid=0x7f0a1c70e000 nid=0x1c8e runnable [0x7f0a10984000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398) at java.net.ServerSocket.implAccept(ServerSocket.java:530) at java.net.ServerSocket.accept(ServerSocket.java:498) at sun.rmi.transport.tcp.TCPTra
