Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1445464800 [2017/05/27 13:44] (current)
Line 1: Line 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: https://​github.com/​vert-x3/​vertx-examples/​blob/​master/​core-examples/​src/​main/​java/​io/​vertx/​example/​core/​http/​simple/​Server.java
 +
 +[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 https://​github.com/​vert-x3/​vertx-examples/​blob/​master/​core-examples/​src/​main/​java/​io/​vertx/​example/​core/​http/​sharing/​Server.java
 +
 +[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: http://​docs.oasis-open.org/​amqp/​core/​v1.0/​os/​amqp-core-transport-v1.0-os.html#​type-transfer
 +
 +[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 ..delivery.settle()
 +
 +[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] *** sendak.freenode.net 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 https://​github.com/​vert-x3/​vertx-proton/​tree/​initial-work 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 https://​github.com/​vert-x3/​vertx-proton/​blob/​initial-work/​src/​test/​java/​io/​vertx/​proton/​example/​HelloWorld.java#​L51
 +
 +[22:09:23] <​chirino>​ you we add data handlers to the delivery object kinda like http://​vertx.io/​docs/​apidocs/​io/​vertx/​core/​http/​HttpServerRequest.html#​bodyHandler-io.vertx.core.Handler-
 +
 +[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: https://​github.com/​apache/​qpid-proton/​blob/​master/​proton-j/​src/​main/​java/​org/​apache/​qpid/​proton/​codec/​transport/​BeginType.java
 +
 +[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