This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[09:19:30] * ChanServ sets mode: +o purplefox [09:33:38] <drfits> Hi! [09:35:27] * ChanServ sets mode: +o temporalfox

[09:38:29] <drfits> I'll be very appreciate if you can create channel for developers on because irc chat is so painful (hard to check chat logs, hard to past code snippets for question, need additional client and so on)

[09:39:04] <drfits> is it possible to create vert.x chat here?

[09:42:05] <drfits> it also possible to add irc bridge to chat

[13:35:41] <rajith> purplefox: Hey Tim

[13:40:56] <purplefox> rajith: hi

[13:54:09] <rajith> purplefox: Is there a way for me to figure out when a handler is registered to a particular 'address'

[13:59:25] <rajith> purplefox: the reason I ask is, that it allows us to create AMQP subscriptions for messages that we are interested in.

[14:14:39] <rajith> chirino: hey any changes btw now and friday that I should be aware of? I'm getting things started on my end … so just wanted to check

[14:15:09] <rajith> chirino: did you and robbie work out any changes to what you were u doing?

[14:26:50] <chirino> rajith: nope

[14:26:58] <chirino> rajith: it's all quiet

[14:27:33] <purplefox> rajith: sorry, back now

[14:27:35] <chirino> think robbie was just going to look into a perf bug

[14:27:36] <rajith> chirino: I'll bug if I hit issues

[14:27:43] <rajith> chirino: gotcha

[14:27:50] <rajith> purplefox: no worries

[14:28:17] <chirino> purplefox: any thoughts on ?

[14:28:20] <purplefox> rajith: there is no way to know this, but I think it's fine for the user to just configure what addresses they are interested in

[14:29:08] <purplefox> chirino: sorry haven't looked yet. but we have to be careful with changing core interfaces - we can't introduce breaking changes to public apis in minor releases

[14:29:21] <rajith> purplefox: there is some interest .. or dare I say a request (from Ted) to see if we can do this … this would be zero config on the address thing

[14:30:04] <chirino> purplefox: I get it. Note that the interfaces don't actually change. Did not change or add methods

[14:30:22] <chirino> just kinda moved them a bit in the inheritance tree

[14:30:33] <purplefox> rajith: maybe we can think about that as a feature further down the road

[14:31:02] <rajith> purplefox: +1 … I just wanted to mention that to you so it's at the back of your mind

[14:32:23] <purplefox> but maybe in amqp you could do wildcard subscriptions to consume from many addresses?

[14:32:38] <purplefox> so if you map vert.x address “foo.*” to amqp addresses “bar.*”

[14:32:55] <purplefox> then you can create an amqp consumer for bar.* and then forward received messages to the Vert.x address

[14:40:00] <rajith> purplefox: (09:32:38 AM) purplefox: so if you map vert.x address “foo.*” to amqp addresses “bar.*” — this is exactly what I did with whats already there :D

[14:40:44] <rajith> purplefox: so we could start there … but think about getting 'meta-events' about handler registration/deregistration down the line

[14:41:06] <purplefox> ah ok, you are ahead of the game already :)

[14:41:26] <purplefox> for future suggestions I suggest adding a github issue against the vertx-amqp project so we don't forget

[14:42:40] <rajith> purplefox: +1

[14:45:06] <rajith> purplefox: you mean ?

[14:45:18] <rajith> purplefox: that was what I plan to put the code under.

[14:46:44] <purplefox> yea that's the one

[14:47:11] <rajith> purplefox: cool

[15:21:06] <rajith> purplefox: once robbie (I think he already is) and tedross gets a chance to subscribe to the list, I will start the discussion there. Also I will create an issue for acks, flow control in the github project

[15:31:34] <tedross> rajith: I'm subscribed

[15:37:58] <rajith> tedross: cool .. I will do any new discussion through the list. Thx

[15:51:58] <purplefox> rajith: are you working on the initial-work branch here: ?

[15:52:18] <purplefox> can't see any commits

[15:54:42] <purplefox> am i looking in the wrong place?

[15:57:31] <rajith> purplefox: yes initial branch …. haven't committed anything yet. Look tmr morning

[15:57:42] <purplefox> ok ccol. thanks :)

[15:58:25] <rajith> purplefox: btw the eb_interceptor branch had 2 failures … I ignored that .. probably not critical .. just wanted to let u know

[16:05:16] <gemmellr> chirino: raised a PR (well, 2, oops :P) for that multiple async delivery issue

[16:06:43] <chirino> thx merged!

