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

[06:18:26] <voidDotClass> is it possible to dynamically add static directory handlers to apex?

[06:18:32] <voidDotClass> i.e at runtime?

[09:42:35] <aesteve> purplefox: If you have a minute I have a couple of simple (non technical) questions

[09:42:52] <purplefox> sure

[09:43:09] <aesteve> i was chatting with my CTO informally last night

[09:43:22] <aesteve> he asked a very good question about the polyglot aspet of vertx

[09:43:44] <aesteve> do you have a vague idea of with which language people mostly use it ?

[09:43:51] <purplefox> java

[09:44:03] <aesteve> by far ? you think

[09:44:25] <aesteve> and second question is about the redis client

[09:44:30] <purplefox> well… i have stats from vert.x 2 (not 3) because of visits to the different lang pages of the website

[09:44:35] <purplefox> based on that

[09:44:39] <purplefox> java is most popular

[09:44:48] <purplefox> JS and groovy are also quite popular

[09:44:54] <aesteve> ah docs are a good metric indeed

[09:45:01] <purplefox> Ruby is less popular, and python the least popular

[09:45:29] <purplefox> and think this makes sense as most of our demographic is Java users who are sick of JavaEE and other Java platforms, not Node.js users who move to vet.x

[09:45:30] <aesteve> yes I think python has a lot of similar frameworks from what I remember

[09:45:33] <aesteve> like flask etc.

[09:45:47] <purplefox> the python and ruby communities are very religious and they don't like jvm stuff

[09:46:01] <purplefox> so they stick with their non jvm tool chain

[09:46:13] <aesteve> that makes sense

[09:46:25] <purplefox> that's one thing I have learned with vert.x

[09:46:28] <aesteve> just like a Ruby user won't use Grails

[09:46:34] <purplefox> its not really just the language its the whole ecosystem

[09:46:42] <purplefox> yes

[09:47:07] <purplefox> jruby is proven to be the fastest ruby engine, but its also the least popular. think about that for a minute :)

[09:47:17] <aesteve> idd

[09:47:25] <aesteve> thx that's a good answer :)

[09:47:45] <aesteve> in regard of the redis client, do you think the 2 bugs could be corrected for the final release ?

[09:47:56] <purplefox> so i think our main audience is java/groovy users who want to do non blocking, reactive stuff

[09:47:58] <purplefox> not javaee

[09:48:06] <purplefox> and also want to do a bit of JS too maybe

[09:48:37] <aesteve> with Vert.x 2 Groovy was almost mandatory for me (because of closures)

[09:48:58] <aesteve> now it's kinda even. The syntaxic sugar is cool for maps / lists and not deal with stream()

[09:49:11] <purplefox> true

[09:49:20] <purplefox> regarding the redis bugs, if they're easy fixes we will do them

[09:49:35] <purplefox> but feel free to submit some PRs to make our lives easier ;)

[09:49:40] <aesteve> in fact this one is concerning me :

[09:49:44] <aesteve> I'm not a redis expert

[09:49:58] <aesteve> so Idk really but I think checking params size is wrong

[09:51:59] <purplefox> ok, will take a look a bit later

[09:52:11] <aesteve> thanks Tim, have a nice day

[09:57:33] <purplefox> aesteve: and you :)

[10:02:24] <purplefox> temporalfox: pmlopes cescoffier i'm joining the meeting now

[11:10:35] <purplefox> temporalfox: i'm looking at reapplying your jsonobject/jsonarray changes that i reverted. do you remember.. were the changes only in core or are there changes in other projects too?

[11:10:50] <temporalfox> it was only core

[11:10:59] <temporalfox> but I think it has side effects in other projects you mentionned

[11:11:19] <purplefox> ok thx

[11:11:20] <temporalfox> so I think it would be good to control these and add new tests in vertx core to have json object comply to these constraints

[11:11:43] <purplefox> yep i'll try and figure out what makes mongo break, think it is something in the equals implementation

[11:13:15] <pmlopes> purplefox, temporalfox, cescoffier:

[11:13:34] <pmlopes> some quick notes after what we've discussed…

[11:14:15] <temporalfox> pmlopes hi for releases you may want to look at project

[11:14:20] <temporalfox> that I use for releasing until now

[11:14:29] <temporalfox> it describes how the pom dependencies are currently managed

[11:14:51] <temporalfox> I see there is a section in your wiki page about release and pom updates with version

