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: https://github.com/vert-x3/issues/issues/51
[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: https://github.com/vert-x3/issues/issues/50
[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 https://github.com/vert-x3/issues/issues/50 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 https://github.com/vert-x3/vertx-web/issues
[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 https://github.com/vert-x3/vertx-auth/blob/master/vertx-auth-jwt/src/main/java/io/vertx/ext/auth/jwt/package-info.java
[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 https://github.com/vert-x3/vertx-web/blob/master/src/main/java/io/vertx/ext/web/handler/sockjs/impl/WebSocketTransport.java#L61
[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: https://gist.github.com/johnoliver/740cb009527882a5e768
[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: http://sol.gfxile.net/dontask.html
[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