This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[05:59:42] * ChanServ sets mode: +o temporalfox [07:51:08] * ChanServ sets mode: +o purplefox

[09:35:35] * ChanServ sets mode: +o temporalfox [10:04:46] <pmlopes> good morning temporalfox [10:04:52] <temporalfox> good morning [10:05:00] <temporalfox> how are you doing ? [10:05:21] <temporalfox> could you review the incremental templating feature in codegen ? [10:05:29] <pmlopes> fine a bit sleepy :-/ (need more coffee), and you? [10:05:54] <pmlopes> yes i will review. [10:05:56] <pmlopes> are we having a meeting today? [10:06:17] <temporalfox> no we don't unless you want to talk about a particular subject [10:06:26] <temporalfox> I think we said last week we skip it [10:06:43] <pmlopes> well i've a couple of subjects but i think we can discuss here if you like [10:06:51] <temporalfox> yes we can [10:06:57] <temporalfox> besides it is logged :-) [10:07:54] <pmlopes> ok, so i've a couple of PRs that should be reviewed/merged, there is this one on core: [10:08:32] <pmlopes> that is quite simple, so when a user tries to send a non existing file core always ends returning 200 :-/ [10:08:40] <pmlopes> kind of strange when you expect 404 [10:08:58] <pmlopes> the pr is tiny and includes a unit test to reproduce the issue [10:09:21] <temporalfox> yes I see that [10:10:19] <temporalfox> so what happens if the file does not exist and there is no handler ? [10:11:05] <pmlopes> you get a status 200 and an empty body with content length 0 [10:11:41] <temporalfox> is this behavior already tested ? [10:12:01] <temporalfox> I mean like testSendNonExistingFile but with no resultHandler [10:13:32] <pmlopes> oh, i can add that but the current code delegates all sendFile methods to a private doSendFile method that handles it on one place, and thats where i did the fix [10:14:50] <temporalfox> I think what you should test is that when you get the resultHandler callback, you are on the expected context [10:21:42] <pmlopes> isn't that what this does?: ctx.runOnContext1); [10:22:24] <temporalfox> I mean in the test [10:22:25] <temporalfox> :-) [10:22:34] <pmlopes> oh ok :) [10:24:59] <pmlopes> and another critical issue that we need to look is: [10:25:12] <pmlopes> it currently breaks the build of vertx-web [10:28:34] <pmlopes> temporalfox: the test now checks if the context is correct [10:29:08] <temporalfox> sounds good then [10:29:40] <pmlopes> i can't merge it (no rights), so its your call :) [10:31:57] <temporalfox> yep [10:32:00] <temporalfox> going to do it [10:34:32] <pmlopes> temporalfox, the next item i had to discuss was the issue that is quite blocking for me since it breaks the vertx-web builds [10:35:24] <pmlopes> how are you with netty details? i looked at the code and i don't see what could cause it but i'm not very familiar with the details of netty… [10:36:07] <temporalfox> I am good on some parts [10:36:19] <temporalfox> I am not expert [10:36:33] <temporalfox> let me merge first the first pr [10:37:22] <pmlopes> well i troubleshoot it using git bissect so i managed to isolate the commit that breaks, but i cannot explain which line, unless i now start poking the changes [10:38:46] <temporalfox> what means [10:38:48] <temporalfox> “mixed status responses” ? [10:40:02] <pmlopes> so during the tests for example we set response status 400, but then what we get at the test client is status code 999 [10:40:14] <temporalfox> ok [10:40:30] <pmlopes> no matter what you set it always ends up being 999 [10:40:31] <temporalfox> and this is because of the invalid response status message ? [10:40:46] <pmlopes> no, this is nothing to do with that issue [10:40:51] <temporalfox> ok :-) [10:40:56] <temporalfox> so you fixed that probelm ? [10:41:04] <temporalfox> or you are investigating it ? [10:41:32] <temporalfox> but this problem happens in server or in client ? [10:41:40] <pmlopes> i only investigated and found that if i revert that specific commit on core than the all tests pass on vertx-web [10:41:48] <pmlopes> this is a server issue [10:41:50] <temporalfox> ok [10:42:26] <temporalfox> the funny thing is that this commit changes the client, doesnt it ? [10:43:52] <pmlopes> humm true, so it seems because it is about ClientConnection [10:44:17] <temporalfox> did you use wireshark to see what happens at http level ? [10:44:33] <temporalfox> to be sure that the status is not correct in the http protocol [10:44:53] <pmlopes> no, i'll verify what comes at the http level [10:45:13] <temporalfox> is it easy to reproduce ? [10:45:41] <temporalfox> try to set on the client maxSockets to a large number [10:46:15] <temporalfox> i.e getMaxPoolSize [10:46:21] <temporalfox> in options [10:46:33] <temporalfox> to see if that changes something [11:02:35] <pmlopes> the server responses are correct, i see the right headers when using curl, setting the maxsockets to 100 on a loop of 8 requests did not make a difference on the test still same result [11:05:47] <temporalfox> so it's a client problem [11:05:54] <temporalfox> because of pooling [12:13:23] <s0va> after applying patch to vertx-hazelcast our production app heaps are still ~200MiB after 24 hours in production; yay! [12:52:40] <Lecherito> Where can I inform about a typo in the web? [13:11:22] <temporalfox> Lecherito here [13:22:55] <Lecherito> temporalfox: The typo is in the JWT auth doc, that will be generated automatically or something from javadocs, right? [13:23:29] <temporalfox> look here [13:24:00] <Lecherito> There it is [13:25:30] <Lecherito> I feel silly opening a pull request for that lol [13:26:39] <temporalfox> I think you can do that online without needing to make a clone locally [13:26:52] <temporalfox> github has very nice web interface for this [13:32:07] <Lecherito> Did it [13:48:45] <DP2015> Does anyone know if you can use a router with websocketHandler [13:55:18] <Sticky> I found no [13:55:29] <Sticky> there may be a way but I couldnt find it [13:55:43] <Sticky> wait that may be a lie [13:55:59] <Sticky> I couldnt use sockjsbridge and websocketHandler [13:57:29] <DP2015> so .web doesn't play nice with websockets? [13:59:07] <Sticky> I could handle websockets from a router by copying the code at [13:59:38] <Sticky> so you just take the request and upgrade it to a WS [14:00:51] <DP2015> did you implement that entire class or just part or it [14:01:11] <Sticky> just 61-74 [14:02:23] <DP2015> do you have an example on how it would be called from HttpServer e.g server.websocketHandler(ws → ws.handler(????)).requestHandler(router::accept).listen(443); [14:02:50] <Sticky> oh, so this for me avioded the need to use websocketHandler [14:03:09] <Sticky> I could just bind websockets to any arbitary path [14:03:38] <DP2015> do you have an example Http Server initialization i could see? [14:03:46] <DP2015> just trying to get my head around how it fits [14:05:02] <DP2015> or does that just becom part of the router [14:05:16] <DP2015> and i ignore web sockets all together as the router will pick it pu? [14:05:18] <DP2015> up? [14:07:32] <DP2015> ok sorry i think we are after different thing [14:09:12] <DP2015> I can handle websockets ok, i jsut want a request to http://test and ws:test to go through same route handlers, just define routes once and have both a websocketHAndler and requestHanlder both pass of to same Router [14:09:30] <DP2015> something like server.websocketHandler(router::accept).requestHandler(router::accept).listen(443); [14:09:33] <Sticky> DP2015: [14:09:41] <DP2015> thanks [14:10:49] <Sticky> so you can add http routes to that router too if you like [14:12:00] <DP2015> ok i tihnk i understand [14:24:52] <DP2015> wow Sticky, that looks like it does the trick, i can now have my usual auth, session handling and everything else before the upgrade , thanks for the help !!!!!!!!!!! [14:25:06] <DP2015> before the upgrade to websocket [14:25:31] <Sticky> yeah [14:25:51] <Sticky> that is the best part of this, you can rig it so only authed people can open the socket [14:26:36] <DP2015> yep thats what i was looking for [14:26:38] <DP2015> AWESOME [14:26:41] <DP2015> me soo horny! [14:26:47] <DP2015> thanks for the help [14:26:52] <DP2015> its awesome [14:27:57] <Sticky> the rc even has a user object so you can give specific users “websocket” privalidges: rc.user().isAuthorised(“websocket”,… [14:36:27] <DP2015> interesting, jsut setting it up now to use the same handlers so can downgrade to http if websockets are not support on client all using the same handlers [14:37:07] <Sticky> are you trying to nih sockjs? [14:38:54] <DP2015> no i am only supporting browsers that support socket [14:38:57] <DP2015> websocket [14:39:05] <DP2015> if not then will degrade back [14:39:15] <DP2015> or tell them to upgrade [14:39:18] <Sticky> ahh [14:39:26] <Sticky> yeah, fair enough [14:39:34] <DP2015> running via mobile 2G, 3G, 4G the biggest issue is latency [14:39:51] <DP2015> so forcing websockets will make the app usable [14:40:07] <DP2015> without looking at massive response time jsut due to latency [14:41:52] <DP2015> so being mobile i have to keep the Javasript and client side stuff down to the absolute minumum [14:42:17] <Sticky> I wouldnt be so sure that websockets vs polling etc will have significant impact on latency when on a mobile network, but meh, either way most modern browsers support websockets anyway (although I am not sure about mobile browsers) [14:47:32] <DP2015> almost all mobile browsers do now [14:47:53] <DP2015> there is a massive speed up on weboskets iva mobile [14:48:04] <DP2015> its where you get the biggest advtage [14:50:23] <amr> blocking workers is “ok” right? [14:54:49] <amr> i'm writing some scrapers, and i want some worker instances to “pause” so i dont hammer URLs to frequently [14:55:55] <Sticky> amr: you can use vertx setTimer and setPeriodic to schedual stuff [15:03:39] <amr> hmm actually, thats a point [15:04:18] <amr> atm ive got a verticle that periodically hits some db resource and pulls a list of place to scrape, and then it fires individual URLs at workers [15:04:30] <amr> maybe i just periodically send a batch instead [15:08:31] <amr> thanks :-) [15:33:32] <domenico> hello guys, do you know of any existing course to learn something about vertx in a more traditional, [unknown:ldquo]attended[unknown:rdquo] mode ? [15:36:14] * ChanServ sets mode: +o purplefox [16:14:56] <cmbergamo> Hello, everyone… [16:15:09] <Sticky> yo [16:15:47] <cmbergamo> I'm new in using vertx, and i have some doubts. Can someone, help me? [16:16:00] <Sticky> maybe [16:16:44] <cmbergamo> I create a share datasource, and I don't know how to get it from other verticles [16:17:32] <Sticky> how do you create it [16:18:13] <cmbergamo> Like this: JDBCClient.createShared(vertx, config, “MyDataSource”); [16:18:29] <Sticky> make that call again in the other verticle [16:18:51] <cmbergamo> Just it? [16:19:15] <Sticky> yes [16:19:22] <Lecherito> As doc says, the first call will actually create it, the second one will just grab it [16:19:29] <Sticky> yeah [16:19:30] <cmbergamo> Even if I try to use in oneother instance (cluster) ? [16:19:56] <cmbergamo> But I have to pass all confi information again? [16:20:29] <Sticky> config is generally got via vertx.getOrCreateContext().config() [16:20:45] <Sticky> so you dont need to pass the object instance [16:20:59] <cmbergamo> Ah, ok! That I doesn't Knowing [16:21:27] <cmbergamo> Thanks Sticky, I will make de changes here… [16:21:32] <Sticky> cool [17:10:55] <Lecherito> I like when there is a community with irc channel [17:11:11] <Lecherito> I hate all the platforms but this one [17:14:29] <Sticky> give it a few days, someone will rage that their question on irc was not answered within 10 min. [17:16:02] <Lecherito> That always happen :D [17:16:30] <Lecherito> Or those who join, ask and leave all in an interval of 3 minutes [17:18:20] <Sticky> also need a bot that links to: [17:20:07] <Sticky> cmbergamo: also you should read that, you did to an “ask to ask” earlier, its not a big issue but is a good life tip [17:21:17] <Lecherito> Yep [17:33:00] <millrossjez> 12 days ago I said hi on IRC and noone answered inside 30 seconds, shocking stuff [17:53:30] <Lecherito> hi millrossjez [18:02:04] <millrossjez> hi Lecherito :) [18:02:20] <Lecherito> Now it is less shocking [18:02:25] <millrossjez> on a serious note I like IRC too [18:02:47] <millrossjez> if you want your question to persist forever use the group, but IRC is always handy to see if there's a very quick answer [19:35:10] <jclingan> [unknown:nbsp][unknown:nbsp]/msg NickServ VERIFY REGISTER jclingan fexootdixshg [19:35:32] <jclingan> crap, sorry [19:38:57] <Sticky> this channel is logged, may want to change that [19:39:21] <AlexLehm> the msg didn't show up in the archive, they probalby have a pattern to remove pws [19:39:33] <Sticky> hunter2 [19:39:53] <AlexLehm> still, its probably better to change it [19:40:47] <AlexLehm> /msg alexlehm test [19:40:54] <jclingan> Agreed. Darn leading space in copy/paste. [19:41:01] <AlexLehm> or its deleting irc commands? [19:42:48] <msavy_> perhaps it's sentient [19:42:56] <jclingan> Luckily it's not a password, only verification. Sorry all. [22:09:17] * ChanServ sets mode: +o temporalfox

v) → resultHandler.handle(…