So I did some debugging and I believe I have found a bug in Artemis. I create two topics, "t.*" and "t.123" (all using JMS). I register two consumers on both "t.*" and "t.123" and send a message to "t.123". If the consumers close both topics are correctly deleted from the broker. However, if I do *not* register a consumer to the more specific topic "t.123" its address will stay in the broker even after the consumer for "t.*" closes. The address "t.*" is correctly deleted, though. Reproducer it attached. The problem seems to be that in the second case no "bindingRemovedTimestamp" is set in the corresponding AddressInfo and hence it stays -1 and the adsress is not eligible for auto-deletion. If you confirm that this is indeed a bug I can open a ticket.
Thorsten Am Freitag, 5. März 2021, 17:56:37 CET schrieb Justin Bertram: > I don't know if there's a way to see why it wasn't deleted from the web > console. You could always attach a debugger to the broker and inspect it > that way. I believe the two main classes involved here would be > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.AddressQueue > Reaper and org.apache.activemq.artemis.core.server.impl.QueueManagerImpl. > > If you can work up a simple way to reproduce this I can take a closer look. > To this end I often recommend users create a variation of one of the > examples we ship with the broker. We ship a "topic-hierarchies" examples > which would probably be a good starting point. > > > Justin > > On Fri, Mar 5, 2021 at 10:44 AM Thorsten Meinl <thorsten.me...@knime.com> > > wrote: > > Hi, > > > > Am Freitag, 5. März 2021, 17:35:32 CET schrieb Justin Bertram: > > > First off, what version of ActiveMQ Artemis are you using? > > > > Sorry, forgot to mention: 2.16.0 > > > > > Do you have auto-delete-addresses = true? If so, addresses *should* be > > > deleted automatically when they have no more bindings. The wildcard > > > > itself > > > > > is a binding so that's probably why the address isn't removed. > > > > Yes, auto-delete-addresses = true. During operation I can see the wilcard > > adress "jobs.\*" which *does* get auto-deleted after all consumers are > > gone. > > Also some other addresses (without wilcard consumers attached) get deleted > > but > > not the jobs.A, jobs.B, ... addresses. > > Is there a way to see why they would stay there? In the "Attributes" tab > > in > > the Artemis Console I can see "Address size", "All queue names" and > > "Binding > > names" and all three are 0 or empty. > > > > > I think using a single topic with selectors on the subscriptions is a > > > viable alternative. There shouldn't be any performance penalty and the > > > semantics should be exactly what you're looking for. > > > > OK, good to hear. The we may likely go that way. > > > > Thanks! > > > > Thorsten > > > > > On Fri, Mar 5, 2021 at 10:09 AM Thorsten Meinl <thorsten.me...@knime.com > > > > > > wrote: > > > > Hi, > > > > > > > > We are currently building an application using ActiveMQ Artemis. The > > > > rough > > > > > > setup is as follows: We have consumers that are interested in all > > > > messages > > > > > > and > > > > other consumers that are only interested in a subset. So far we have > > > > been > > > > > > using topic hierarchies. The first group of consumers listens on e.g. > > > > "jobs.*" > > > > whereas the others listens on "jobs.A", "jobs.B", etc. All addresses, > > > > topics, > > > > queues are auto-created. What we notice now is that even if all > > > > consumers > > > > > > are > > > > gone there are still addresses "jobs.A", "jobs.B", ... remaining even > > > > though > > > > they don't have anything attached to them any more. No consumers, no > > > > queues, > > > > nothing. Therefore the first question: why is this and how can we > > > > prevent > > > > > > it? > > > > > > > > An alternative approach would be to use just one topic "jobs" and > > > > filter > > > > > > messages with message selectors (e.g. "id=A", "id=B", ...). This would > > > > eliminate the issue above. The question is whether there is a > > > > performance > > > > > > or > > > > functionality penalty involved with this approach. > > > > > > > > Thanks, > > > > > > > > Thorsten > > > > > > > > -- > > > > Dr.-Ing. Thorsten Meinl > > > > KNIME AG > > > > Hardturmstrasse 66 > > > > 8005 Zurich, Switzerland > > > > -- > > Dr.-Ing. Thorsten Meinl > > KNIME AG > > Hardturmstrasse 66 > > 8005 Zurich, Switzerland -- Dr.-Ing. Thorsten Meinl KNIME AG Hardturmstrasse 66 8005 Zurich, Switzerland
import javax.jms.Destination;
import javax.jms.JMSConsumer;
import javax.jms.JMSContext;
import org.apache.activemq.artemis.api.core.client.ActiveMQClient;
import org.apache.activemq.artemis.api.core.client.ServerLocator;
import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;
public class Test {
public static void main(String[] args) throws Exception {
try (ServerLocator locator = ActiveMQClient.createServerLocator("tcp://localhost:61616");
ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(locator);
JMSContext context = connectionFactory.createContext("knime", "knime", JMSContext.CLIENT_ACKNOWLEDGE)) {
Destination d1 = context.createTopic("t.*");
Destination d2 = context.createTopic("t.123");
JMSConsumer c1 = context.createConsumer(d1);
c1.setMessageListener(a -> {});
// Without explicitly registering a consumer for the specific topic t.123 the address will stay in the broker
// forever. If you comment out the following two lines you can easily reproduce it.
JMSConsumer c2 = context.createConsumer(d2);
c2.setMessageListener(a -> {});
context.createProducer().send(d2, new byte[0]);
Thread.sleep(5000);
}
}
}
signature.asc
Description: This is a digitally signed message part.