[18:20:20] <gemmellr> chirino: ping

[18:21:00] <chirino> pong

[18:22:00] <gemmellr> chirino:, in terms of the API I had a few things that might be worth discussing

[18:22:14] <chirino> ok. shoot

[18:22:49] <gemmellr> currently theres the 'settle' callback when using an async handler

[18:23:08] <chirino> yeah

[18:23:12] <gemmellr> would we perhaps want to expose the acept/reject/release functionality there?

[18:23:28] <chirino> so the delivery is given right?

[18:23:39] <chirino> you can set the disposition there no?

[18:23:48] <gemmellr> it is yeah…ok, i think i see where you were going there

[18:24:13] <chirino> I think I default the disposition to Accepted.

[18:24:19] <chirino> which could be debatable

[18:24:30] <gemmellr>, that kinda works…but only if we ensure no other threads process the transport while we are in the callback

[18:24:57] <chirino> I think vert.x does that for us, be we might need to double check with purplefox

[18:25:18] <gemmellr> actually, even the same thread will be an issue

[18:25:18] <chirino> oh in the async callback?

[18:25:47] <gemmellr> the states are for the most part 'outcomes', so you cant send one then send another..if a state is set and the transport gets processed, it will send a disposition with the state in it even if you might have wanted to wait and settle it at the same time

[18:26:00] <chirino> yeah so that might be a bad idea then

[18:26:33] <chirino> so perhaps we should only set accepted in the settle() callback if the disposition has not been set yet.

[18:26:57] <gemmellr> I added the concept of a 'default delivery state' to the delivery object in proton-j so you can set what it shoudl be set to if the message gets settled without a state being set first

[18:27:18] <gemmellr> the links already have this concept…but almost noone handles that correctly or sets it in the first place ;)

[18:28:37] <chirino> ok

[18:29:24] <gemmellr> so yeah…i was totally overlooking the delivery object exposing the disposition method, so much of what i was thinking there is moot ;)

[18:32:08] <gemmellr> the only other thing might be, i think purplefox was keen for credit handle to be hidden, e.g adding credit when you ack/nack….I guess its partly hidden behind the settle action…might it be worth having a default initial credit config (which can be overriden) so the flow call on the consumer isnt needed by default?

[18:32:26] <gemmellr> *credit handling

[18:33:14] <gemmellr> then the only time you would need it explicitly is if you want to issue new credit before ack/nack/settle of the earlier messages that have depleted your existing credit

[18:35:09] <gemmellr> saying that…might need a method to determine the current available credit…sort of matching the senders sendQueueFull method

[18:44:06] <gemmellr> if the connection object is going to have the 'default sender' based send(..) methods, we should probably hook that up to use the anonymous relay by detect the capability, using the appropriate Source etc, fail if it isnt supported…handling link-refusal is something we should do there too….this is mostly all impl rather than API though

[18:46:20] <gemmellr> chirino: another thing I wondered about that is API is whether the sender/receiver creation methods should take the target/source respectively in the creation call rather than needing a seperate setter to be used

[18:46:55] <gemmellr> having the setter might mean folks dont do it, or think they can change it later…

[18:47:27] <rajith> purplefox: ping

[18:48:28] <gemmellr> though i guess it does make things more symmetical on both types of links the way it is…which is useful in some ways (but perhaps not in others)

[18:49:00] <rajith> purplefox: it would be nice if SendContext has a method to denote whether it's a send vs a publish … bcos the treatment of it will be different on how the network routes it… Note that routing could happen outside of the vert.x.

[19:57:27] <rajith> purplefox: you around?

[19:58:17] <purplefox> rajith: hi

[19:59:08] <rajith> purplefox: this is not important for now … but just curious how the bridge will get it's config

[19:59:58] <purplefox> the convention is to use either an options class or a JsonObject

[20:00:10] <rajith> purplefox: I like the latter :)

[20:01:11] <rajith> purplefox: one more question. Lets say I want to deploy some verticles. So do you envision people will programatically deploy them for a particular vertx instance and then add the bridge as an interceptor .

[20:01:32] <rajith> purplefox: just curious to know as u have seen existing customer deployments out there

[20:05:02] <purplefox> not sure yet, maybe we can add them automatically using service loader

[20:05:25] <purplefox> i have to shoot now, but lets catch up again tomorrow

[20:05:39] <rajith> purplefox: sure

[20:05:44] <rajith> purplefox: have a good evening

[21:24:32] *** ChanServ sets mode: +o temporalfox