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

[00:11:17] * ChanServ sets mode: +o temporalfox [11:24:10] <kislo_metal> Hi all [11:24:29] <Sticky_> yo [11:26:32] <kislo_metal> I a just started to use vertx. I faced with an issue related to deploying of more than 2 verticle with http server. [11:27:48] <kislo_metal> I see that both verticle get to start methods and call it, but look like I do not understand how the vertx.createHttpServer should work. [11:28:34] <kislo_metal> maybe someone has useful link)? (I did google it) [11:30:34] <purplefox> kislo_metal: take a look the examples repository [11:31:25] <Sticky_> also, are you trying to create 2 http servers and bind the same port twice? [11:32:41] <kislo_metal> I did looked at examples, but did not seen same case. [11:34:23] <kislo_metal> 2 http server - sure I did that , I suppose mistake , at the start. Looks like the second http server will be alive. Did not seen clear statement about this anywhere .. [11:35:57] <kislo_metal> So, right now I have separate VertxVertucleMain, where I am trying to vertx.deployVerticle(SoleClass.class, new DeploymentOptions); [11:38:08] <kislo_metal> with this configuration I create one http server in mane, and deploy all vertices there, but The routs from the deployed Verticles does not work. [11:38:12] <purplefox> kislo_metal: i'm not sure i understand what you're trying to do [11:40:11] <kislo_metal> I want 2 deploy 2 Verticle. Each should work on same host:port. [11:41:26] <kislo_metal> http server should be created outside those Verticle, is it correct? [11:41:31] <purplefox> you can either deploy them programmatically or specify number of instances at command line [11:42:04] <purplefox> simple http example is here: [11:42:24] <purplefox> if you want 2, just deploy 2 of them [11:42:28] <purplefox> if you want 4, deploy 4 [11:42:29] <purplefox> etc [11:43:10] <purplefox> example of programmatic deployment is here [11:43:26] <purplefox> but you can also just deploy multiple at command line so don't really need that [11:45:38] <kislo_metal> in case command line deployment - http servers created inside of Vertices should work just fine, right? [11:45:50] <purplefox> yes [11:46:45] <kislo_metal> ok, I will try command line approach. thank you. [11:47:24] <purplefox> command line is no different from programmatic [11:47:27] <purplefox> they both should work [11:48:06] <purplefox> command line is just deploying N instances exactly the same as if you did it programmatically [12:36:37] <kislo_metal> <Sticky_> also, are you trying to create 2 http servers and bind the same port twice? [12:37:15] <kislo_metal> ←- is it actually valid for vertx ? [13:52:53] * ChanServ sets mode: +o temporalfox

[14:09:39] * ChanServ sets mode: +o temporalfox [14:32:11] * ChanServ sets mode: +o temporalfox

[15:34:14] <chirino> purplefox: morning!

[15:43:41] <chirino> rajith: ping

[15:57:39] <rajith> chirino: pong

[16:00:39] <chirino> you familiar with the receiver mode = second messaging pattern?

[16:01:05] <chirino> seems like that's how you might do once and only once qos, but I'm not sure

[16:02:19] <chirino> kinda wondering if we can boil down the sender/receiver modes things down to a more descriptive enum.

[16:03:08] <chirino> kinda like sender.setQoS(QoS.ONCE_AND_ONLY_ONCE)

[16:05:34] <gemmellr> chirino: thats exactly what it is for

[16:05:42] <gemmellr> 'second'

[16:06:12] <chirino> so when it is second, what do we have to do on the proton api?

[16:06:14] <rajith> chirino: yes as gemmellr confirmed

[16:07:43] <gemmellr> chirino: the reciever waits until the sender settles, then they settle

[16:08:09] <gemmellr> chirino: so you decouple the disposition update (i.e accepted) from the settle…wait for the other side to settle first

[16:08:11] <chirino> so what does the sender wait for?

[16:08:22] <chirino> ok so the receiver set Accepted

[16:08:29] <rajith> chirino: so the receiver knows that the sender is not going to send again

[16:08:31] <chirino> then the sender sees that and sets settled?

[16:08:45] <rajith> chirino: the 3-way-ack

[16:08:55] <rajith> chirino: yes

[16:09:02] <chirino> ok

[16:09:10] <gemmellr> chirino: described at:

[16:09:45] <chirino> but this is stuff the user of the proton api has to do right? It's not automatic

