[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 ?