Differences

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

Link to this comparison view

irc:1444687200 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[00:03:43] <​jtruelove_>​ we use the shared map concept to coordinate across verticles in a bunch of places
 +
 +[00:04:03] <​jtruelove_>​ i may not even do the ref counting and just elect once vertx instance the listener
 +
 +[00:05:27] <​temporal_>​ I haven'​t looked much in the very details jtruelove_
 +
 +[00:14:10] <​jtruelove_>​ but at a minimum it seems like you '​must'​ use the vertx-shell style verticle instance initialization to get the SPI options in
 +
 +[00:15:29] <​jtruelove_>​ and each SPI impl instance associated to each vertx instance will be a client of the one shared listener that will do the publishes off the event bus
 +
 +[00:16:02] <​jtruelove_>​ so you can create as many vertx-opentsdb metrics clients without spamming the total outbound connections to opentsdb
 +
 +[09:19:07] <​purplefox>​ temporal_: pmlopes: cescoffier morning guys
 +
 +[09:19:22] <​cescoffier>​ good morning purplefox
 +
 +[09:19:47] <​temporal_>​ good morning everyone
 +
 +[09:21:01] <​purplefox>​ how's it going with you?
 +
 +[09:21:14] <​purplefox>​ I'm going to start on the event bus pluggability thingy today
 +
 +[09:22:14] <​cescoffier>​ I'm fine and you
 +
 +[09:22:32] <​cescoffier>​ started working on the many presentation I'm going to present (first on Friday)
 +
 +[09:22:32] <​purplefox>​ pretty good
 +
 +[09:22:44] <​cescoffier>​ and also working on the stack builder
 +
 +[09:22:49] <​purplefox>​ good stuff
 +
 +[09:22:57] <​purplefox>​ which conf is on friday?
 +
 +[09:23:04] <​cescoffier>​ BTW, last weekend, I've migrated wisdom framework to vert.x 3.1
 +
 +[09:23:14] <​purplefox>​ awesome
 +
 +[09:23:22] <​cescoffier>​ on friday it's Eclipse Days (something pretty small), next Friday I've softshake
 +
 +[09:23:23] <​purplefox>​ don't forget too add it to vertx-awesome
 +
 +[09:23:34] <​temporal_>​ I'm wokring this morning with Thomas on metrics SPI with hawkular
 +
 +[09:23:38] <​purplefox>​ ok, this will be good practice for devoxx :)
 +
 +[09:23:40] <​cescoffier>​ I will, but I've found two small issues I need to discuss with Paulo
 +
 +[09:23:44] <​temporal_>​ to review his stuff
 +
 +[09:24:07] <​purplefox>​ geez, do you ever stop working? ;)
 +
 +[09:24:08] <​cescoffier>​ (the issues are about HTTP compliance in netty)
 +
 +[09:24:45] <​purplefox>​ ok
 +
 +[09:25:26] <​cescoffier>​ BTW, purplefox : vert.x will be present at the CES in Las Vegas :-)
 +
 +[09:25:52] <​cescoffier>​ (via wisdom, but that's kind of cool anyway)
 +
 +[09:27:38] <​purplefox>​ great
 +
 +[09:28:56] <​temporal_>​ @purplefox if you can also wire some back pressure in event bus it would be cool :-)
 +
 +[09:30:10] <​purplefox>​ ah yes, back pressure
 +
 +[09:31:18] *** ChanServ sets mode: +o temporalfox
 +
 +[09:32:20] <​pmlopes>​ good morning
 +
 +[09:32:59] <​cescoffier>​ good morning pmlopes
 +
 +[09:33:15] <​cescoffier>​ pmlopes: do you have some free time today ? I would like to discuss a few things
 +
 +[09:34:04] <​pmlopes>​ yes, i've received your mindmap but i did not had time to look at it properly
 +
 +[09:35:10] <​cescoffier>​ we need to discuss this, but I also a couple of question about HTTP.
 +
 +[09:35:23] <​cescoffier>​ (might be bug we currently have in vert.x)
 +
 +[12:53:13] *** ChanServ sets mode: +o purplefox
 +
 +[13:53:37] <​voidDotClass>​ i've upgraded to 3.1.0 from 3.0.0-MILESTONE6 , via maven, but the maven dep doesn'​t seem to be set up right, i'm getting a bunch of missing class errors
 +
 +[13:55:18] <​Sticky>​ going from 3.0.0 to 3.1.0 was fairly seamless for me
 +
 +[13:56:40] <​voidDotClass>​ yeah, in my repo i see the jars are there, but Intellij is not loading them for some reason
 +
 +[13:59:55] <​Sticky>​ oh yeah, use mvn dependency:​tree to make absolutely sure no 3.0.0-MILESTONE6 jars are left around
 +
 +[14:00:42] <​voidDotClass>​ its not that its loading milestone jars, its that intellij isn't loading the new jars
 +
 +[14:00:49] <​voidDotClass>​ so its showing classNotFound errors
 +
 +[14:01:12] <​cescoffier>​ well, between 3.0.0-m6 and 3.1.0 lots of things have been changed
 +
 +[14:01:23] <​cescoffier>​ for instance, logging classes have been moved
 +
 +[14:01:29] <​cescoffier>​ this was made before the 3.0.0 release
 +
 +[14:02:53] <​voidDotClass>​ i don't use vertx for logging, i mostly just use httpserver and vertx-web
 +
 +[14:20:45] <​cescoffier>​ hum, what are the unresolved classes ?
 +
 +[14:31:00] <​voidDotClass>​ cescoffier, the classes are working now, but i had some code using Utils.createISODateTimeFormatter();​
 +
 +[14:31:03] <​voidDotClass>​ that's breaking
 +
 +[14:31:29] <​cescoffier>​ can you give the the fully qualified name of Utils ?
 +
 +[14:33:48] <​voidDotClass>​ cescoffier, ​ io.vertx.ext.web.impl.Utils
 +
 +[14:34:16] <​cescoffier>​ your code is using an implementation class ?
 +
 +[14:35:11] <​voidDotClass>​ i guess
 +
 +[14:36:09] <​cescoffier>​ createRFC1123DateTimeFormatter
 +
 +[14:36:45] <​voidDotClass>​ cescoffier, thanks, is that the one used in http headers?
 +
 +[14:37:24] <​voidDotClass>​ yes, it is
 +
 +[14:37:43] <​cescoffier>​ in which headers ? last-modified - yes
 +
 +[14:37:56] <​cescoffier>​ in the cookies, not sure
 +
 +[14:38:11] <​voidDotClass>​ yes, last-modified
 +
 +[15:29:44] <​voidDotClass>​ what's the status of http2 support in vertx?
 +
 +[15:33:05] <​voidDotClass>​ is it present in snapshot?
 +
 +[15:36:28] <​temporalfox>​ voidDotClass no support so far, we're waiting for Netty to be released with it
 +
 +[15:36:32] <​cescoffier>​ no it's not thereyet
 +
 +[15:36:33] <​temporalfox>​ and then adapt
 +
 +[15:36:38] <​voidDotClass>​ ah
 +
 +[15:36:48] <​cescoffier>​ it should be in netty 4.1, that will be released soonish
 +
 +[15:36:53] <​voidDotClass>​ great
 +
 +[16:17:29] <​Sticky>​ hay I am getting issues during tests of setTimer throwing RejectedExecutionException,​ it seems to think that the executor has shutdown but cannot tell why this would have happened. Has anyone else noted this?
 +
 +[17:15:59] <​purplefox>​ Sticky: sounds like the vert.x instance has been closed
 +
 +[17:17:50] <​Sticky>​ I think it is to do with somehow the thread pool being shared between multiple unit tests
 +
 +[17:18:29] <​Sticky>​ so at the end of one test the eventloop thread pool gets shutdown, then the next test trys to use it
 +
 +[17:25:12] <​ksclarke>​ I'm trying to handle a path that comes in as /​path/​to/​something?#​state=asdf but I don't seem to be able to access that fragment from vertx-web... it's not in a param (because it's not a param) or the .query() or .uri()... is there a way to get access to it?
 +
 +[17:40:42] <​jtruelove>​ temporal when you are back around let me know the outcome of the chat with the hawkular guy
 +
 +[17:41:08] <​jtruelove>​ i'd be open to doing a video conf at some point if you wanted to chat about design on this stuff
 +
 +[18:04:14] <​Sticky>​ eurgh, this is just enfurtiating chasing down threading bugs
 +
 +[18:23:27] <​Ashe`>​ ksclarke: normally it's not sent by the browser
 +
 +[18:23:59] <​Ashe`>​ not sure why it'd be ?#​state=asdf rather than just ?state=asdf though
 +
 +[18:24:26] <​Ashe`>​ or you're using some i-got-no-html5-history workaround?
 +
 +[18:25:05] <​ksclarke>​ this is a javascript library that's passing it back through -- I'm not sure why #state either but there must be some reason for it because for another service it's working with it does use ?state=
 +
 +[18:25:27] <​ksclarke>​ (which makes it so much nicer)
 +
 +[18:25:55] <​ksclarke>​ I imagine it is some sort of internal workaround for this library (which isn't mine... I'm just using)
 +
 +[18:26:14] <​Ashe`>​ yeah angular and such have a similar mechanism where they prefix with #
 +
 +[18:26:32] <​Ashe`>​ otherwise you need url rewriting
 +
 +[18:27:02] * ksclarke nods
 +
 +[18:27:07] <​Ashe`>​ could be a bug in that lib I guess
 +
 +[18:27:31] <​Ashe`>​ like, there'​s a # at the end of the url and it doesn'​t add the query params before it
 +
 +[18:27:41] <​Ashe`>​ cause query params shouldn'​t be an issue with url rewriting
 +
 +[18:27:47] <​Ashe`>​ it's only for paths
 +
 +[18:28:47] <​ksclarke>​ possibly... I'm at the point where I don't want to sink too much more time into it (and will just look for a server side solution instead of this javascript one) if I can't access the #value through request() somehow
 +
 +[18:29:14] <​Ashe`>​ well, browsers won't send it so you're pretty much screwed
 +
 +[18:29:27] <​Ashe`>​ (anything past the hashbang or whatever it's called, anyway)
 +
 +[18:30:09] <​ksclarke>​ hmm, okay, I was under the impression a js library was sending it via xhr but perhaps I'm wrong about that
 +
 +[18:30:27] <​ksclarke>​ sounds like my best path is just to look to the server side, thanks
 +
 +[18:30:30] <​Ashe`>​ with the browser debugger (or even just the console) you can see what's sent
 +
 +[18:31:55] <​ksclarke>​ it's popping up a new window when it does this and I'm not seeing anything in/from that new window when looking in chrome tools for xhr... I just see stuff from the page that opens the new window
 +
 +[18:36:43] <​melvinross>​ I've got what i hope is a silly question. I'm trying to send a JsonObject over the eventbus from a JS verticle
 +
 +[18:37:42] <​melvinross>​ I'm successfully creating the JsonObject object, but when I try to send it, vertx core is throwing an error about unrecognized tokens
 +
 +[20:13:28] <amr> are you encoding it?
 +
 +[20:13:46] <amr> there'​s a method on JsonObject, .encode()
 +
 +[20:13:49] <amr> oh, event bus
 +
 +[22:08:23] <​melvinross>​ has anyone ever used the englishtown elastic search vertical?
 +
 +[22:34:35] <​jtruelove>​ temporalfox any big take aways from your session today?