[11:22:09] <pmlopes> temporalfox so the gitflow plugin would only “help” on the first step, it makes sure that you won't forget to tag and push tags so you don't need to handle all the git commands manually. I think it is a important thing because in the past I made releases where I would forget to tag or push the tags and then someone notices and I need to find the commit, checkout that specific commit, tag in the past and push…

[11:22:46] <temporalfox> I've been bitten by that too sometimes

[11:23:04] <temporalfox> I'm have nothing against moving to something else than the current process / tooling though

[11:23:19] <temporalfox> I think one important part that forced this current design

[11:23:28] <temporalfox> is to have a centralized file with all versions

[11:23:41] <temporalfox> and not manage snapshots version in all projects

[11:23:52] <temporalfox> because that becomes really hard to manage

[11:24:05] <temporalfox> given that after 3.0 versions will not all be same all the time

[11:24:48] <temporalfox> the aggregator project became helpful because of the project dependencies between themselves

[11:24:51] <temporalfox> it could be done without

[11:25:26] <temporalfox> but finding the right order of the project is done at the moment with this aggregator as it uses the Maven reactor that knows best how to figure out the order

[11:56:43] <aesteve> pmlopes:next thing I'd like to implement for vertx-web is , tell me if I'm not clear enough in the issue

[11:59:11] <pmlopes> aesteve, we need to confirm with purplefox, because we are on milestone6 (last before 3.0) and we feature/api freeze… I think this issue will only make it to 3.1 since it introduces a new API

[11:59:36] <aesteve> yeah obviously, everything I'm referring to is past 3.0 :)

[12:09:50] <purplefox> temporalfox: can i just check something with you in JsonObject?

[12:12:32] <AlexLehm> purplefox, i will remove the runOnContext from the unit tests

[12:53:45] <pmlopes> aesteve: about the issue i think it is clear, i've updated the issue with a API more aligned with vertx-web

[12:54:22] <aesteve> ok I'll have a look, thanks Paulo

[13:01:44] <AlexLehm> is there a way to force @Before and @After methods to be called in a sequence

[13:02:35] <AlexLehm> like i want to close my server before close the vertx object

[13:03:56] <aesteve> AlexLehm:not that I know of

[13:04:16] <aesteve> unless there's inheritance (superclass first) (that's what I use commonly)

[13:04:41] <aesteve> but in your case, closing the vertx object should close everything related to that vertx instance no ?

[13:05:14] <AlexLehm> i currently have TestClass → implements Server Testclass → implements TestBaseClass

[13:05:30] <AlexLehm> yes that should work

[13:08:17] <purplefox> AlexLehm: just use vertxtestbase

[13:08:52] <purplefox> and override setup/teardown then you have order

[13:09:34] <AlexLehm> hm, i just started to remove that since I used vertx-unit, maybe that is not a good idea

[13:57:58] <purplefox> temporalfox: this jsonobject stuff is giving me a headache

[13:58:12] <temporalfox> purplefox what's the problem ?

[13:58:27] <purplefox> temporalfox: it seems your changes to jsonobject are incompatible with recent PR that was accepted in vertx-service-proxy

[13:58:39] <temporalfox> ok

[14:01:00] <purplefox> temporalfox: actually… it's not related to that PR, but it does cause tests to fail

[14:01:05] <temporalfox> <hich PR ?

[14:01:08] <temporalfox> ok

[14:01:22] <purplefox> i already pushed the changes in core, so if you git pull than and build

[14:01:23] <temporalfox> I was looking at the PR :-)

[14:01:26] <purplefox> then try and run service proxy tests

[14:01:27] <temporalfox> ok

[14:01:32] <temporalfox> sure

[14:03:02] <purplefox> i think the problem is that service proxy assumes that if you have a jsonarray containing jsonobject that if you call getList() on the jsonarray you will get a List containing JsonObject but now you actually get a List containing Map

[14:03:43] <temporalfox> I get this

[14:03:44] <temporalfox> java.lang.ClassCastException: java.util.HashMap cannot be cast to io.vertx.core.json.JsonObject

[14:03:49] <purplefox> yes

[14:04:25] <purplefox> this is because previously we were storing the jsonObject instances internally in the jsonarray but now we just store the hashmap instances

[14:05:35] <temporalfox> but it could have stored Map with several level of nesting via Jackson unmarshalling

[14:05:51] <temporalfox> anyway

[14:05:59] <temporalfox> can it be adapted to use map instead ?

[14:15:20] <purplefox> i guess, but it's a pain

[14:20:19] <temporalfox> do you prefer that we modify lang-groovy to convert json → map recursively ?

[14:21:22] <purplefox> not sure

