Approvals: 0/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 ?