[16:09:49] <rajith> gemmellr: hey robbie did they finalize the amqp-jms mapping ? I never followed it.

[16:09:56] <rajith> chirino: yes

[16:10:10] <gemmellr> chirino: if sending the message, you wait for the other side to accept (but not settle)., then you settle, then they settle

[16:10:24] <chirino> ok

[16:11:32] <gemmellr> once you see they settled, you know it got there…this is where link-recovery would come in if things were to be interupted inbetween….but proton (-j at least) doesnt yet really support that

[16:12:03] <gemmellr> rajith: no it isnt finalised..still plenty to do

[16:12:06] <rajith> gemmellr: proton-c doesn't either ..

[16:12:13] <rajith> gemmellr: have fun :p

[16:15:57] <rajith> chirino: receiver side .. if (delivery.remotelySettled() && link.getReceiverSettleMode() == ReceiverSettleMode.SECOND) then

[16:16:33] <chirino> so if local and remote sender/receiver settle modes don't match

[16:16:34] <rajith> chirino: sender side, check for the disposition if the delivery is updated and then settle if the receiving side is going to settle second.

[16:16:39] <chirino> which are you supposed to honor?

[16:17:34] <rajith> chirino: if I'm not mistaken when someone creates a link into your node, you could throw an exception if it doesn't match your expectations

[16:17:51] <rajith> chirino: bcos those modes are specified when the link is created

[16:18:16] <rajith> gemmellr: can you confirm if the above is the correct practice ? ^^

[16:18:53] <rajith> chirino: robbie participates in the jms mapping TC, so these things would have been discussed.

[16:19:16] <rajith> chirino: I'm just going by the notes I made after conversations with Rafi

[16:20:11] <rajith> chirino: for behavior (or interpretation of the spec) gemmellr is a better source as he's more involved in the spec than I am.

[16:20:26] <chirino> so the side receiving the link request needs to honor the remote settings or else set an error condition?

[16:20:44] <chirino> so basically he has to set his remote bits to match?

[16:21:05] <rajith> chirino: I'm guessing … if someone wants to come into my house with conditions I can meet … then I have the right to refuse their advance :p

[16:21:26] <rajith> chirino: I *can't*

[16:21:40] <chirino> so if they don't match I can consider that an error too?

[16:21:57] <rajith> chirino: let me double check with Gordon .. looks like robbie stepped out for a bit

[16:22:01] <gemmellr> chirino: essentially the remotes details tend to be what are in effect

[16:22:38] <rajith> gemmellr: can we not throw an error if I get a link with options that I don't support ?

[16:22:43] <gemmellr> when you attach etc, you ask for what you want…the reply should say what actually occurs

[16:23:08] <chirino> so you might get a silent downgrade?

[16:23:11] <gemmellr> rajith: you can certainly refuse the link if you want to yes

[16:23:27] <rajith> gemmellr: I think thats better than doing a silent downgrade

[16:23:36] <gemmellr> chirino: possible, yep

[16:23:55] <gemmellr> rajith: wasnt saying it isnt… :)

[16:24:07] <chirino> k

[16:24:14] <chirino> making more sense

[16:24:42] <rajith> gemmellr: :)

[16:24:55] <chirino> what does SenderSettleMode.MIXED do?

[16:24:58] <gemmellr> note that refusing a link still involves attaching it (with whichever details you like) then immediately detaching/closing it :)

[16:25:09] <chirino> I think I get UNSETTLED, SETTLED :)

[16:25:23] <gemmellr> chirino: means you can send things settled or unsettled, rather than jsut one or the other

[16:25:28] <chirino> is SenderSettleMode.MIXED used with SECOND?

[16:25:37] <chirino> oh

[16:26:06] <gemmellr> mixed and second wouldnt make much sense…but im not sure if its ruled out :)

[17:50:30] * sets mode: +o purplefox [20:42:02] * ChanServ sets mode: +o purplefox

[21:52:53] * ChanServ sets mode: +o purplefox [22:04:58] <chirino> rajith: I think the public api at is in about the right shape now. [22:05:05] <chirino> if you get a chance could you review it? [22:06:56] <chirino> rajith: One thing I've been pondering is supporting delivery streaming [22:07:29] <chirino> so that if your moving large blobs around, instead of doing [22:09:23] <chirino> you we add data handlers to the delivery object kinda like [22:20:44] * ChanServ sets mode: +o purplefox

