Differences

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

Link to this comparison view

irc:1450306800 [2017/05/27 13:44]
irc:1450306800 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[00:15:44] <​temporalfox>​ AlexLehm ​ thanks I will have a look for sure
 +
 +[00:20:51] <​temporalfox>​ AlexLehm ​ I'm looking at the test, does it need Connection: keep-alive in the first request ?
 +
 +[00:20:54] <​temporalfox>​ with HTTP 1.1
 +
 +[00:36:50] <​AlexLehm>​ I think http 1.1 has connection keep-alive enabled implicitly
 +
 +[00:40:19] <​AlexLehm>​ when doing a request on apache, it contains Connection: keep-alive in the reply if it was in the request (then also a header Keep-Alive: timeout=5, max=100 is present), if the request does not contain Connection: keep-alivem the reply doesn'​t either
 +
 +[00:42:31] <​AlexLehm>​ doesn'​t change the behaviour, but i can take it out
 +
 +[01:03:06] <​temporalfox>​ AlexLehm I've taken your test
 +
 +[01:03:18] <​temporalfox>​ and use a reverted pr to implement a fix
 +
 +[01:03:30] <​temporalfox>​ I will also try to handle the case where the connection is closed without a close header
 +
 +[01:03:50] <​temporalfox>​ I think in this case the HttpClientRequest or Response gets an exception in the handler
 +
 +[01:04:53] <​temporalfox>​ in this case it hangs indeed
 +
 +[01:05:00] <​temporalfox>​ (just tested)
 +
 +[01:05:20] <​temporalfox>​ so this should be taken care of also if the connection is closed without a connection headers
 +
 +[01:05:25] <​temporalfox>​ which is not http_ish
 +
 +[01:05:33] <​temporalfox>​ but still happens :-)
 +
 +[01:05:39] <​temporalfox>​ I mean can happen
 +
 +[01:06:22] <​AlexLehm>​ actually, i think its a valid response for the server to just close the connection, IIS did that sometimes to do load balancing
 +
 +[01:06:31] <​AlexLehm>​ probably not with keep-alive though
 +
 +[01:07:00] <​temporalfox>​ ok
 +
 +[01:07:10] <​temporalfox>​ when this happen handleClosed() is called
 +
 +[01:07:15] <​temporalfox>​ but there is no life cycle happening
 +
 +[01:07:27] <​temporalfox>​ so if there are queued connection
 +
 +[01:07:47] <​temporalfox>​ but all connection are already busy
 +
 +[01:07:53] <​temporalfox>​ (like closed for instance)
 +
 +[01:08:05] <​temporalfox>​ then all these connection remain in the queue waiting
 +
 +[01:10:14] <​AlexLehm>​ ok
 +
 +[01:13:35] <​AlexLehm>​ that matches the issue described in the issue thread I think
 +
 +[01:24:29] <​temporalfox>​ actually this case should be taken care of
 +
 +[01:24:38] <​temporalfox>​ the handler was just called in the parent class
 +
 +[01:25:00] <​temporalfox>​ so if we have 11 connections with a pool of 5 and close on 2nd request like in your case
 +
 +[01:25:02] <​temporalfox>​ without a close header
 +
 +[01:25:08] <​temporalfox>​ the 10 first requests work fine
 +
 +[01:25:19] <​temporalfox>​ and the 11th gets the exception handler called
 +
 +[01:25:34] <​temporalfox>​ because the requests is queued but the connection is closed before it makes the request
 +
 +[01:27:13] <​temporalfox>​ I will push a branch so the azhuchkov can try
 +
 +[08:47:30] <​aesteve>​ hi everyone :)
 +
 +[10:42:39] <​temporalfox>​ hi arnaud
 +
 +[10:43:01] <​aesteve>​ hi julien, how was the meetup ? :)
 +
 +[12:09:51] <​csoop>​ Hi everybody!
 +
 +[12:11:57] <​csoop>​ I am new to Vert.X, could anybody give me a pointer to do content negotiation properly in Vert.X Web? Something similar to what you find in JAXB and JAXRS, where a DTO is marshalled to the Content-Type matching the HTTP Accept header
 +
 +[13:00:05] <​pmlopes>​ hi @csoop vert.x internally uses jackson for json serialization it can also do xml serialization if i recall correctly, so in your content negotiation you can use it to serialize as you like
 +
 +[13:03:50] <​pmlopes>​ https://​paste.gnome.org/​piqibv4rv
 +
 +[14:19:42] <​csoop>​ @pmlopes Thanks for the reply - Yes that is correct my question is really how you configure content negotiation and make sure Vertex understands what type to return
 +
 +[14:20:09] <​aesteve>​ Vert.x doesn'​t '​understand',​ it's unopiniated
 +
 +[14:20:14] <​aesteve>​ you have to write the code
 +
 +[14:20:59] <​aesteve>​ within the RoutingContext you have the content-negociation information : http://​vertx.io/​docs/​apidocs/​io/​vertx/​ext/​web/​RoutingContext.html#​getAcceptableContentType--
 +
 +[14:21:00] <​csoop>​ OK, so there is no support for content negotiation?​
 +
 +[14:21:21] <​aesteve>​ then you have to marshall the DTO according to the "​bestContentType"​
 +
 +[14:21:58] <​aesteve>​ so yes, there is content negociation,​ but no, vert.x doesn'​t "​marashall"​ the DTOs for you
 +
 +[14:22:14] <​csoop>​ OK, so there is nothing that matches the JAXR's annotations and I can't just return a DTO that will be marshalled by Vert.X Web
 +
 +[14:22:45] <​csoop>​ You might be forgiving to think there could be a handler, filter or similar that would help with it.
 +
 +[14:23:00] <​csoop>​ And yes, I could write it myself... :-)
 +
 +[14:23:34] <​aesteve>​ have a look there : https://​github.com/​vert-x3/​vertx-awesome
 +
 +[14:23:52] <​aesteve>​ a lot of ppl have worked to propose implementations
 +
 +[14:24:06] <​aesteve>​ (unofficial implementations)
 +
 +[14:24:58] <​aesteve>​ vertx-web must stay unopinionated and minimal I think, that's the role of the community to provide such "​marshallers"​ like JAX-RS, Spring MVC, RESTeasy etc. do
 +
 +[14:24:59] <​csoop>​ thanks!
 +
 +[14:25:23] <​csoop>​ (for the link - funny I did not see the JAXRs implementation)
 +
 +[14:27:26] <​aesteve>​ you'll notice how close RestVertx, Vertx Jersey, QBit and Nubes are, actually. That's almost the same approach
 +
 +[14:29:14] <​csoop>​ ok
 +
 +[14:29:26] <​csoop>​ *looking*
 +
 +[14:32:33] <​csoop>​ yes, they are similar
 +
 +[15:05:35] <​aesteve>​ temporalfox:​ one day we should discuss the vertx-service-registry
 +
 +[15:05:45] <​aesteve>​ that'd be cool in addition to vertx-awesome
 +
 +[15:05:51] <​temporalfox>​ is there one ?
 +
 +[15:05:57] <​aesteve>​ no :(
 +
 +[15:05:59] <​temporalfox>​ ah ok
 +
 +[15:06:07] <​temporalfox>​ there should be one using DNS ?
 +
 +[15:06:48] <​aesteve>​ we ended up not doing it because we add issues "​tagging"​ the projects in maven central dependening on vertx-core, remember ?
 +
 +[15:07:23] <​temporalfox>​ ahhhh
 +
 +[15:07:32] <​temporalfox>​ so it would rather be I think disocvery of vertx things
 +
 +[15:07:44] <​aesteve>​ yes I named it wrong
 +
 +[15:07:49] <​temporalfox>​ it is hard to come with something like that
 +
 +[15:08:44] <​aesteve>​ npm has the notion of "every github project can be a npm repository"​ which is kinda cool
 +
 +[15:09:03] <​aesteve>​ but yes it's hard to come, but that'd be a cool addition I guess
 +
 +[15:10:18] <​temporalfox>​ well we can have too :-)
 +
 +[15:10:26] <​temporalfox>​ one can publish a maven repository
 +
 +[15:10:30] <​temporalfox>​ with just files
 +
 +[15:10:41] <​temporalfox>​ but it means binaries somewhere
 +
 +[15:14:04] <​aesteve>​ yes
 +
 +[15:14:25] <​aesteve>​ discovering github projects using Vert.x sounds possible (using Github API)
 +
 +[15:15:12] <​aesteve>​ mavenCentral is gonna be almost impossible, bintray sounds possible, too
 +
 +[15:17:51] <​aesteve>​ https://​api.github.com/​search/​repositories?​q=vertx
 +
 +[15:17:53] <​temporalfox>​ ah github api
 +
 +[15:18:01] <​temporalfox>​ and why people then wouldn'​t just make a record ?
 +
 +[15:18:12] <​temporalfox>​ that points to maven central coordinates ?
 +
 +[15:18:16] <​temporalfox>​ with simple json ?
 +
 +[15:18:30] <​aesteve>​ what is a "​record"​ ? :\ sorry
 +
 +[15:18:37] <​temporalfox>​ a file
 +
 +[15:18:44] <​temporalfox>​ :)
 +
 +[15:18:58] <​temporalfox>​ this file then contains the coordinates
 +
 +[15:19:00] <​aesteve>​ is it something standard ? (ppl are used to)
 +
 +[15:19:06] <​temporalfox>​ json
 +
 +[15:19:10] <​temporalfox>​ have you seen the new stack manager in 3.2.0 ?
 +
 +[15:19:18] <​aesteve>​ yes json, but describing maven coordinates somewhere
 +
 +[15:19:24] <​temporalfox>​ in the json
 +
 +[15:19:31] <​aesteve>​ I'll have a look
 +
 +[15:19:59] <​temporalfox>​ { "​coordinates":​ "​mygroup:​myartifact:​myversion",​ ... }
 +
 +[15:20:17] <​temporalfox>​ the stack manager should have ability to modify the stack.json file
 +
 +[15:20:19] <​temporalfox>​ or other
 +
 +[15:20:32] <​temporalfox>​ like we could have a command to list stuff using the CLI ext
 +
 +[15:20:38] <​temporalfox>​ and install them
 +
 +[15:20:41] <​temporalfox>​ which means
 +
 +[15:20:53] <​temporalfox>​ 1/ modify stack.json with the installed file
 +
 +[15:21:05] <​temporalfox>​ 2/ trigger the stack manager to "​resolve"​ it
 +
 +[15:21:07] <​temporalfox>​ or
 +
 +[15:21:20] <​temporalfox>​ 1/ modify stack.json and call stack manager resolve at the same time
 +
 +[15:21:31] <​temporalfox>​ something like
 +
 +[15:21:43] <​temporalfox>​ vertx install GAV
 +
 +[15:21:58] <​temporalfox>​ vertx install "​name"​
 +
 +[15:22:10] <​temporalfox>​ and the name is resolved from what is found on github using this format
 +
 +[15:22:18] <​aesteve>​ when you think about stack manager I'm thinking about a website listing Vert.x projects
 +
 +[15:22:29] <​temporalfox>​ ah ok
 +
 +[15:22:39] <​aesteve>​ that's kinda fun actually, but OK that's a good use case, too
 +
 +[15:22:40] <​temporalfox>​ both are actually good
 +
 +[15:23:05] <​temporalfox>​ what would be nice is to rahnk project by github stars
 +
 +[15:23:08] <​aesteve>​ and especially, both can rely on the same '​resolution service'​
 +
 +[15:23:53] <​aesteve>​ https://​api.github.com/​search/​repositories?​q=vertx&​sort=stars
 +
 +[15:24:20] <​aesteve>​ problem is the '​q='​ which is not very reliable :\
 +
 +[15:43:51] <​temporalfox>​ why it's not reliable ?
 +
 +[15:44:42] <​aesteve>​ because we don't really know on which criteria Github relies, so we might be missing some repos, don't you think ?
 +
 +[16:09:50] <​temporalfox>​ we need to try :-)
 +
 +[16:22:44] <​aesteve>​ I can setup a small web project this weekend
 +
 +[20:57:43] *** ChanServ sets mode: +o temporalfox
 +
 +[22:23:16] <​Pluto>​ Hi! I am making a pilot project with vert.x and I awould like to ask for help or example code to use with EventBus
 +
 +[22:40:41] *** ChanServ sets mode: +o temporalfox
 +
 +[22:44:31] <​aesteve>​ temporalfox:​ I think I got something working for the "​vertx-sync-like"​ stuff :)
 +
 +[22:44:46] <​aesteve>​ (with AST transformations)
 +
 +[22:45:17] <​aesteve>​ here it is https://​github.com/​aesteve/​vertx-groovy-sugar/​blob/​master/​src/​main/​groovy/​com/​github/​aesteve/​vertx/​groovy/​promise/​PromiseTransformation.groovy
 +
 +[22:45:40] <​aesteve>​ (I named it "​promise"​ but it could be anything)
 +
 +[22:45:58] <​aesteve>​ what it does is :
 +
 +[22:46:50] <​aesteve>​ inspect every method, if the last parameter is a handler, it creates a new method with only the other parameters
 +
 +[22:47:21] <​aesteve>​ this new method will return a CurriedClosure (binded method) from the specified parameters
 +
 +[22:47:55] <​aesteve>​ now we're free to call this curried closure with the Handler of our choice
 +
 +[22:48:36] <​aesteve>​ for example, on the "​Promise"​ class, we could add a "​onFail"​ method, etc.
 +
 +[23:34:28] <​temporalfox>​ looks nice but is it sync ?