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?