[14:27:09] <purplefox> i'm going to park it for a while

[14:27:14] <temporalfox> ok

[14:44:37] <cescoffier> purplefox you have merged a PR without reading the comment ;-)

[14:45:03] <cescoffier> the osgi examples would only work if you merge the PR I did on vertx-core

[14:48:33] <cescoffier> ok, you did did ;-)

[14:48:37] <purplefox> cescoffier: ;)

[14:48:45] <purplefox> but you're right, i did it in the wrong order :)

[14:49:08] <cescoffier> so, it works on Felix, Equinox and even Knopflerfish

[14:49:14] <cescoffier> so no problem for KAraf

[14:49:41] <cescoffier> (you probably never heard about Knopflerfish before)

[14:59:58] <purplefox> no, never heard of it. but that doesn't mean much as i don't know much about osgi ;)

[15:07:11] <purplefox> cescoffier: clement, i am getting a build failure when attempting to build vertx-examples (mvn install)

[15:07:13] <purplefox> [ERROR] Failed to execute goal org.apache.felix:maven-ipojo-plugin:1.12.1:ipojo-bundle (default) on project osgi-examples: The input file /home/tim/projects/vert-x3/vertx-examples/osgi-examples/target/classes is not a Jar file → [Help 1]

[15:07:15] <purplefox> any ideas?

[15:07:28] <purplefox> (this is after I merged the osgi examples)

[15:07:53] <cescoffier> let me check, probably a packaging type issue

[15:10:15] <cescoffier> purplefox are you in your IDE ?

[15:10:31] <purplefox> the error was at the command line

[15:10:50] <cescoffier> from the root or from the project itself ?

[15:10:55] <purplefox> from the root

[15:11:02] <purplefox> mvn clean install

[15:11:49] <purplefox> i suppose install is pretty meaningless here

[15:12:08] <cescoffier> weird I don't have it

[15:12:44] <purplefox> i guess it's because packing type is bundle, and install needs a jar

[15:12:56] <purplefox> but i guess mvn install is not appropriate anyway

[15:13:04] <purplefox> for this project

[15:13:10] <purplefox> it compiles ok

[15:13:38] <purplefox> ah, mvn package doesn't work weither

[15:13:39] <cescoffier> the bundle packaging type is an extension of jar

[15:13:51] <cescoffier> can you tell me your mvn version ?

[15:14:17] <purplefox> 3.2.3

[15:14:38] <purplefox> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T21:58:10+01:00)

[15:14:39] <purplefox> Maven home: /home/tim/apache-maven-3.2.3

[15:14:39] <purplefox> Java version: 1.8.0_45, vendor: Oracle Corporation

[15:14:39] <purplefox> Java home: /home/tim/jdk1.8.0_45/jre

[15:14:39] <purplefox> Default locale: en_GB, platform encoding: UTF-8

[15:14:40] <purplefox> OS name: “linux”, version: “3.13.0-37-generic”, arch: “amd64”, family: “unix”

[15:14:40] <cescoffier> so not a maven version issue

[15:15:05] <purplefox> did you git pull from vertx-examples and also git pull and mvn install vertx-core ?

[15:15:50] <cescoffier> yes

[15:16:00] <cescoffier> can you launch mvn clean package -X

[15:16:08] <cescoffier> (goanna write lots of stuff)

[15:17:48] <purplefox> cescoffier: this is the exception i get:

[15:26:55] <purplefox> temporalfox: it looks like the jsonobject/array change breaks a lot of things in service-proxy so I think we should probably revert it (again ;)

[15:27:09] <temporalfox> no prob

[15:28:07] <purplefox> so now i will revert the revert of the revert ;)

[15:28:25] <cescoffier> Can you try with this pom

[15:28:26] <cescoffier>

[15:28:33] <temporalfox> never seen that before

[15:28:50] <temporalfox> perhaps you are in a cycle like in inception

[15:29:18] <temporalfox> and you will continue reverting it

[15:30:26] <purplefox> cescoffier: yes that seems to solve the osgi issue, but now i get an issue from the docker examples

[15:30:29] <purplefox> temporalfox: lol

[15:30:37] <cescoffier> do you have docker installed ?

[15:30:40] <purplefox> temporalfox: it already feels like that

[15:30:44] <cescoffier> ok, will commit this pom

[15:30:50] <purplefox> cescoffier: no, so i guess that is the problem

[15:30:51] <cescoffier> actually, shorter (so better)

[15:31:06] <purplefox> cescoffier: cool just commit it directly no need for pr