[22:30:06] <AlexLehm> purplefox: i have written a unit test for the timer issue in 3.2, should the test be included in the PR for the fix?

[23:38:16] <rajith> chirino: hey Hiram

[23:38:28] <chirino> hey

[23:38:50] <rajith> chirino: to do delivery streaming we need to have support for that in proton

[23:39:09] <rajith> chirino: for example allowing multiple data sections in a transfer

[23:39:24] <chirino> ok.

[23:39:45] <chirino> so no point in doing that now?

[23:40:27] <rajith> chirino: I'm doing some codec improvements at the moment and have investigated this. Hopefully I get that into a branch late next week

[23:40:51] <rajith> chirino: yea lets revisit that when proton supports it

[23:40:53] <chirino> so it would be nice if you coudl message encode directly to the link

[23:41:16] <chirino> instead of of copying into a intermediate buffer.

[23:41:17] <rajith> chirino: unless we by pass the current message abstraction in proton and do that ourselves

[23:41:37] <rajith> chirino: yea proton-j sucks with the extra copying

[23:42:06] <rajith> chirino: even the codec … the new codec is somewhat better but still have a major flow

[23:42:15] <rajith> flaw

[23:42:47] <chirino> I added some benchmarks to the the project too

[23:42:53] <chirino> perf is not really that greate

[23:43:27] <rajith> chirino: yea perf is not that great … one reason for the new codec work is perf improvements

[23:43:38] <chirino> cool

[23:43:48] <chirino> one day it would be nice if we had link recovery too :)

[23:43:55] <chirino> so much work to do!

[23:44:13] <rajith> chirino: btw I will not have time to look your code in detail tonight and I'm away until mid day tmr…. robbie will have a look in the meantime

[23:44:25] <rajith> chirino: yea even proton-c doesn't do it

[23:44:46] <rajith> chirino: btw what u have done is nice & compact … I did look at it briefly

[23:44:51] <chirino> I mean that is one of the biggest reasons folks use messaging instead of http

[23:45:37] <rajith> chirino: even with 0.9 version we never implemented recovery properly …. supposedly bcos the protocol didn't have enough support

[23:46:05] <rajith> chirino: but then again we still haven't gotten to it yet with 1.0 impl either :p

[23:49:28] <chirino> rajith: in terms of buffer handling netty is one of those projects that has the best buffer handling impls, perhpas you should peek at it and take some inspiration.

[23:49:54] <chirino> they do things like buffer passing and pooling

[23:49:57] <rajith> chirino: norman was going to help with that …. then unfortunately he moved :(

[23:50:01] <chirino> instead of buffer coying

[23:50:18] <chirino> copying

[23:50:39] <rajith> chirino: yea buffer management is one area that needs improvement

[23:51:13] <rajith> chirino: however my next biggest target is a real issue with even the new decoder … we create a lot of interim List objects. If u run it under a profiler you'll see this

[23:52:14] <rajith> chirino: I need to figure out a way to avoid that…. Originally Rafi was going to modify his decoder to help with that …however Rafi hasn't been that active, so I have to look into it.

[23:52:34] <chirino> got an example of where you create one of those?

[23:53:47] <rajith> chirino:

[23:54:02] <rajith> chirino: look at the public Begin newInstance(Object described) … line 118

[23:54:13] <rajith> chirino: it's given a list object

[23:54:43] <rajith> chirino: bcos AMQP peformatives are encoded as lists, most decoders takes the easy route and present it as a list

[23:55:31] <rajith> chirino: instead if we can pull those fields individually from a decoder or data handler then we can avoid creating a list, shoving the data in that and then passing it

[23:55:48] <chirino> k

[23:56:11] <chirino> are these files hand written?

[23:57:15] <rajith> chirino: I thought they were generated … anyways the new performatives I wrote are handwritten so I was atleast able to cut out the bloat and make it more compact

[23:57:25] <chirino> k

[23:57:57] <rajith> chirino: code gen is a cool idea … but more often than not results in bloated code

[23:58:17] <chirino> yeah

[23:58:56] <rajith> chirino: anyways feel free to work with robbie tomorrow to improve the api work you did … most likely I will be out until lunch

[23:59:04] <chirino> k

[23:59:43] <rajith> chirino: I'll link up with you on monday morning as I hope start the work during the weekend and I will have feedback/bugs when I start using it for the bridge