Differences

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

Link to this comparison view

irc:1441922400 [2017/05/27 13:44] (current)
Line 1: Line 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.runOnContext((v) -> resultHandler.handle(...));​
 +
 +[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