[15:31:14] <cescoffier> temporalfox: do we have docker enabled by default or not ? Cannot remember what we discussed ?

[15:31:19] <cescoffier> ok

[15:31:23] <temporalfox> yes it is enabled by default

[15:31:30] <temporalfox> and you can use -DskipDocker to skip it

[15:31:38] <temporalfox> in vertx-stack

[15:32:51] <cescoffier> temporalfox purplefox - maybe in example we should disble them by default ?

[15:33:03] <temporalfox> I don't know about examples

[15:33:25] <cescoffier> not everyone has docker on his machine (and tons of disk space because it downloads the universe)

[15:33:30] <temporalfox> I think what you can do

[15:33:35] <temporalfox> is have the example

[15:33:40] <temporalfox> but it does not use the docker plugin

[15:33:49] <temporalfox> and you activate this docker plugin with an extra explicit profile

[15:33:57] <temporalfox> so you still build the code

[15:34:10] <cescoffier> yes, that's sound like a plan

[15:34:11] <temporalfox> but it does not build the docker image until it's explicitely asked

[15:34:19] <cescoffier> purplefox ok for you ?

[15:34:23] <temporalfox> because anyway this docker image ends up in the docker registry

[15:34:33] <temporalfox> and it's not possible to run it without docker installed

[15:34:56] <temporalfox> another option I think is to just configure the docker plugin in plugin management

[15:35:01] <temporalfox> and then in README we say that

[15:35:10] <temporalfox> user should do “mvn docker:build”

[15:35:19] <temporalfox> after compiling the project to produce the actual docker image

[15:35:26] <temporalfox> and deploy it in the local registry

[15:35:38] <temporalfox> the user could also even use its own docker CLI

[15:35:43] <temporalfox> after buildling it

[15:35:52] <temporalfox> docker build …./docker

[15:37:03] <purplefox> temporalfox: lol, here is the inception commit:

[15:37:37] <temporalfox> that reminds me when you fix a bug you found when fixing another bug several times

[15:39:34] <cescoffier> the docker build cannot be manual acutally

[15:39:44] <cescoffier> as the plugin massage the docker file ….

