Differences

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

Link to this comparison view

irc:1433800800 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[08:57:24] <​pmlopes>​ temporalfox:​ did you work on the proxy generator?
 +
 +[08:57:44] <​temporalfox>​ pmlopes not much, I can try to help though
 +
 +[08:59:22] <​pmlopes>​ i am porting the old examples to the new api but i found a problem with the proxy generated code. the proxy generates json messages with headers while the vertxbus.js does not have this feature (at least the js that already was on the examples)
 +
 +[09:00:37] <​temporalfox>​ so basically you want to use an event bus proxy from the browser via the bridge
 +
 +[09:02:16] <​pmlopes>​ yes that is the case the old real time angular js app demonstrated
 +
 +[09:02:43] <​pmlopes>​ so i can update the vertxbus.js to support that but i will introduce a API change on the vertxbus.js client
 +
 +[09:02:50] <​temporalfox>​ I think indeed we have an "​hole"​ there
 +
 +[09:03:12] <​temporalfox>​ and I think that message headers make that a bit more low level to use
 +
 +[09:03:18] <​temporalfox>​ I mean manually
 +
 +[09:03:42] <​temporalfox>​ one thing we could consider is to generate javascript clients too
 +
 +[09:03:56] <​temporalfox>​ but we would still miss message headers
 +
 +[09:04:16] <​pmlopes>​ however this is not all... the sockjs handler allows filtering all incoming/​outgoing messages and once I move the action out of the body into the header then i cannot filter by action, or i need to duplicate the property both in the body and header which makes it confusing imo
 +
 +[09:05:23] <​temporalfox>​ you mean that we should be able also to filter according to headers
 +
 +[09:05:31] <​pmlopes>​ i can update the vertxbus.js to have the headers argument as optional so it won't break existing code so i can make it a client only fix
 +
 +[09:05:57] <​temporalfox>​ do we have today headers in vertxbus.js ?
 +
 +[09:06:09] <​temporalfox>​ you said it does not have this feature
 +
 +[09:06:47] <​pmlopes>​ vertxbus.js does not have headers and should be added otherwise i cannot send messages to the jvm event bus
 +
 +[09:06:58] <​temporalfox>​ right
 +
 +[09:07:08] <​temporalfox>​ I think at least we can add headers to vertxbus.js
 +
 +[09:07:23] <​pmlopes>​ regarding to filtering in the example app we want to filter all messages to mongo and only allow "​find"​ action, however the match only applies to the message body
 +
 +[09:07:38] <​temporalfox>​ and routing is done via headers
 +
 +[09:07:41] <​temporalfox>​ right ?
 +
 +[09:07:53] <​pmlopes>​ ok, so i will add the headers to the vertxbus.js
 +
 +[09:08:32] <​temporalfox>​ with the "​action"​
 +
 +[09:08:34] <​pmlopes>​ yes the routing depends on the headers it expects a message like: {address: "​xxx",​ headers: {action: "​find"​},​ body: {}}
 +
 +[09:08:45] <​temporalfox>​ let's first add headers to vertxbus.js
 +
 +[09:08:49] <​pmlopes>​ but the filtering only parses message.body
 +
 +[09:08:53] <​temporalfox>​ I believe it's not too hard
 +
 +[09:09:04] <​temporalfox>​ then probably we can also add filtering via actions
 +
 +[09:09:18] <​temporalfox>​ both don't seem overcomplicated to do
 +
 +[09:09:26] <​temporalfox>​ as long as it is well tested and documented
 +
 +[09:09:30] <​temporalfox>​ wdyt ?
 +
 +[09:09:31] <​pmlopes>​ no, but introduce new APIs :)
 +
 +[09:09:44] <​pmlopes>​ i'll update those them
 +
 +[09:09:44] <​temporalfox>​ yeah...
 +
 +[09:09:45] <​pmlopes>​ then
 +
 +[09:09:57] <​temporalfox>​ it's not really new APIs per se
 +
 +[09:10:23] <​temporalfox>​ it's more lacks of methods in the API that makes this feature not usable
 +
 +[09:11:16] <​temporalfox>​ how much work do you think it requires ?
 +
 +[09:21:40] <​purplefox>​ temporalfox:​ pmlopes: I'm not sure I follow the issue about headers....
 +
 +[09:23:58] <​pmlopes>​ the case is like this: i deploy the mongo service and from the web i send the message: {address: "​vertx.mongo",​ body: {action: "​find",​ selector: {}}} or something like that but then once the bridge tries to forward the message to mongo it fails at the proxy because the proxy tries to get the action from the message header and not the body
 +
 +[09:24:40] <​pmlopes>​ it expected the message to be: {address: "​vertx.mongo",​ header: {action: find} body: {selector: {}}}
 +
 +[09:25:14] <​purplefox>​ ah i see
 +
 +[09:25:33] <​purplefox>​ so you want to call an event bus service directly from client side
 +
 +[09:26:06] <​pmlopes>​ yes, that is what vtunes was doing ob vertx2
 +
 +[09:26:19] <​pmlopes>​ i am porting that example to v3
 +
 +[09:26:37] <​purplefox>​ right, in V3 we recently downplayed the important of proxy services in favoir of clients
 +
 +[09:26:53] <​purplefox>​ so you'll notice we renamed a lot of things from service to client
 +
 +[09:26:58] <​purplefox>​ e.g. mongo, redis, jdbc etc
 +
 +[09:27:34] <​purplefox>​ so I'm not sure it makes sense to port the V2 app _directlty_
 +
 +[09:27:50] <​pmlopes>​ so what does that mean? should i register my own handler on the jvm side and then call the client?
 +
 +[09:28:00] <​pmlopes>​ and drop the mongo-service
 +
 +[09:28:06] <​purplefox>​ pmlopes: yeah, i'd say that would be a more V3 way of doing it
 +
 +[09:28:24] <​pmlopes>​ ok, then there is no need to "​fix"​ vertxbus.js
 +
 +[09:28:26] <​purplefox>​ so basically receive eventbus messages in your verticle, and then call a local client
 +
 +[09:28:33] <​pmlopes>​ ok, will do
 +
 +[09:28:45] <​purplefox>​ we should really fix vertxbus.js too, but it's not so important
 +
 +[09:28:50] <​purplefox>​ i think it should support headers
 +
 +[09:28:54] <​purplefox>​ and it would be easy to do
 +
 +[09:29:20] <​purplefox>​ you can already add headers in the eventbusbridge event handlers
 +
 +[09:29:30] <​purplefox>​ so all we need to do is add a little bit of json:
 +
 +[09:29:54] <​purplefox>​ "​headers":​ {"​header1":"​val1",​ "​header2":"​val2"​}
 +
 +[09:29:58] <​purplefox>​ when sending from client
 +
 +[09:30:12] <​purplefox>​ in the message
 +
 +[09:30:24] <​purplefox>​ it's probaby just a few lines of code change in vertxbus.js
 +
 +[09:30:51] <​pmlopes>​ yes
 +
 +[09:33:39] <​purplefox>​ actually... after 3.0 we should probably make a completely new version of vertxbus.js that looks more like the current eventbus interface
 +
 +[09:33:48] <​purplefox>​ or even generate it using codegen
 +
 +[09:34:01] <​purplefox>​ but that's more work
 +
 +[10:01:28] <​andyhedges>​ Hi all, I'm wondering, with a call back is there an easy way to know which context and/or thread it's going to run on?
 +
 +[10:01:41] <​andyhedges>​ It's caught me out a few times making the wrong assumption
 +
 +[10:02:59] <​andyhedges>​ Oh and a completely unrelated question, I want to do a Lunch & Learn on vertx at work and was wondering if anyone had some good material, want to keep it in the code as much as is possible.
 +
 +[10:07:31] <​purplefox>​ andyhedges: it will run on the same context as the thread that set the handler
 +
 +[10:08:05] <​purplefox>​ andyhedges: so basically all the handlers for a verticle will run with the same context
 +
 +[10:08:09] <​purplefox>​ which makes things very simple
 +
 +[10:08:17] <​purplefox>​ as it basically makes your verticle single threaded
 +
 +[10:08:32] <​purplefox>​ so in most cases you shouldn'​t have to worry about it
 +
 +[10:12:47] <​purplefox>​ andyhedges: do you have an example where it has caught you out?
 +
 +[10:51:39] <​aesteve>​ idk if anyone else had trouble with that, but I got an issue with template engines and prefixes
 +
 +[10:52:16] <​aesteve>​ and I found myself writing this kind of stuff : https://​github.com/​aesteve/​vertx-nubes/​blob/​master/​src/​main/​java/​io/​vertx/​nubes/​views/​impl/​PrefixedHandlebarsTemplateEngineImpl.java
 +
 +[10:52:45] <​aesteve>​ especially : https://​github.com/​aesteve/​vertx-nubes/​blob/​master/​src/​main/​java/​io/​vertx/​nubes/​views/​impl/​PrefixedHandlebarsTemplateEngineImpl.java#​L74
 +
 +[12:45:52] <​purplefox>​ hi pmlopes
 +
 +[12:46:10] <​purplefox>​ just looking at https://​github.com/​vert-x3/​vertx-examples/​pull/​39
 +
 +[12:46:13] <​purplefox>​ looks good
 +
 +[12:46:54] <​purplefox>​ i'm not sure I have understood the issue with auth though, could you elaborate a bit?
 +
 +[13:01:48] <​pmlopes>​ purplefox: so i was trying to just use the bridge permittedoptions.requiredAuthority = "​vtoons",​ however the sockjs.webUser is always null, from what i've understood that value is grabbed from the routing context. Now from the handlers i cannot get a reference to the routing context so uppon login i cannot set the user object...
 +
 +[13:03:24] <​purplefox>​ i think we have tests for this in EventBusBridgeTest
 +
 +[13:03:29] <​purplefox>​ or at least.. we should do
 +
 +[13:04:35] <​pmlopes>​ i did look and could not find anything
 +
 +[13:04:51] <​purplefox>​ you should be able to provide handlers for auth just like any other vertx-web app
 +
 +[13:05:02] <​purplefox>​ i guess I am not understanding the issue properly
 +
 +[13:06:01] <​purplefox>​ ok. take a look at EventBusBridgeTest.testSendRequiresAuthorityHasAuthority
 +
 +[13:06:11] <​purplefox>​ this uses auth handlers to set up the user
 +
 +[13:07:30] <​purplefox>​ so you should just be able to use whatever authhandler you want
 +
 +[13:08:33] <​pmlopes>​ ok thanks
 +
 +[13:38:50] <​pmlopes>​ purplefox, it does not work, the test expects that the login happens before any request to /​eventbus/​*,​ since this is a websocket, it is open at start and stays open after that. What happens with the vtunes example is that at start a ws request is done to request all albums and this is public call so no need to authenticate,​ therefore the handler will always be bound to no user. After that I call the login but since the ws was already open the
 +
 +[13:38:50] <​pmlopes>​ handler that would now validate the request will not be called. The same applies for a eventual logout from a ws, since the webSession and webUser are read only and there is no routingContext available it cannot be done, it always need to be done over HTTP
 +
 +[13:40:13] <​pmlopes>​ in order to use the bridge security i think it can only be done using 2 bridges one public and another where client only connect after althenticating this ways we can use the authorities check
 +
 +[13:40:20] <​purplefox>​ if you protect the page that is served at the beginning then login can be done at that point
 +
 +[13:41:10] <​pmlopes>​ yes, it can but i assume for this example even without authentication you might want to get realtime albums updates
 +
 +[13:44:24] <​purplefox>​ i guess you could use two bridges if you wanted, but in this case i think a simple solution is just to require login for everything
 +
 +[13:46:00] <​pmlopes>​ sure, it is simple enough
 +
 +[13:46:42] <​pmlopes>​ i guess for post 3.0 we should revisit the sock bridge and make it possible to update the current webUser and webSession
 +
 +[13:49:57] <​aesteve>​ purplefox: if you're looking at examples, do you want me to submit https://​github.com/​aesteve/​vertx-feeds
 +
 +[13:50:09] <​aesteve>​ or is it too high-level (like there'​s too much stuff in it)
 +
 +[14:17:19] <​purplefox>​ pmlopes: +1
 +
 +[15:29:38] <​purplefox>​ aesteve: sorry, i just haven'​t had a chance to take a proper look at your example yet :(
 +
 +[15:30:34] <​aesteve>​ np :) bookmark it somewhere so you can review it once you have some free time (in a galaxy far far away maybe)
 +
 +[16:01:38] <​pmlopes>​ purplefox, temporalfox,​ cescoffier: all web examples are in or as a pull request!
 +
 +[16:01:53] <​temporalfox>​ hum ?
 +
 +[16:02:09] <​temporalfox>​ how are you doing :-) ?
 +
 +[16:02:14] <​cescoffier>​ pmlopes complted the list of examples that are required for the 3.0 final
 +
 +[16:03:48] <​cescoffier>​ that's cool, we are mostly done with the examples
 +
 +[16:04:02] <​temporalfox>​ pmlopes now time to make them polyglot :-)
 +
 +[16:06:43] <​pmlopes>​ temporalfox isn't that just a rebuild of the project and let the codegen do its magic?
 +
 +[16:06:51] <​temporalfox>​ codetrans :-)
 +
 +[16:07:10] <​temporalfox>​ pmlopes it means sometimes changing the java code to make it translatable
 +
 +[16:07:16] <​temporalfox>​ I sent an email on vertx-dev about it
 +
 +[16:07:32] <​temporalfox>​ I'm working on codetrans improvements to increase the coverage though
 +
 +[16:07:43] <​temporalfox>​ one issue I found is in vertx-web
 +
 +[16:07:49] <​temporalfox>​ one example uses fail(throwable)
 +
 +[16:08:01] <​temporalfox>​ the polyglot api has a "​fail(int)"​ method
 +
 +[16:08:26] <​temporalfox>​ somehow shouldnt we support a fail(String) ?
 +
 +[16:14:58] <​purplefox>​ pmlopes: awesome
 +
 +[16:15:13] <​purplefox>​ pmlopes: cescoffier: you two have done an awesome job :)
 +
 +[16:58:11] <​pmlopes>​ temporalfox:​ how can i iterate over a map values in a way that the code translator will accept it? for (Object o : map.values()) {} is not allowed... how can i make it work?
 +
 +[17:34:07] <​temporalfox>​ pmlopes : use mapEach((k,​v) -> )
 +
 +[17:46:49] <​temporalfox>​ map.forEach
 +
 +[17:47:08] <​millrossjez>​ @purplefox: just in case you think you're missing something, i'm quite a fan of Spring Boot for setting up a primarily Spring project, but I don't see significant benefit in the idea of combining Spring Boot and vert.x (other than to placate architects who want to know if they can use both)
 +
 +[17:47:28] <​purplefox>​ +1
 +
 +[17:47:51] <​purplefox>​ but then again, i know bugger all about spring really ;)
 +
 +[17:49:19] <​millrossjez>​ I know it pretty well, and it has its place, but if your first question about a new tech is "how does it play with Spring Boot" I think you're asking the wrong first question ;)
 +
 +[17:53:05] <​millrossjez>​ Spring Boot is really just a mechanism for inferring, based on what spring components are on your classpath, conventions for wiring them together (e.g. set up database connectivity,​ expose web endpoints etc)
 +
 +[17:54:31] <​purplefox>​ temporalfox:​ cescoffier: I think we need to move things around in the examples repo a bit
 +
 +[17:54:48] <​cescoffier>​ yes probably
 +
 +[17:54:51] <​temporalfox>​ what's the problem ?
 +
 +[17:54:56] <​cescoffier>​ start to be kind of _busy_
 +
 +[17:54:57] <​temporalfox>​ complexity ?
 +
 +[17:55:00] <​purplefox>​ i notice the maven simplest and maven verticle example now have a parent pom which is the root pom of the repo
 +
 +[17:55:14] <​purplefox>​ which wasn't the case before
 +
 +[17:55:31] <​purplefox>​ this is not desirable because it means the fatjar will pull in all sorts of unwanted deps
 +
 +[17:55:42] <​temporalfox>​ purplefox agreed
 +
 +[17:55:56] <​purplefox>​ and the idea with maven simplest is the user can just copy the pom
 +
 +[17:56:00] <​purplefox>​ directly
 +
 +[17:56:33] <​purplefox>​ so we need to support examples in sub dirs which don't have the parent dir as a parent
 +
 +[17:56:39] <​purplefox>​ but maven doesn'​t allow this I believe
 +
 +[17:56:59] <​purplefox>​ so i think we need to push most things down one level
 +
 +[17:57:06] <​purplefox>​ so there is no parent pom in the top directory
 +
 +[17:57:37] <​purplefox>​ then we can have examples such as maven verticle, springboot which can have different parent poms
 +
 +[17:58:16] <​purplefox>​ wdyt?
 +
 +[17:58:33] <​cescoffier>​ purplefox Maven supports this ;-) no problem
 +
 +[17:59:23] <​cescoffier>​ we can clearly remove all parent declaration - so each project would have to be _Standalone_
 +
 +[17:59:42] <​purplefox>​ do you know how to fix it?
 +
 +[17:59:48] <​cescoffier>​ yes
 +
 +[17:59:50] <​purplefox>​ when i build the springboot example it tells me:
 +
 +[17:59:51] <​purplefox>​ [WARNING] '​parent.relativePath'​ points at io.vertx:​vertx-examples instead of org.springframework.boot:​spring-boot-starter-parent,​ please verify your project structure @ org.springframework.boot:​springboot-example:​[unknown-version],​ /​home/​tim/​projects/​vert-x3/​vertx-examples/​springboot-example/​pom.xml,​ line 6, column 11
 +
 +[17:59:51] <​purplefox>​ [WARNING]
 +
 +[17:59:51] <​purplefox>​ [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
 +
 +[18:00:10] <​cescoffier>​ is it merged ?
 +
 +[18:00:19] <​purplefox>​ ok let me do that now
 +
 +[18:00:41] <​purplefox>​ cescoffier: it's merged now
 +
 +[18:01:04] <​cescoffier>​ ok pulling and fixing
 +
 +[18:01:05] <​purplefox>​ we don't want all examples to be standalone, just the ones like:
 +
 +[18:01:16] <​purplefox>​ maven-verticles,​ maven-simplest,​ springboot
 +
 +[18:01:28] <​purplefox>​ springboot for example uses its own parent
 +
 +[18:03:04] <​purplefox>​ cescoffier: thanks. i am pretty crap with maven
 +
 +[18:03:22] <​cescoffier>​ I shared my life between Maven and OSGi
 +
 +[18:03:56] <​purplefox>​ so maybe you can now take over the title of "​resident maven expert"​ from temporalfox ? ;)
 +
 +[18:04:13] <​cescoffier>​ here it's pretty simple, by default the parent pom relative path is ../pom.xml, but in your case it's not. So you need to say to Maven "come on, don't check this" with a simple <​relativePath/>​
 +
 +[18:04:46] <​cescoffier>​ well let's see for the title ;-) It suits well on temporalfox
 +
 +[18:05:11] <​purplefox>​ lol
 +
 +[18:05:33] <​cescoffier>​ anyway, we should try to avoid using '​parent'​ in our example so people can come, copy and paste directly
 +
 +[18:05:44] <​cescoffier>​ it should be self-contained
 +
 +[18:06:09] <​cescoffier>​ in the springboot case, spring boot configuration is inherited from the parent, so it's probably the only examples where a parent is required
 +
 +[18:07:06] <​cescoffier>​ pmlopes : I've a couple of rb file (generated) not checked in ? Is it expected ? (web examples)
 +
 +[18:07:58] <​pmlopes>​ On my machine there are nome, maybe my snapshots of codegen are old...
 +
 +[18:08:14] <​cescoffier>​ yes, code gen evolves a lot lately
 +
 +[18:08:26] <​cescoffier>​ try with mvn clean install -U
 +
 +[18:08:36] <​cescoffier>​ purplefox : parent pom issue fixed
 +
 +[18:10:01] <​pmlopes>​ I'm out for my capoeira time so i'll check it later, but you can push any changes i don't have any code to check in
 +
 +[18:11:09] <​purplefox>​ temporalfox:​ looking at the groovy maven verticle example (codetrans) - doesn'​t look right to me
 +
 +[18:11:10] <​purplefox>​ https://​github.com/​vert-x3/​vertx-examples/​blob/​master/​maven-verticle/​src/​main/​groovy/​io/​vertx/​example/​helloworldverticle.groovy
 +
 +[18:11:27] <​purplefox>​ I don't think it should be creating a new Vertx object as it's a verticle
 +
 +[18:12:01] <​purplefox>​ cescoffier: yeah probably we should make them all self contained
 +
 +[18:12:12] <​purplefox>​ but then we end up with a lot of poms! (e.g. in vertx-web)
 +
 +[18:12:55] <​purplefox>​ pmlopes: have fun!
 +
 +[18:16:21] <​cescoffier>​ purplefox: will have a look tomorrow
 +
 +[18:18:53] <​purplefox>​ cescoffier: np, cya tomorrow :)
 +
 +[18:38:01] <​temporalfox>​ purplefox it is because the maven verticle is not updated by codetrans
 +
 +[18:38:13] <​temporalfox>​ becasue the example is self contained
 +
 +[18:38:18] <​temporalfox>​ I think we should just remove the groovy and js version
 +
 +[18:38:29] <​purplefox>​ ah ok :)
 +
 +[18:38:46] <​purplefox>​ hmm, vertx-examples doesn'​t seem to be building now anyway...
 +
 +[18:38:51] <​temporalfox>​ I just build it
 +
 +[18:38:56] <​temporalfox>​ but I had to update my snapshots
 +
 +[18:39:01] <​purplefox>​ something to do with the service proxy example
 +
 +[18:39:27] <​purplefox>​ [ERROR] /​home/​tim/​projects/​vert-x3/​vertx-examples/​service-proxy-examples/​service-provider/​src/​main/​java/​io/​vertx/​examples/​service/​ProcessorServiceVerticle.java:​[18,​5] constructor ProcessorServiceVertxProxyHandler in class io.vertx.examples.service.ProcessorServiceVertxProxyHandler cannot be applied to given types;
 +
 +[18:39:28] <​purplefox>​ [ERROR] required: io.vertx.core.Vertx,​io.vertx.examples.service.ProcessorService,​java.lang.String,​boolean,​long
 +
 +[18:39:32] <​temporalfox>​ yes
 +
 +[18:39:35] <​temporalfox>​ I had the same
 +
 +[18:40:26] <​temporalfox>​ we just had a big storm here
 +
 +[18:41:48] <​purplefox>​ ok cool it builds now :)
 +
 +[18:41:51] <​purplefox>​ thunderstorm?​
 +
 +[18:41:53] <​temporalfox>​ yes
 +
 +[18:41:59] <​temporalfox>​ now it's quiet
 +
 +[18:42:05] <​purplefox>​ cool, i like thunderstorms
 +
 +[18:42:05] <​temporalfox>​ my internet went down
 +
 +[18:42:17] <​temporalfox>​ and my apc beeped all the way long
 +
 +[18:42:24] <​temporalfox>​ UPS backup I mean
 +
 +[18:43:16] <​purplefox>​ must have been pretty serious
 +
 +[18:43:45] <​purplefox>​ btw have you any idea about this: https://​github.com/​vert-x3/​vertx-examples/​issues/​44
 +
 +[18:43:56] <​purplefox>​ i am trying to remove the parent from the maven-simplest example
 +
 +[18:44:02] <​purplefox>​ but maven doesn'​t like it
 +
 +[18:44:10] <​purplefox>​ and I can't use relativePath as there is no parent
 +
 +[18:45:46] <​purplefox>​ i like the smell of the ground after a thunderstorm,​ rain on dry earth
 +
 +[18:45:54] <​temporalfox>​ I'm trying
 +
 +[18:47:05] <​temporalfox>​ remove the parent section
 +
 +[18:47:09] <​temporalfox>​ and add
 +
 +[18:47:12] <​temporalfox>​ <​groupId>​io.vertx</​groupId>​
 +
 +[18:47:15] <​temporalfox> ​ <​version>​3.0.0-SNAPSHOT</​version>​
 +
 +[18:47:22] <​temporalfox>​ that works for me
 +
 +[18:47:28] <​temporalfox>​ unless I'm missing something obvious :-)
 +
 +[18:48:02] <​temporalfox>​ so one example that is not translated from core is
 +
 +[18:48:07] <​temporalfox>​ Cannot generate EventBusExamples#​example7 : Unsupported method MethodSignature[name=addHeader,​parameters=[java.lang.String,​ java.lang.String]] on object model
 +
 +[18:48:20] <​temporalfox>​ because it's specific to java
 +
 +[18:48:34] <​temporalfox>​ and does not exist in other langs
 +
 +[18:52:00] <​purplefox>​ doh, why didn't i think of that?
 +
 +[19:05:25] <​lexey4eg>​ Hi, i'm wondering if vertx is production ready, may be someone can provide some real-world examples of production usage?
 +
 +[19:06:30] <​purplefox>​ lexey4eg: take a look at the list of companies on the V3 website http://​vert-x3.github.io/​
 +
 +[19:06:57] <​purplefox>​ (scroll down)
 +
 +[19:07:01] <​purplefox>​ (click more)
 +
 +[19:07:25] <​purplefox>​ and we have a bunch more to put up still
 +
 +[19:07:58] <​millrossjez>​ I think Mark's huge gaming app is live isn't it
 +
 +[19:07:58] <​purplefox>​ (and that's just a few, there are many more companies who haven'​t got their logos up there (not all companies like to make it public)
 +
 +[19:08:07] <​purplefox>​ millrossjez:​ yes
 +
 +[19:08:13] <​purplefox>​ that's not up there either
 +
 +[19:08:33] <​millrossjez>​ I think that's one of the best "​production-ready"​ statements given the level of load they'​re expecting
 +
 +[19:08:37] <​lexey4eg>​ thx for information
 +
 +[19:09:16] <​purplefox>​ so yes many companies use vert.x in production including some very big companies, e.g. very large banks etc
 +
 +[19:09:37] <​millrossjez>​ my client isn't in production but that isn't because of any concerns about vert.x
 +
 +[19:10:10] <​millrossjez>​ their code is so production-unready vert.x isn't the major concern :)
 +
 +[19:13:05] <​lexey4eg>​ I'm just started investigation of vert.x and found out some gap in technical info. I mean i can found some common presentations,​ but i can't find any information about how vert.x works under the hood, i mean architecture details and etc., so it yet looks a little bit magic for me now
 +
 +[19:14:55] <​purplefox>​ lexey4eg: there should be a lot of information on the V3 website http://​vert-x3.github.io/​
 +
 +[19:15:07] <​purplefox>​ lexey4eg: and of course the source is all public so you can look at it yourself
 +
 +[19:15:42] <​aesteve>​ http://​vert-x3.github.io/​docs/​vertx-core/​java/#​_reactor_and_multi_reactor ​   |    https://​github.com/​vietj/​vertx-materials/​blob/​master/​src/​main/​asciidoc/​Demystifying_the_event_loop.adoc
 +
 +[19:33:43] <​lexey4eg>​ Thx for the information,​ especially for Demystifying_the_event_loop.adoc
 +
 +[19:35:44] <​lexey4eg>​ may be you have something like Demystifying_vertx_class_loading_and_modules_hot_reload?​ ;)
 +
 +[19:36:58] <​aesteve>​ so you're using vertx 2 lexey4eg ?
 +
 +[19:39:02] <​lexey4eg>​ no, just making investigation. Trying to choose best one for new project
 +
 +[19:40:08] <​aesteve>​ You should consider looking at Vert.x 3 if you're investigating. There'​s no longer "​modules"​ just simple jars
 +
 +[19:40:26] <​lexey4eg>​ I think if i we choose vert.x we can use v.3, looks like it's near - Vert.x 3.0.0-final (release: 22 June 2015)
 +
 +[19:40:38] <​aesteve>​ definitely :)
 +
 +[20:20:37] <​andyhedges>​ purplefox: re early conversation,​ it caught me out when using the Mongo Client - however that creates another verticle under the hood so would make sense
 +
 +[20:20:44] <​andyhedges>​ if it is as simple as then then that's ok
 +
 +[20:21:02] <​andyhedges>​ so http client is in the same context too?
 +
 +[20:24:41] <​purplefox>​ andyhedges: the mongo client doesn'​t create another verticle
 +
 +[20:30:37] <​andyhedges>​ OK, the callback handler seems to operate on a different thread - if that's not correct I'll submit a reproducer for you
 +
 +[21:48:37] <​temporalfox>​ purplefox for mail we need to have CaseInsensitiveHeaders polyglot, I'm suggesting to add a static factory method on MultiMap