• cheeser
  • ernimril
  • joed
  • kinabalu
  • lunk
  • ojacobson
  • r0bby
  • ThaDon
  • ricky_clarkson
  • topriddy

« 2019-07-11


2019-07-13 »

Nick Message Date
tmielke [tmielke!] has joined #apache-activemq [03:06]
dejanb [dejanb!] has joined #apache-activemq [03:34]
calohmn [calohmn!] has joined #apache-activemq [03:49]
wallbroken [wallbroken!~Thunderbi@unaffiliated/wallbroken] has joined #apache-activemq [03:53]
tmielke parted the channel: [04:35]
bambitroll [bambitroll!] has joined #apache-activemq [05:53]
bambitroll parted the channel: [05:53]
tbish [tbish!] has joined #apache-activemq [07:34]
jbertram [jbertram!~jbertram@redhat/jboss/jbertram] has joined #apache-activemq [07:41]
jbertram hacst: it kind of depends on the protocol/client [08:18]
rkieley [rkieley!~rkieley@] has joined #apache-activemq [08:23]
hacst jbertram: AMQP [08:40]
javabot [javabot!~javabot@unaffiliated/javabot] has joined #apache-activemq [09:17]
jbertram hacst: unless you were using the JMS over AMQP library I think you'd have to use the FQQN [09:35]
jbertram hacst: again, I'm not terribly familiar with the AMQP implementation [09:35]
hacst Still very helpful. This is an interesting restriction compared to ActiveMQ (btw., I solved my ActiveMQ problem and so the individual dead letter stuff works there now, for some reason I had to create seperate policies for each subscriber. Creating one that matches all queues didn't work). [09:36]
jbertram hacst: right, the addressing model in Artemis is a bit more granular [09:37]
hacst I would imagine the FQQN concept would make it hard to use artemis as a drop-in for other brokers (e.g. rabbit, activemq) which have no such naming restrictions. [09:38]
jbertram hacst: I believe if the address and there is 1 anycast queue with the same name then you can just use that one name [09:39]
hacst Yeah [09:40]
jbertram hacst: I was just looking through some tests which indicate that's true [09:40]
jbertram hacst: so I don't think that would be a migration hurdle [09:41]
hacst Well. If you use multicast (aka implement a "topic" for pub/sub) you'll have more than one queue and none will be named like the topic queue. There there is no such mechanism afaik [09:42]
jbertram hacst: true [09:43]
jbertram hacst: I'm not sure how AMQP handles that [09:43]
hacst It's a shame that there isn't a standalone concept of a queue that can just be bound to addresses. [09:43]
hacst Imho that would be quite powerful [09:44]
jbertram hacst: I think you'd just subscribe to the address (i.e. just create a consumer or whatever) [09:44]
hacst topic::subscriber is the FQQN pattern [09:44]
jbertram hacst: then the subscriber would get it's own queue [09:44]
jbertram hacst: so one queue bound to multiple addresses? [09:45]
jbertram hacst: does AMQP differentiate between point-to-point and pub-sub? [09:46]
hacst No. It's all just nodes you establish a link to. [09:46]
hacst But as I'm trying to get close to the behavior of the Azure ServiceBus broker implementation being able to match its naming schemes simplifies compat [09:47]
hacst << Here is MS's description of what they are doing [09:48]
hacst hacst's title: "AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide | Microsoft Docs" [09:48]
jbertram hacst: so tests I'm looking at indicate you can just "subscribe" to the address name [09:48]
jbertram hacst: you don't necessarily need to do topic::subscription [09:49]
hacst If I have <address name="foo"><multicast><queue name="bar" /></multicast></address> I can subscribe too "bar" ? Unless my testing was wrong that doesn't work. [09:50]
hacst I had to do foo::bar [09:51]
jbertram if you want to get *that* specific subscription, then yes [09:51]
jbertram if you want "normal" pub/sub semantics you can just subscribe to the address [09:51]
hacst Interesting. How does that work under the covers? Does it create a transient queue for me? [09:52]
jbertram an address with a single multicast queue where you always subscribe to that single queue defeats the purpose of multicast [09:52]
jbertram yes, it will create a transient queue for you [09:52]
hacst Well. That just a simple example. Of course I have multiple queues or multicast wouldn't be helpful [09:53]
hacst As I said it's a pub/sub use-case (though with fixed persistent queues for the subscribers) [09:53]
jbertram so every subscribe will get it's own queue and since its multicast every queue and every subscriber will get the message [09:53]
hacst How does it know what queue I used before if I reconnect? Or is this only for getting things sent while you are connected? [09:54]
jbertram normal pub-sub semantics are only for getting things while you're connected [09:55]
jbertram although there's things like a durable subscription in JMS [09:55]
jbertram which create a non-transient queue on the address [09:55]
hacst ASB only offers the non-transient pub/sub variant so that's what I'm aiming at. [09:56]
jbertram and the client provides details (i.e. client ID and subscription name) to reconnect to its queue [09:56]
hacst I see. So there you would use the FQQN too I assume [09:56]
jbertram hacst: not with JMS [09:56]
hacst For some reason the openwire protocol adapter seems to have some special handling to be able to strip it down again. No idea why it's only there though. Probably some convention. [09:57]
jbertram hacst: but other protocols/APIs don't support those same interaction semantics so you'd probably need to use FQQN [09:57]
hacst (virtualTopicConsumerWildcards) [09:59]
hacst In any case. For the specific thing I'm trying to do something like <address name="bar"><alias name="foo::bar" /></address> would've been neat. If you only target artemis it's not an issue of course. [10:02]
jbertram hacst: destination names are usually externalized from an application exactly for this reason [10:07]
jbertram hacst: e.g. JNDI for Java [10:07]
hacst Don't really know what JNDI is. Is it a service you query to retrieve endpoint names for JMS etc.? [10:08]
jbertram hacst: yup [10:10]
hacst Never heard of something like that in other language ecosystems. [10:10]
jbertram hacst: that's one of its uses anyway [10:10]
jbertram hacst: it's good for portability so JMS clients can switch between brokers with minimal effort [10:11]
jbertram (or no effort) [10:11]
jbertram hacst: seems like your app could benefit from something like that [10:13]
jbertram hacst: btw, the virtualTopicConsumerWildcards is to ease migration for 5.x users who leverage its "virtual topics" feature [10:23]
hacst jbertram: I see how such an abstraction can make sense. Though it's probably simpler for me to push out endpoint naming into the app configuration to work around such stuff. I'm messing around with AMQP because I want something I can use from every language against Azure ServiceBus and at least one (preferably more) other non Azure bound broker. Basically it's supposed to be a small "framework" to [10:28]
hacst prevent Azure vendor lock in for our applications. [10:28]
hacst And the less code/config has to change when switching brokers the better things will work. [10:28]
jbertram hacst: sure, but AMQP doesn't define those naming conventions so you can expect differences between providers [10:31]
hacst jbertram: Sure. Though tbo artemis is the first one where I couldn't just name things freely. Which is fine. I'm ok with pushing this out to config. But every difference I can configure away is a bit less hassle. [10:34]
hacst *configure away in the broker [10:34]
jbertram hacst: what other brokers have you tried? [10:34]
rkieley [rkieley!] has joined #apache-activemq [10:34]
hacst jbertram: rabbitmq and activemq [10:35]
hacst Well. ASB definitely doesn't let me choose anything so artemis being the first was a lie ;) [10:35]
jbertram understood [10:38]
jbertram hacst: I could see value in a "fqqn-alias" for a <queue> [10:41]
jbertram hacst: so you could use "myName" from the client and that would get translated into "myAddress::myQueue" on the broker [10:42]
jbertram (as you already mentioned) [10:42]
hacst jbertram: Yeah. That would do it. [10:48]
hacst jbertram: Btw. I'm still trying to get the divert configuration to get to work for per-subscriber DLQ behavior. Do you see anything obviously wrong with this: . I can't seem to get it to match on the diverts. [10:49]
hacst Alternatively is there something like a compositeQueue in activemq where can "multicast" into other addresses with their own DLQ behavior? [10:51]
jbertram hacst: config looks OK to me...what behavior are you seeing? just that the messages aren't matching? [10:55]
jbertram hacst: there is something called a composite queue in ActiveMQ [10:56]
jbertram hacst: [10:56]
jbertram hacst: that doc is JMS-centric...not sure if that works for AMQP [10:57]
hacst jbertram: I have it working in activemq. I meant is there something like that in artemis. [10:58]
jbertram hacst: no [10:58]
hacst jbertram: Yeah. It looks like they just aren't matching. They just end up in the _dlq iirc. Let me check again [10:59]
hacst jbertram: Yeah. They just go through into mytopic/_dlq without being diverted [11:06]
hacst Looking into the header of one of them I see String Property - JMS_AMQP_MA__AMQ_ORIG_QUEUE mytopic/subscribers/sub1 [11:07]
hacst (and another copy with sub2 ofc) [11:08]
cek [cek!uid23454@gateway/web/] has joined #apache-activemq [01:16]