[15:39:52] <cescoffier> (don't ask why they do this)

[15:47:29] <cescoffier> About `redeploy example (showing disabling of cache too)` the cache stuff is about -Dvertx.disableFileCaching=true ?

[15:47:38] <cescoffier> or is it something I don't know yet ?

[16:18:34] <cescoffier> purplefox - fixed the docker dependency, so you should be able to build now

[16:26:20] <aesteve> there's something I've always found confusing in the docs and I think that's because I don't fully understand the reactor pattern

[16:26:25] <aesteve> “Vert.x works differently here. Instead of a single event loop, each Vertx instance maintains several event loops. By default we choose the number based on the number of available cores on the machine, but this can be overridden.”

[16:27:00] <aesteve> vs

[16:27:02] <aesteve> “Each verticle instance is +strictly single threaded so to scale your application across available cores you might want to deploy more than +one instance”

[16:27:25] <aesteve> I guess the thing relies in _your application_

[16:28:25] <aesteve> so basically when I start a Verticle, the verticle itself is single threaded, but relies on a multi-threaded event loop ?

[16:28:46] <aesteve> well relies is not the right word… but…

[16:29:00] <purplefox> cescoffier: thanks

[16:29:55] <purplefox> aesteve: yes the verticle is single threaded

[16:30:01] <purplefox> an event loop is a thread

[16:31:03] <purplefox> i'm not sure i understand what bit you find confusing

[16:31:20] <aesteve> it's a matter of words I think

[16:31:52] <aesteve> when I run my webServer for instance, with everything set up as default

[16:32:39] <aesteve> my verticle is single threaded, and there are many threads, called event-loops which are handling events

[16:32:58] <aesteve> (please correct my phrasing if it's wrong)

[16:33:30] <purplefox> how many instances of your verticle do you have?

[16:35:19] <aesteve> let's say I'm using the default configuration

[16:35:35] <purplefox> not sure what you mean by that

[16:35:40] <aesteve> vertx run

[16:35:48] <aesteve> with no -instances option

[16:35:54] <cescoffier> so 1 instance

[16:35:58] <purplefox> ok so just one instance then

[16:36:20] <purplefox> so when your verticle is deployed, vert.x assigns it an event loop out of the available pool of event loops

[16:36:35] <purplefox> and from then on that event loop will be used to deliver all events for that verticle instance

[16:37:23] <aesteve> ok thanks

[16:37:53] <purplefox> that's why you need to deploy more than one instance if you want to use all available cores

[16:38:09] <aesteve> so thant's just not a matter of words, I have to read the docs once more

[16:38:12] <purplefox> and that's an area where vert.x differs from node.js

[16:39:24] <purplefox> brb

[17:42:39] <aesteve> purplefox: thanks for the fixes in redis-client

[17:43:37] <purplefox> np, i actually had a local branch with fixes in it from a while back that I'd completely forgotten to merge ;)

[17:48:47] <aesteve> purplefox:do you have a minute to talk about the eventloop / number of threads things or you'd prefer I ask on the Google group ?

[17:51:26] <purplefox> sure

[17:51:44] <purplefox> here is fine

[17:52:27] <aesteve> so let's imagine I'm working on my local dual core machine, and run a MainVerticle through Vertx started class (or command line with no option)

[17:52:43] <purplefox> ok

[17:52:47] <aesteve> when Vertx is started, 4 event loops should be available

[17:52:50] <purplefox> yes

[17:53:07] <aesteve> one of them is assigned to my MainVerticle

[17:53:10] <purplefox> yes

[17:53:26] <aesteve> then my MainVerticle deploys two verticles (standard, non-workers)

[17:54:05] <aesteve> each of them gets an event-loop assigned

[17:54:15] <purplefox> yes

[17:54:24] <aesteve> since they're chosen with a round robin, they all have a different event loop at this point

[17:54:29] <purplefox> yes

[17:54:56] <aesteve> so If I want to benefit the most of my dual core machine

[17:55:31] <aesteve> what I should do in this case is : only one instance for the mainVerticle since it doesn't do anything except deployment

[17:56:00] <aesteve> then identify among the two others which one is gonna benefit from multiple instances

[17:56:07] <aesteve> (the most)

[17:56:44] <purplefox> there is no correct anwswer here, is depends on your application and what your verticles do

[17:56:49] <aesteve> imagine the first one is a webserver, the other is just a periodic reporter

[17:56:55] <purplefox> ok

[17:57:06] <purplefox> what do you mean by “periodic reporter”?

[17:57:21] <aesteve> I had no idea of a “very lightweight verticle”

[17:57:40] <aesteve> imagine it sends an email with an extract from mongo every 24h or something like that

[17:57:46] <purplefox> ok

[17:58:19] <purplefox> so in this case I'd deploy number of webservers >= number of cores

[17:59:02] <aesteve> because MainVerticle AND PeriodicThingy can reuse the webserver event loops with very little side effect

[17:59:05] <aesteve> ?

[17:59:10] <purplefox> yes

[17:59:19] <aesteve> mmh I think I'm starting to understand

[18:00:03] <purplefox> cool

[18:00:26] <aesteve> I'll rethink that again and again but thanks alot for your help, it helps me alot

[18:00:51] <purplefox> np

[18:53:16] <temporalfox> purplefox with a few tweaks in SimpleRest now it can generate something

[18:53:23] <temporalfox> I think it does not execute yet

[18:53:33] <temporalfox> for instance : products[product.“id”] = product;

[18:53:42] <temporalfox> need some improvements

[18:54:09] <temporalfox> there is quite work still needed

[18:54:14] <temporalfox> but that's a start

[18:54:38] <temporalfox> (also the instance member products is not yet translated)

[18:56:42] <temporalfox> the groovy version :

[19:33:28] <purplefox> cool

[19:34:34] <aesteve> purplefox: I'll submit PRs tonight for template engines. And I think I'll work on JS template engines next

[19:35:24] <purplefox> awesome

[19:35:39] <aesteve> especially underscore

[19:38:09] <aesteve> do you have other template engines in mind ?

[19:38:21] <aesteve> I saw there was “scalate” used in Play!

[19:39:17] <aesteve> and I tried to run vertx-web tests in IntelliJ and got some errors

[19:39:55] <aesteve> not sure if I should build every Vert.x project manually or just rely on oss snapshots

[19:41:09] <purplefox> aesteve: the snapshots should be ok now

[19:44:00] <aesteve> ok I'll fetch upstream then

[19:50:06] <aesteve> ah ok I guess these are issues due to Windows

[19:50:17] <aesteve> like CRLF or stuff like that

[19:51:43] <aesteve> like : io.vertx.ext.web.handler.StaticHandlerTest#testContentHeadersSet is failing with java.lang.AssertionError: expected:<18> but was:<20>

[19:51:57] <aesteve> nvm I'll work on Mac tonight