Differences

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

Link to this comparison view

irc:1427839200 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +
 +
 +[11:48:52] <​aesteve>​ Hello everyone. If anyone interested : https://​github.com/​aesteve/​vertx-mvc/​blob/​master/​README.md
 +
 +[11:49:12] <​aesteve>​ it's a kind of resteasy-like framework on top of Apex
 +
 +[11:55:04] <​temporalfox>​ you need a nickname maybe for the project
 +
 +[11:55:25] <​aesteve>​ I'm bad at nicknames :(
 +
 +[11:55:39] <​temporalfox>​ one awesome thing you could do is to generate URL builders
 +
 +[11:55:46] <​temporalfox>​ using annotation processing
 +
 +[11:55:52] <​temporalfox>​ I did that for my previous web framework
 +
 +[11:56:11] <​temporalfox>​ also annotation processing can help you save annotations
 +
 +[11:56:19] <​temporalfox>​ @Param("​type"​) CharacterType type
 +
 +[11:56:21] <​aesteve>​ not sure I understand what an URL Builder is
 +
 +[11:56:28] <​temporalfox>​ something to build an URL :-)
 +
 +[11:56:31] <​temporalfox>​ so you do
 +
 +[11:56:33] <​temporalfox>​ in java
 +
 +[11:56:48] <​temporalfox>​ CharactersController_.getCharacter("​foobar"​);​
 +
 +[11:56:52] <​temporalfox>​ and it returns an URL
 +
 +[11:57:00] <​temporalfox>​ CharactersController_ is a generated class
 +
 +[11:57:11] <​temporalfox>​ and the url builder uses the @Path info etc...
 +
 +[11:57:26] <​aesteve>​ mmh
 +
 +[11:58:17] <​temporalfox>​ if I would have time I would help you doing it :-)
 +
 +[11:58:17] <​aesteve>​ how will I map the generated URL onto an Apex route ?
 +
 +[11:58:35] <​temporalfox>​ ah
 +
 +[11:58:39] <​temporalfox>​ it is for generating URL
 +
 +[11:58:46] <​temporalfox>​ not handling them
 +
 +[11:59:03] <​aesteve>​ ah ok
 +
 +[11:59:03] <​temporalfox>​ creating server URL from server side
 +
 +[11:59:19] <​aesteve>​ for now, every annotation is a runtime annotation
 +
 +[11:59:40] <​aesteve>​ when you bootstrap the "​mvc"​ layer, it scans and instanciates all the apex stuff for you (basically)
 +
 +[12:00:01] <​aesteve>​ but I'm pretty sure I could benefit from non-runtime annotations !
 +
 +[12:00:20] <​temporalfox>​ with annotation processing you could remove need for @Param annotation
 +
 +[12:00:23] <​temporalfox>​ that repeats the name
 +
 +[12:00:26] <​temporalfox>​ like in Play1
 +
 +[12:00:37] <​temporalfox>​ because you have access to this info at compilation time
 +
 +[12:01:12] <​aesteve>​ so the name of the java parameter would be the name of the request/​route parameter ?
 +
 +[12:01:19] <​aesteve>​ would be awesome indeed
 +
 +[12:01:30] <​temporalfox>​ yes
 +
 +[12:02:55] <​aesteve>​ cool, I'll create an issue so that I don't forget
 +
 +[12:05:12] <​aesteve>​ thanks :)
 +
 +[13:46:21] <​temporalfox>​ purplefox_ I have a question for you
 +
 +[14:06:52] <​purplefox_>​ temporalfox:​ sure
 +
 +[14:07:19] <​temporalfox>​ I'm wrapping a java lib that gathers OS info, like process, cpu, etc...
 +
 +[14:07:29] <​temporalfox>​ for a demo
 +
 +[14:07:40] <​temporalfox>​ it's called "​sigar"​
 +
 +[14:07:59] <​temporalfox>​ I would like to have a node able to fetch info regularly from a cluster
 +
 +[14:08:20] <​temporalfox>​ right now a sigar verticle published a bus address in the shared data map
 +
 +[14:08:42] <​temporalfox>​ and then a node that wants such info can query send a message and get a reply with the info
 +
 +[14:08:49] <​temporalfox>​ do you have something simpler in mind ?
 +
 +[14:09:11] <​purplefox_>​ shared data local map? that's only local to the vert.x instance
 +
 +[14:09:20] <​temporalfox>​ clustered map
 +
 +[14:09:27] <​temporalfox>​ vertx.sharedData().getClusterWideMap
 +
 +[14:10:32] <​purplefox_>​ ok
 +
 +[14:10:54] <​purplefox_>​ why not just have a well known address and have the verticle publish stats to that, then others can subscribe to that address?
 +
 +[14:11:25] <​temporalfox>​ ok
 +
 +[14:11:30] <​temporalfox>​ I was thinking at this
 +
 +[14:11:40] <​temporalfox>​ however the node that gets data, does not know the topology
 +
 +[14:11:56] <​temporalfox>​ ideally it aggregates data and then send it to the client
 +
 +[14:12:09] <​temporalfox>​ it can however gather data
 +
 +[14:12:17] <​temporalfox>​ and send the updated aggregated view every second
 +
 +[14:12:31] <​temporalfox>​ and takes whatever has been published during that timeframe
 +
 +[14:12:43] <​temporalfox>​ so I will try htat instead
 +
 +[14:13:08] <​purplefox_>​ i guess i'm not sure i understand your topology
 +
 +[14:13:38] <​temporalfox>​ servers on the cluster start a SigarVerticle that publishes OS metrics
 +
 +[14:13:55] <​temporalfox>​ and one node of the cluster gathers them all and then send it to the browser for doing charting
 +
 +[14:16:22] <​purplefox_>​ ok
 +
 +[14:35:28] <​aesteve>​ purplefox_: hello, I was wondering something I can't find in the docs, is there a way to "​join"​ futures ?
 +
 +[14:36:22] <​aesteve>​ like : i want to do A, and B : and once A and B are finished, I'm ready to do something
 +
 +[14:37:15] <​aesteve>​ I did that here for example : https://​github.com/​aesteve/​vertx-mvc/​blob/​bfa56b2576c42f6fede9c6391e77e62e0af32632/​src/​main/​java/​io/​vertx/​mvc/​utils/​MultipleFutures.java
 +
 +[15:20:27] <​temporalfox>​ aesteve you can use RxJava for that
 +
 +[15:20:44] <​temporalfox>​ and the Rxified api
 +
 +[15:22:10] <​aesteve>​ ok I'll have a look, thanks tekacs
 +
 +[15:22:21] <​aesteve>​ oops, thanks temporalfox :\
 +
 +[19:47:35] <​AlexLehm>​ in case you haven'​t read that already, take a look at https://​com.google/​
 +
 +[20:13:34] <​voidDotClass>​ lol
 +
 +[20:14:11] <​voidDotClass>​ is .google a tld?
 +
 +[21:01:29] <​voidDotClass>​ purplefox_: temporalfox : Why does the static file handler create a .vertx/​file-cache-xxx directory / files?
 +
 +[21:01:43] <​voidDotClass>​ Shouldnt it cache the stuff in memory? After all the static files are meant to be static
 +
 +[21:01:50] <​voidDotClass>​ what's it writing to disk?
 +
 +[21:03:47] <​purplefox_>​ static doesn'​t mean the files don't change. e.g. it's pretty common to edit a something.html file on a website and have the change picked up without restarting the server
 +
 +[21:04:21] <​purplefox_>​ static just means the files aren't dynamic, i.e. they'​re not created on the fly with e.g. templates
 +
 +[21:04:37] <​voidDotClass>​ but they are packed in a jar
 +
 +[21:04:40] <​voidDotClass>​ they cant change
 +
 +[21:04:56] <​temporalfox>​ if you use the CLI it can change
 +
 +[21:05:02] <​temporalfox>​ I'm doing that at the moment :)
 +
 +[21:05:13] <​voidDotClass>​ would you do that in prod?
 +
 +[21:05:19] <​voidDotClass>​ caching is only useful for prod
 +
 +[21:05:25] <​temporalfox>​ good point
 +
 +[21:05:35] <​temporalfox>​ I'm not an apex specialist yet though :-)
 +
 +[21:11:28] <​purplefox_>​ static handler has cache headers enabled so if it hasn't changed then it won't serve the file again anyway
 +
 +[21:11:41] <​purplefox_>​ (i.e. using if-modified-since)
 +
 +[21:11:56] <​voidDotClass>​ purplefox_: but what is it writing to disk?
 +
 +[21:12:13] <​purplefox_>​ we extract to disk because:
 +
 +[21:12:24] <​purplefox_>​ a) it's much faster to serve from disk than to extract from a jar
 +
 +[21:13:19] <​voidDotClass>​ If you are running within a jar, isn't class.getResourceAsStream() or equivalent, just getting it from memory?
 +
 +[21:13:34] <​purplefox_>​ b) don't want to fill memory with lots of files
 +
 +[21:13:40] <​purplefox_>​ you might have gigabytes of files
 +
 +[21:14:01] <​purplefox_>​ class.getResourceAsStream() depending on where the resources is might end up unzipping a jar
 +
 +[21:14:09] <​purplefox_>​ also its blocking
 +
 +[21:14:27] <​purplefox_>​ sendFile from disk is the most efficient way to serve files
 +
 +[21:14:37] <​purplefox_>​ it actually bypasses userspace altogether in most cases
 +
 +[21:15:11] <​voidDotClass>​ so you're reading the file from jar the first time, writing it to disk, then reading it from disk and serving it from disk from then on?
 +
 +[21:15:18] <​purplefox_>​ yes
 +
 +[21:15:28] <​purplefox_>​ but it's not necessarily in a jar in the first place
 +
 +[21:15:38] <​purplefox_>​ it could be elsewhere on the classpath or not on the classpath at all
 +
 +[21:15:47] <​purplefox_>​ but in some cases (e.g. fatjars) it might be in a jar
 +
 +[21:22:11] <​voidDotClass>​ i see
 +
 +[21:30:48] <​purplefox_>​ temporalfox:​ i have some auth and apex changes almost ready, but won't be ready until tomorrow morning. will they be in time for the release?
 +
 +[21:30:57] <​temporalfox>​ yes
 +
 +[21:31:02] <​voidDotClass>​ which release?
 +
 +[21:31:02] <​temporalfox>​ I will do the release friday
 +
 +[21:31:06] <​temporalfox>​ milestone4
 +
 +[21:31:07] <​purplefox_>​ ok great.
 +
 +[21:31:18] <​temporalfox>​ can you validate my tiny metrics changes :-) ?
 +
 +[21:31:18] <​purplefox_>​ michel has also provided a PR for the website :)
 +
 +[21:31:32] <​temporalfox>​ yes that's providence
 +
 +[21:31:42] <​temporalfox>​ I mean totally awesome
 +
 +[21:32:17] <​purplefox_>​ +1
 +
 +[21:32:47] <​purplefox_>​ +100
 +
 +[22:35:12] <​AlexLehm>​ voidDotClass,​ i assume .google is a tld controlled by google onl
 +
 +[22:35:33] <​voidDotClass>​ yeah seems they acquired the .tld