[jira] [Created] (AMQ-5252) Purge through webconsole fails if authorizationPlugin is used
Richard Wagg created AMQ-5252:
-
Summary: Purge through webconsole fails if authorizationPlugin is
used
Key: AMQ-5252
URL: https://issues.apache.org/jira/browse/AMQ-5252
Project: ActiveMQ
Issue Type: Bug
Components: webconsole
Affects Versions: 5.10.0
Reporter: Richard Wagg
Priority: Minor
Upgrading from a 5.5.1 broker to 5.10.
I've managed to work around the issue by making some changes to
org.apache.activemq.web.LocalBrokerFacade, but unsure if this is the root issue
or a band-aid fix.
{code}
Set destinations =
getManagedBroker().getQueueRegion().getDestinations(destination);
{code}
returns a AuthorizationDestinationFilter when the code is expecting a
org.apache.activemq.broker.region.Queue - calling getNext() on the
AuthorizationDestinationFilter returns the expected Queue.
Old code:
{code}
public void purgeQueue(ActiveMQDestination destination) throws Exception {
Set destinations =
getManagedBroker().getQueueRegion().getDestinations(destination);
for (Iterator i = destinations.iterator(); i.hasNext();)
{
Destination dest = (Destination) i.next();
if (dest instanceof Queue) {
Queue regionQueue = (Queue) dest;
regionQueue.purge();
}
}
}
{code}
new:
{code}
public void purgeQueue(ActiveMQDestination destination) throws Exception {
Set destinations =
getManagedBroker().getQueueRegion().getDestinations(destination);
for (Iterator i = destinations.iterator(); i.hasNext();)
{
Destination dest = (Destination) i.next();
if (dest instanceof Queue) {
Queue regionQueue = (Queue) dest;
regionQueue.purge();
}
else if(dest instanceof AuthorizationDestinationFilter)
{
AuthorizationDestinationFilter adf =
(AuthorizationDestinationFilter)dest;
if (adf.getNext() instanceof Queue)
{
Queue regionQueue = (Queue)adf.getNext();
regionQueue.purge();
}
}
}
}
{code}
Attached is the activemq.xml file we're using to test this - creating a message
on the webconsole and then attempting to purge it will fail unless either the
code change above is made, or the plugins section of activemq.xml is
commented out.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-5252) Purge through webconsole fails if authorizationPlugin is used
[
https://issues.apache.org/jira/browse/AMQ-5252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Wagg updated AMQ-5252:
--
Attachment: activemq.xml
Purge through webconsole fails if authorizationPlugin is used
-
Key: AMQ-5252
URL: https://issues.apache.org/jira/browse/AMQ-5252
Project: ActiveMQ
Issue Type: Bug
Components: webconsole
Affects Versions: 5.10.0
Reporter: Richard Wagg
Priority: Minor
Attachments: activemq.xml
Upgrading from a 5.5.1 broker to 5.10.
I've managed to work around the issue by making some changes to
org.apache.activemq.web.LocalBrokerFacade, but unsure if this is the root
issue or a band-aid fix.
{code}
Set destinations =
getManagedBroker().getQueueRegion().getDestinations(destination);
{code}
returns a AuthorizationDestinationFilter when the code is expecting a
org.apache.activemq.broker.region.Queue - calling getNext() on the
AuthorizationDestinationFilter returns the expected Queue.
Old code:
{code}
public void purgeQueue(ActiveMQDestination destination) throws Exception {
Set destinations =
getManagedBroker().getQueueRegion().getDestinations(destination);
for (Iterator i = destinations.iterator(); i.hasNext();)
{
Destination dest = (Destination) i.next();
if (dest instanceof Queue) {
Queue regionQueue = (Queue) dest;
regionQueue.purge();
}
}
}
{code}
new:
{code}
public void purgeQueue(ActiveMQDestination destination) throws Exception {
Set destinations =
getManagedBroker().getQueueRegion().getDestinations(destination);
for (Iterator i = destinations.iterator(); i.hasNext();)
{
Destination dest = (Destination) i.next();
if (dest instanceof Queue) {
Queue regionQueue = (Queue) dest;
regionQueue.purge();
}
else if(dest instanceof AuthorizationDestinationFilter)
{
AuthorizationDestinationFilter adf =
(AuthorizationDestinationFilter)dest;
if (adf.getNext() instanceof Queue)
{
Queue regionQueue = (Queue)adf.getNext();
regionQueue.purge();
}
}
}
}
{code}
Attached is the activemq.xml file we're using to test this - creating a
message on the webconsole and then attempting to purge it will fail unless
either the code change above is made, or the plugins section of
activemq.xml is commented out.
--
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-tabpanelfocusedCommentId=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] [Commented] (AMQ-4987) io wait on replicated levelDB slaves
[ https://issues.apache.org/jira/browse/AMQ-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047684#comment-14047684 ] anselme dewavrin commented on AMQ-4987: --- still up and running in production. io wait on replicated levelDB slaves Key: AMQ-4987 URL: https://issues.apache.org/jira/browse/AMQ-4987 Project: ActiveMQ Issue Type: Test Components: activemq-leveldb-store Affects Versions: 5.9.0 Environment: debian VM 2.6.32-5-amd64, jdk7 Reporter: anselme dewavrin Priority: Minor Fix For: 5.9.0 Dear all, I set up a 3-nodes replicatedLevelDB activeMQ cluster on 3 different machines, as explained on the activemq site (with zookeeper etc.). I made a message injector using the php stomp client described here : http://stomp.fusesource.org/documentation/php/book.html Then I injected persistent messages as fast as possible (giving about 100 messages/s, each message is 10k). Everything works fine, then I measured the servers' activity with vmstat 1. I saw no iowait on the master node, but 20% on both slaves. This would impeach scalabitity I suppose. And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report. The machines are not swapping (paging). Here is what I tried, without success : -specify explicitly sync=quorum_mem -JNI implementation of the leveldb store (and verified it is used) -setting flushDelay to 2000 Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much to disk ? Many thanks in advance Yours, Anselme -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQ-5253) Typo In settings parameter for policyEntries
Alexey created AMQ-5253: --- Summary: Typo In settings parameter for policyEntries Key: AMQ-5253 URL: https://issues.apache.org/jira/browse/AMQ-5253 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.9.0 Environment: OS X Version 10.9.3 AMQ were installed through homebrew Reporter: Alexey Priority: Minor I noticed that there is a typo in property used for deleting inactive destinations. In documentation example(http://activemq.apache.org/delete-inactive-destinations.html) inactiveTimoutBeforeGC used. Which has one letter missing in word Timout. I tried to change property name to inactiveTimeoutBeforeGC and active mq failed to start afterwards, so seems there is typo in parameter name. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5250) temp queue not working after long run of activemq
[ https://issues.apache.org/jira/browse/AMQ-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047799#comment-14047799 ] Timothy Bish commented on AMQ-5250: --- A JUnit test case to demonstrate the issue is needed to understand the use case. temp queue not working after long run of activemq - Key: AMQ-5250 URL: https://issues.apache.org/jira/browse/AMQ-5250 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.9.0 Reporter: Rural Hunter We encounterred a problem when using temp queue for request/reply pattern. It worked normally but after a long time lets say several weeks, the applications using temp queue started to report errors: 2014-06-25 08:25:59 [WARNING] Message back to the server fails！ javax.jms.InvalidDestinationException: Cannot publish to a deleted Destination: temp-queue://ID:myserver-45345-1403492084155-1:1:259 at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1748) at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:289) at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:224) at org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:300) I created a test application to test the temp when the problem happened and found this: On each connection, the temp queue worked once and the second time it failed. I also tried to monitor messages in ActiveMQ.Advisory.TempQueue. But I could only receive one message after I subsribed on it everytime. I checked the activemq log and there was nothing about the problem. Other applications not using temp queue worked fine. This happened twice in recent month. I just had to restart activemq to fix it. I saw a same error in mailing list but not sure if it's the same problem: http://activemq.2283324.n4.nabble.com/Getting-a-quot-Cannot-publish-to-a-deleted-Destination-quot-but-eventually-works-after-a-couple-of-rs-td4682497.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5253) Typo In settings parameter for policyEntries
[ https://issues.apache.org/jira/browse/AMQ-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047829#comment-14047829 ] Timothy Bish commented on AMQ-5253: --- We should probably create an alternative set of accessors and deprecate the old one's so that we have names that are spelled correctly. Typo In settings parameter for policyEntries Key: AMQ-5253 URL: https://issues.apache.org/jira/browse/AMQ-5253 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.9.0 Environment: OS X Version 10.9.3 AMQ were installed through homebrew Reporter: Alexey Priority: Minor Fix For: 5.11.0 I noticed that there is a typo in property used for deleting inactive destinations. In documentation example(http://activemq.apache.org/delete-inactive-destinations.html) inactiveTimoutBeforeGC used. Which has one letter missing in word Timout. I tried to change property name to inactiveTimeoutBeforeGC and active mq failed to start afterwards, so seems there is typo in parameter name. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-5253) Typo In settings parameter for policyEntries
[ https://issues.apache.org/jira/browse/AMQ-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-5253: -- Fix Version/s: 5.11.0 Typo In settings parameter for policyEntries Key: AMQ-5253 URL: https://issues.apache.org/jira/browse/AMQ-5253 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.9.0 Environment: OS X Version 10.9.3 AMQ were installed through homebrew Reporter: Alexey Priority: Minor Fix For: 5.11.0 I noticed that there is a typo in property used for deleting inactive destinations. In documentation example(http://activemq.apache.org/delete-inactive-destinations.html) inactiveTimoutBeforeGC used. Which has one letter missing in word Timout. I tried to change property name to inactiveTimeoutBeforeGC and active mq failed to start afterwards, so seems there is typo in parameter name. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5192) Add a statistic for showing how many messages every scheduler job triggered
[ https://issues.apache.org/jira/browse/AMQ-5192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048173#comment-14048173 ] Timothy Bish commented on AMQ-5192: --- I think that the issue should be updated to make it clear what is being requested. The title and the description seem to be asking for two different features. 1. The title seems to be asking for a way to see how many times a given scheduled job has run. 2. The description seems to be asking for a way to know how many jobs are scheduled to fire a message to a specific destination. If you want both then there should be one issue for each. Add a statistic for showing how many messages every scheduler job triggered --- Key: AMQ-5192 URL: https://issues.apache.org/jira/browse/AMQ-5192 Project: ActiveMQ Issue Type: Improvement Components: Broker, JMX, Job Scheduler Affects Versions: 5.8.0 Reporter: Burning Luffy Assignee: Timothy Bish Is there anyway we can see how many messages are scheduled for re-delivery per queue? At the moment the best we can do is get the number of scheduled jobs via JMX, which is not queue-specific. Is it possible to programmatically query the KahaDB to inspect the scheduled redelivery jobs? -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [ActiveMQCPP 3.8.2|Linux] crash in activemq::core::ConnectionAudit::isDuplicate
On 06/29/2014 10:16 AM, Lyubov Romanchuk wrote: Hi, We use activemqcpp library from the version 3.8.2. Sometimes there is a crash in activemq::core::ConnectionAudit::isDuplicate. Could you please advise with this core - what may cause such crash, is it a known issue? Here is the call stack from one of the cores: * 1 Thread 32129 0x760417ab in decaf::lang::PointerComparatoractivemq::commands::ActiveMQDestination, decaf::util::concurrent::atomic::AtomicRefCounter::operator() (this=0x874ce1c, left=..., right=...) at decaf/lang/Pointer.h:243 (gdb) bt #0 0x760417ab in decaf::lang::PointerComparatoractivemq::commands::ActiveMQDestination, decaf::util::concurrent::atomic::AtomicRefCounter::operator() (this=0x874ce1c, left=..., right=...) at decaf/lang/Pointer.h:243 #1 0x76108cad in std::_Rb_treedecaf::lang::Pointeractivemq::commands::ActiveMQDestination, decaf::util::concurrent::atomic::AtomicRefCounter, std::pairdecaf::lang::Pointeractivemq::commands::ActiveMQDestination, decaf::util::concurrent::atomic::AtomicRefCounter const, decaf::lang::Pointeractivemq::core::ActiveMQMessageAudit, decaf::util::concurrent::atomic::AtomicRefCounter , std::_Select1ststd::pairdecaf::lang::Pointeractivemq::commands::ActiveMQDestination, decaf::util::concurrent::atomic::AtomicRefCounter const, decaf::lang::Pointeractivemq::core::ActiveMQMessageAudit, decaf::util::concurrent::atomic::AtomicRefCounter , decaf::lang::PointerComparatoractivemq::commands::ActiveMQDestination, decaf::util::concurrent::atomic::AtomicRefCounter, std::allocatorstd::pairdecaf::lang::Pointeractivemq::commands::ActiveMQDestination, decaf::util::concurrent::atomic::AtomicRefCounter const, decaf::lang::Pointeractivemq::core::ActiveMQMessageAudit, decaf::util::concurrent::atomic::AtomicRefCounter ::find (this=0x874ce14, __k=...) at /packages/gnu-3.2.3-20.linux30/include/c++/3.2.3/bits/stl_tree.h:669 #2 0x76100316 in decaf::util::StlMapdecaf::lang::Pointeractivemq::commands::ActiveMQDestination, decaf::util::concurrent::atomic::AtomicRefCounter, decaf::lang::Pointeractivemq::core::ActiveMQMessageAudit, decaf::util::concurrent::atomic::AtomicRefCounter, decaf::lang::PointerComparatoractivemq::commands::ActiveMQDestination, decaf::util::concurrent::atomic::AtomicRefCounter ::containsKey (this=0x874ce10, key=...) at /packages/gnu-3.2.3-20.linux30/include/c++/3.2.3/bits/stl_map.h:345 #3 0x760fb57a in activemq::core::ConnectionAudit::isDuplicate (this=0x874cdf4, dispatcher=0xc0a7e94, message=...) at decaf/util/StlMap.h:794 #4 0x7603605c in activemq::core::ActiveMQConnection::isDuplicate (this=0x8a74408, dispatcher=0x32332d46, message=...) at decaf/util/concurrent/atomic/AtomicRefCounter.h:46 #5 0x76141bb5 in activemq::core::kernels::ActiveMQConsumerKernel::dispatch (this=0xc0a7e88, dispatch=...) at activemq/core/kernels/ActiveMQSessionKernel.h:330 #6 0x760e4b1b in activemq::core::ActiveMQSessionExecutor::dispatch (this=0x32332d46, dispatch=...) at decaf/lang/Pointer.h:258 #7 0x760e4e92 in activemq::core::ActiveMQSessionExecutor::iterate (this=0x5a5676a0) at activemq/core/ActiveMQSessionExecutor.cpp:181 #8 0x762659b6 in activemq::threads::DedicatedTaskRunner::run (this=0x5a6935e0) at activemq/threads/DedicatedTaskRunner.cpp:141 #9 0x7646285e in decaf::lang::Thread::run (this=0x32332d46) at decaf/lang/Thread.cpp:141 #10 0x76421c17 in (anonymous namespace)::runCallback (arg=0x5abb66e8) at decaf/internal/util/concurrent/Threading.cpp:266 #11 0x76421b89 in (anonymous namespace)::threadEntryMethod (arg=0x5abb66e8) at decaf/internal/util/concurrent/Threading.cpp:254 #12 0x757f145b in start_thread () from /lib/libpthread.so.0 #13 0x7566024e in clone () from /lib/libc.so.6 (gdb) t 10 [Switching to thread 10 (Thread 32093)]#0 0x756951b2 in dl_iterate_phdr () from /lib/libc.so.6 (gdb) bt #0 0x756951b2 in dl_iterate_phdr () from /lib/libc.so.6 #1 0x0849cd55 in _Unwind_Find_FDE () #2 0x0849a815 in ?? () #3 0x0849b0a8 in _Unwind_RaiseException () #4 0x75762309 in __cxa_throw () from /usr/lib/libstdc++.so.5 #5 0x760a6bb8 in activemq::core::ActiveMQMessageAudit::isDuplicate (this=0xbbef390, msgId=...) at decaf/util/HashMap.h:971 #6 0x760faba1 in activemq::core::ConnectionAudit::isDuplicate (this=0x874cdf4, dispatcher=0x4ff9473c, message=...) at decaf/lang/Pointer.h:258 #7 0x7603605c in activemq::core::ActiveMQConnection::isDuplicate (this=0x8a74408, dispatcher=0xb726488, message=...) at decaf/util/concurrent/atomic/AtomicRefCounter.h:46 #8 0x76141bb5 in activemq::core::kernels::ActiveMQConsumerKernel::dispatch (this=0x4ff94730, dispatch=...) at activemq/core/kernels/ActiveMQSessionKernel.h:330 #9 0x760e4b1b in activemq::core::ActiveMQSessionExecutor::dispatch (this=0xb726488, dispatch=...) at decaf/lang/Pointer.h:258 #10 0x760e4e92 in activemq::core::ActiveMQSessionExecutor::iterate (this=0xb25f658) at activemq/core/ActiveMQSessionExecutor.cpp:181 #11 0x762659b6 in activemq::threads::DedicatedTaskRunner::run
[jira] [Commented] (AMQ-5250) temp queue not working after long run of activemq
[ https://issues.apache.org/jira/browse/AMQ-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048400#comment-14048400 ] Rural Hunter commented on AMQ-5250: --- I understand but it's very hard to reproduce. The test case will pass normally and will only fail after activemq keeps running for several weeks. temp queue not working after long run of activemq - Key: AMQ-5250 URL: https://issues.apache.org/jira/browse/AMQ-5250 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.9.0 Reporter: Rural Hunter We encounterred a problem when using temp queue for request/reply pattern. It worked normally but after a long time lets say several weeks, the applications using temp queue started to report errors: 2014-06-25 08:25:59 [WARNING] Message back to the server fails！ javax.jms.InvalidDestinationException: Cannot publish to a deleted Destination: temp-queue://ID:myserver-45345-1403492084155-1:1:259 at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1748) at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:289) at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:224) at org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:300) I created a test application to test the temp when the problem happened and found this: On each connection, the temp queue worked once and the second time it failed. I also tried to monitor messages in ActiveMQ.Advisory.TempQueue. But I could only receive one message after I subsribed on it everytime. I checked the activemq log and there was nothing about the problem. Other applications not using temp queue worked fine. This happened twice in recent month. I just had to restart activemq to fix it. I saw a same error in mailing list but not sure if it's the same problem: http://activemq.2283324.n4.nabble.com/Getting-a-quot-Cannot-publish-to-a-deleted-Destination-quot-but-eventually-works-after-a-couple-of-rs-td4682497.html -- This message was sent by Atlassian JIRA (v6.2#6252)
