Differences

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

Link to this comparison view

irc:1432591200 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[09:46:12] <​Huntter>​ Hi guys, I want to build the vert.x 3 example project, but seems the artifacts are not house in the maven central, where can I get the artifacts?
 +
 +[09:47:13] <​temporalfox>​ Huntter so either yo ucan use a tag
 +
 +[09:47:18] <​temporalfox>​ of vertx examples
 +
 +[09:47:36] <​temporalfox>​ or use https://​oss.sonatype.org/​content/​repositories/​snapshots/​
 +
 +[09:47:42] <​temporalfox>​ the sonatype snapshot repo
 +
 +[09:48:08] <​Huntter>​ what I can find in maven central is vertx3 perview 1
 +
 +[09:49:00] <​Huntter>​ Cool, there is the 3.0.0-SNAPSHOT thanks in advance
 +
 +[10:07:31] <​cescoffier>​ the easiest I would say is to use the following dependency:
 +
 +[10:07:32] <​cescoffier>​ <​dependencies>​
 +
 +[10:07:32] <​cescoffier> ​  <​dependency>​
 +
 +[10:07:33] <​cescoffier> ​    <​groupId>​io.vertx</​groupId>​
 +
 +[10:07:33] <​cescoffier> ​    <​artifactId>​vertx-stack-depchain</​artifactId>​
 +
 +[10:07:33] <​cescoffier> ​    <​version>​${vertx.version}</​version>​
 +
 +[10:07:33] <​cescoffier> ​    <​type>​pom</​type>​
 +
 +[10:07:33] <​cescoffier> ​  </​dependency>​
 +
 +[10:07:33] <​cescoffier>​ </​dependencies>​
 +
 +[10:07:49] <​cescoffier>​ with ${vertx.version} set to 3.0.0-SNAPSHOT
 +
 +[10:19:45] <​Huntter>​ <​repositories> ​    <​repository> ​      <​id>​oss</​id> ​      <​url>​https://​oss.sonatype.org/​content/​repositories/​snapshots</​url> ​    </​repository> ​  </​repositories>​
 +
 +[10:19:53] <​Huntter>​ I added this to the root pom.xml and it works
 +
 +[10:20:03] <​pmlopes>​ @purplefox are you available?
 +
 +[11:13:11] <​purplefox>​ temporalfox:​ cescoffier pmlopes : good morning!
 +
 +[11:13:27] <​cescoffier>​ morning !
 +
 +[11:13:43] <​purplefox>​ cescoffier: and welcome :)
 +
 +[11:13:51] <​cescoffier>​ thanks !
 +
 +[11:14:14] <​purplefox>​ it was a national holiday in the UK yesterday (and my birthday) so I wasn't around
 +
 +[11:14:22] <​temporalfox>​ good morning all
 +
 +[11:15:13] <​cescoffier>​ no problem, I found stuff to do ;-)
 +
 +[11:15:44] <​cescoffier>​ I don't know if you see, I've provided new docker images (built by maven), and two examples (on compliant with fabric 8)
 +
 +[11:15:50] <​cescoffier>​ fabric 8
 +
 +[11:16:03] <​purplefox>​ i haven'​t seen yet, but that sounds great
 +
 +[11:17:44] <​purplefox>​ cescoffier: today is going to be a pretty crazy week, as we are supposed to be doing the final milestone for Vert.x 3 by the end of the week ;)
 +
 +[11:18:02] <​cescoffier>​ yes, julien told me.
 +
 +[11:18:09] <​purplefox>​ but don't worry we don't expect you or paulo to do any critical stuff for this as you're still finding your feet
 +
 +[11:18:14] <​cescoffier>​ I'm looking at the documentation right now (file system)
 +
 +[11:18:34] <​cescoffier>​ you should get a PR before noon (paris time ;-) )
 +
 +[11:18:45] <​purplefox>​ awesome
 +
 +[11:21:00] <​purplefox>​ cescoffier: temporalfox pmlopes: we should probably have a little meeting to discuss our plans for the milestone a bit later on. wdyt?
 +
 +[11:21:14] <​purplefox>​ just so we know what needs to be done, etc
 +
 +[11:21:18] <​temporalfox>​ purplefox ok, but I have a scheduled lunch today :-)
 +
 +[11:21:54] <​cescoffier>​ purplefox no problem for me
 +
 +[11:21:59] <​purplefox>​ what time is your lunch appointment?​
 +
 +[11:22:44] <​temporalfox>​ I would say between 12h00 and 14h00
 +
 +[11:22:52] <​pmlopes>​ i was looking at the auth stuff and getting it merged to vertxweb but i am not sure how to proceed since it will break the current shiro impl
 +
 +[11:22:52] <​temporalfox>​ I meet a JUG sponsor
 +
 +[11:23:01] <​temporalfox>​ and it's not close to home
 +
 +[11:23:02] <​purplefox>​ and now it is 11:22 for you?
 +
 +[11:23:07] <​temporalfox>​ yes
 +
 +[11:23:46] <​purplefox>​ could we do a quick irc meeting at 11:45 for 15 mins?
 +
 +[11:23:51] <​purplefox>​ i don't think will take long
 +
 +[11:23:53] <​temporalfox>​ yes
 +
 +[11:24:21] <​purplefox>​ great. then we can do a proper meeting next week (on videoconf) after the mileston. i think this week is going to be just too hectic
 +
 +[11:24:51] <​temporalfox>​ shaving yaks
 +
 +[11:25:19] <​purplefox>​ as always ;)
 +
 +[11:30:15] <​cescoffier>​ :-)
 +
 +[11:36:56] <​purplefox>​ temporalfox:​ cescoffier is paulo around this morning?
 +
 +[11:37:19] <​temporalfox>​ pmlopes seems here but perhaps we don't have his attention yet
 +
 +[11:37:34] <​pmlopes>​ i am here
 +
 +[11:38:05] <​pmlopes>​ just multitasking alot :)
 +
 +[11:38:25] <​purplefox>​ :)
 +
 +[11:38:37] <​pmlopes>​ top
 +
 +[11:38:57] <​purplefox>​ pmlopes: one important thing we need to figure out is if we need further changes to auth or now, as this needs to be done before the end of the week
 +
 +[11:39:05] <​purplefox>​ s/or now/or not
 +
 +[11:41:01] <​pmlopes>​ my only concern now is to make the API clear, we currently have a clear seperation between roles and permissions,​ but it is not explicit if the matching is done with string equality or also allowing wildcard, also if the model is user > role > permission
 +
 +[11:41:43] <​purplefox>​ agreed, that's not clear
 +
 +[11:42:08] <​purplefox>​ i'm thinking that perhaps we don't enforce any particular semantics of the actual strings and just document that it is "up to the implementation"​
 +
 +[11:42:16] <​purplefox>​ so shiro can do it one way, something else can do it another way
 +
 +[11:43:17] <​purplefox>​ ok let's leave that discussion to the end of the meeting as julien has to leave in 15 mins
 +
 +[11:43:37] <​purplefox>​ temporalfox:​ pmlopes: cescoffier: ok folks let's start
 +
 +[11:43:46] <​temporalfox>​ purplefox ok
 +
 +[11:43:52] <​cescoffier>​ purplefox ok
 +
 +[11:44:03] <​purplefox>​ so just a quick one
 +
 +[11:44:36] <​purplefox>​ as you know from the roadmap we are due a final milestone before 3.0 on thursday https://​github.com/​vert-x3/​wiki/​wiki/​Vert.x-Roadmap
 +
 +[11:45:01] <​purplefox>​ the idea is most things are done by this milestone then we just tweak stuff for the final release
 +
 +[11:45:15] <​temporalfox>​ define tweak :-)
 +
 +[11:45:31] <​purplefox>​ tweak - some changes to docs, examples, website, maybe fix some bugs
 +
 +[11:45:44] <​purplefox>​ but no new functionality,​ new components
 +
 +[11:46:04] <​purplefox>​ no big refactorings or changes to important APIs
 +
 +[11:46:17] <​purplefox>​ that's what I was thinking
 +
 +[11:46:29] <​pmlopes>​ agree
 +
 +[11:46:34] <​purplefox>​ now realistically i think thursday is only 2 days, which is not enough
 +
 +[11:46:44] <​purplefox>​ so I'm going to suggest we push this until Monday next week
 +
 +[11:46:45] <​cescoffier>​ what do the numbers means on the roadmap. Is it priority ?
 +
 +[11:46:52] <​temporalfox>​ cescoffier yes
 +
 +[11:47:08] <​cescoffier>​ Is 1 the higher priority ?
 +
 +[11:47:19] <​temporalfox>​ cescoffier yes
 +
 +[11:47:57] <​purplefox>​ ok so what's outstanding:​
 +
 +[11:48:13] <​purplefox>​ 1. stack changes (i.e. building the different distros)
 +
 +[11:48:47] <​purplefox>​ 2. possible auth changes (discussing with paulo)
 +
 +[11:48:59] <​purplefox>​ 3. clients (!?)
 +
 +[11:49:31] <​temporalfox>​ mongo client has a PR for date support
 +
 +[11:49:44] <​purplefox>​ right, we should do that
 +
 +[11:49:54] <​purplefox>​ redis needs documentation,​ but is more or less done
 +
 +[11:50:28] <​purplefox>​ email.... i think it is more or less there but maybe needs a little guidance
 +
 +[11:50:45] <​purplefox>​ amqp: i think rajith is nearly there, but also needs to be looked at
 +
 +[11:50:54] <​purplefox>​ rabbit - not sure if we have the time for this
 +
 +[11:51:03] <​purplefox>​ so maybe delay until 3.1
 +
 +[11:51:17] <​purplefox>​ it's not a huge issue i think if we push some of the client stuff
 +
 +[11:51:29] <​purplefox>​ imho it's more important we have the central stuff working well
 +
 +[11:51:59] <​purplefox>​ 4. there'​s also a serious hazelcast bug we are awaiting progress on. but i seem to have found a workaround
 +
 +[11:52:14] <​temporalfox>​ speaking of bugs, I've done some bug fixes / test cases for client/​server worker in vertx core
 +
 +[11:52:25] <​purplefox>​ right, we need to implement those fixes too
 +
 +[11:52:37] <​purplefox>​ some of the smaller bug stuff we can fix after the final milestone
 +
 +[11:52:41] <​temporalfox>​ https://​github.com/​eclipse/​vert.x/​tree/​network-worker-bugs
 +
 +[11:52:49] <​temporalfox>​ I made 3 tests
 +
 +[11:52:50] <​temporalfox>​ 2 fixes
 +
 +[11:52:56] <​purplefox>​ great
 +
 +[11:53:06] <​temporalfox>​ the last one is the big block with synchronized block
 +
 +[11:53:09] <​temporalfox>​ that you should look :-)
 +
 +[11:53:23] <​temporalfox>​ these bugs make the vertx core test suite fail currently
 +
 +[11:53:30] <​temporalfox>​ sometimes
 +
 +[11:53:34] <​temporalfox>​ depending on os
 +
 +[11:54:38] <​temporalfox>​ there maybe other bugs, I'll keep looking after milestone6
 +
 +[11:55:14] <​purplefox>​ ok, so let's split up the work
 +
 +[11:55:18] <​purplefox>​ for this week
 +
 +[11:55:32] <​purplefox>​ (sorry going so fast here... ;) )
 +
 +[11:55:55] <​purplefox>​ julien can you complete the distro stuff, then perhaps help with some of the client stuff
 +
 +[11:56:14] <​purplefox>​ i can do the hazelcast bug and also help with client stuff
 +
 +[11:56:30] <​purplefox>​ and paulo and i can discuss auth changes
 +
 +[11:56:33] <​temporalfox>​ purplefox I'm on the distro / build stuff
 +
 +[11:56:35] <​purplefox>​ (and maybe make some changes)
 +
 +[11:56:41] <​temporalfox>​ purplefox I'll look at the mongodb PR
 +
 +[11:57:13] <​purplefox>​ paulo - maybe you could also take a look at the redis client, as you wrote the original version? :)
 +
 +[11:57:17] <​temporalfox>​ clement is helping me a bit on the distro with docker
 +
 +[11:57:32] <​cescoffier>​ I can have a look at the redis and mail
 +
 +[11:57:48] <​pmlopes>​ sure, i can have a look
 +
 +[11:58:17] <​cescoffier>​ for docker, if we have more stacks- we should provide an image per stack
 +
 +[11:58:27] <​cescoffier>​ as soon as stacks are there, I can do that
 +
 +[11:58:35] <​purplefox>​ pmlopes: basically i think it just needs a bit of documentation (not much) then it's there. and most of the docs can just say "hey look at the redis commansd docs for more info" ;)
 +
 +[11:58:56] <​purplefox>​ cescoffier: one really useful thing for 3.0 would be to have it working on openshift too
 +
 +[11:59:09] <​pmlopes>​ ok
 +
 +[11:59:11] <​purplefox>​ i think it should be pretty simple, but maybe that would be one area to look at
 +
 +[11:59:18] <​cescoffier>​ ok, I have a look
 +
 +[11:59:35] <​cescoffier>​ as a java program or something more integrated ?
 +
 +[11:59:40] <​temporalfox>​ cescoffier for openshift there is a plugin for Vert.x 2, but Vert.x 3 should run more or less in the java main spirit
 +
 +[11:59:58] <​cescoffier>​ ok, no problem
 +
 +[12:00:26] <​purplefox>​ temporalfox:​ right, so it might just be a case of some simple docs... to use openshift you first create your fatjar then blah, blah, blah..,.
 +
 +[12:00:48] <​cescoffier>​ oh as fat jar[unknown:​hellip] so definitely easy
 +
 +[12:00:53] <​purplefox>​ i'll handle the mail client as there are some tricky context related stuff there
 +
 +[12:00:56] <​temporalfox>​ purplefox and perhaps also use the docker images you're buidling :-)
 +
 +[12:01:07] <​purplefox>​ temporalfox:​ +1
 +
 +[12:01:09] <​temporalfox>​ I mean both use case are good
 +
 +[12:01:32] <​cescoffier>​ there is some holes in the main documentation
 +
 +[12:01:43] <​cescoffier>​ should we fix them before the RC ?
 +
 +[12:03:02] <​temporalfox>​ purplefox you need to announce cescoffier on vertx group too :-)
 +
 +[12:03:15] <​purplefox>​ yes will do! :)
 +
 +[12:04:13] <​purplefox>​ cescoffier: right we need to fix those holes :) we can fix more docs stuff after RC too but the sooner the better :)
 +
 +[12:04:54] <​cescoffier>​ ok
 +
 +[12:04:57] <​purplefox>​ temporalfox:​ cescoffier pmlopes: ok folks, are we all good for now?
 +
 +[12:05:10] <​cescoffier>​ everything fine for me
 +
 +[12:05:12] <​temporalfox>​ all good for me, good to have new blood :-)
 +
 +[12:05:16] <​purplefox>​ temporalfox:​ are you cool with delaying the milestone to next monday?
 +
 +[12:05:29] <​temporalfox>​ yes, n/p, I need to work on the build too a bit
 +
 +[12:05:38] <​purplefox>​ ah... btw next monday and tuesday I will be in newcastle office meetings
 +
 +[12:05:47] <​temporalfox>​ purplefox when do you think hazelcast will be fixed ?
 +
 +[12:05:52] <​temporalfox>​ purplefox who is supposed to do the release ?
 +
 +[12:06:00] <​temporalfox>​ because you are :-)
 +
 +[12:06:10] <​pmlopes>​ yes, i just need some discussion on the auth
 +
 +[12:06:38] <​purplefox>​ hazelcast.. they are still investigating,​ so I don't know... but we have a workaround that seems to work, so I am not too worried for now
 +
 +[12:06:48] <​purplefox>​ i am fairly confident it will be fixed before the final release
 +
 +[12:07:06] <​temporalfox>​ purplefox it just that it makes the build fail when releasing :-)
 +
 +[12:07:38] <​temporalfox>​ if neceesary we'll exclude that test for the release
 +
 +[12:07:40] <​purplefox>​ temporalfox:​ do you know what doesn'​t build?
 +
 +[12:07:46] <​purplefox>​ (which test)
 +
 +[12:07:56] <​temporalfox>​ purplefox what do you mean
 +
 +[12:08:17] <​purplefox>​ sorry, thought you said it stops the build from working.. :)
 +
 +[12:08:38] <​temporalfox>​ purplefox I do hae a vertx-aggregator project I use for rleease
 +
 +[12:08:42] <​temporalfox>​ that deploy all the modules
 +
 +[12:08:52] <​temporalfox>​ and the HZ makes this whole build fail :-)
 +
 +[12:09:10] <​purplefox>​ hmm, really? don't think that is related to that bug
 +
 +[12:09:24] <​purplefox>​ you mean the HZ test suite doesn'​t work for you?
 +
 +[12:09:38] <​cescoffier>​ for me it bocks (for ever)
 +
 +[12:09:48] <​temporalfox>​ purplefox yes
 +
 +[12:10:06] <​purplefox>​ ok. i'm not sure that is the same issue
 +
 +[12:10:28] <​purplefox>​ you are running OSX right?
 +
 +[12:10:43] <​purplefox>​ there are some multicast setup issues on OSX, iirc
 +
 +[12:10:44] <​temporalfox>​ yes
 +
 +[12:10:56] <​temporalfox>​ sometimes eventloop is blocked
 +
 +[12:11:30] <​temporalfox>​ and sometimes it fails with
 +
 +[12:11:30] <​temporalfox>​ [127.0.0.1]:​5701 [dev] [3.4] All migration tasks have been completed, queues are empty.
 +
 +[12:11:31] <​temporalfox>​ [127.0.0.1]:​5702 [dev] [3.4] Address[127.0.0.1]:​5702 is STARTED
 +
 +[12:11:31] <​temporalfox>​ java.lang.AssertionError:​ expected:<​[0,​ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
 +
 +[12:11:34] <​temporalfox>​ lot of numbers
 +
 +[12:11:36] <​purplefox>​ ok that's interestin.. can you take a copy of the stacktrace when that happens and add it is an issue on the vertx-haszelcast project?
 +
 +[12:11:41] <​temporalfox>​ ok
 +
 +[12:11:59] <​temporalfox>​ I do two issues
 +
 +[12:13:35] <​purplefox>​ ok great :)
 +
 +[12:13:46] <​cescoffier>​ it seems that the doc generator has some issues on {@code}
 +
 +[12:14:19] <​temporalfox>​ cescoffier that's post M6 priority
 +
 +[12:14:40] <​cescoffier>​ yes, just we should not forget
 +
 +[12:14:43] <​temporalfox>​ I would call that polish :-)
 +
 +[12:15:06] <​temporalfox>​ it's quite shiny though :-)
 +
 +[12:15:45] <​purplefox>​ pmlopes: i just remembered... you don't officially start until next week.. so of course anything you do is completely voluntary, no compulsion there :)
 +
 +[12:16:57] <​temporalfox>​ cescoffier started officially yesterday :-)
 +
 +[12:17:10] <​temporalfox>​ so we are good with him
 +
 +[12:17:31] <​cescoffier>​ :-)
 +
 +[12:20:52] <​pmlopes>​ yes, that is fine, about the auth, so lets agree to document that implementations will decide on the matching either string equality or wildcard and document that.
 +
 +[12:21:33] <​pmlopes>​ regarding the data model, should we stick to apache shiro user > role > permission (which is logical)
 +
 +[12:27:57] <​purplefox>​ pmlopes: right so that's the main question.. we could either stick with role/​permission or just use string like authority and for shiro it's prefixed with "​role:"​ or "​perm:"​
 +
 +[12:28:06] <​purplefox>​ (or suchlike)
 +
 +[12:28:58] <​purplefox>​ i'm not sure what is better... what is your opinion on this?
 +
 +[12:32:00] <​pmlopes>​ purplefox: spring security uses just a string (they call it authorities) but then they implement hasRole where they match against: ROLE_<​someString>,​ so i think they realized that they miss the role/​permission model and made it work with convention use of prefixes. We can make it explicit by keeping the role/​permission seperation but we need now to agree that a role is a property of a user and that a permission is a property of a rol
 +
 +[12:32:03] <​pmlopes>​ e, otherwise we end up with complex models where users can have also permissions and in that case when looking for permissions we need to look both on user and roles
 +
 +[12:32:19] <​pmlopes>​ and if we end that doing that we need to clarify how to handle overlaps
 +
 +[12:33:25] <​pmlopes>​ so in order to not break much of the existing code I would propose lets keep roles and permissions but make clear that a user has roles and a role has permissions,​ no user has permissions
 +
 +[12:34:23] <​purplefox>​ ok that seems sensible, so this becomes more of a documetation issue for us I guess?
 +
 +[12:35:07] <​pmlopes>​ yes and i need to adjust the jwt since the implementation treated roles and permissions as user properties instead of user > role > permission
 +
 +[12:36:17] <​purplefox>​ ok great. i'll also give you push/pull rights on the repos so you can make small changes directly
 +
 +[12:36:31] <​pmlopes>​ thanks!
 +
 +[12:37:20] <​purplefox>​ np
 +
 +[12:37:23] <​purplefox>​ that reminds me:
 +
 +[12:37:44] <​purplefox>​ cescoffier: pmlopes: can you also look at this if you haven'​t already
 +
 +[12:38:02] <​purplefox>​ https://​github.com/​vert-x3/​wiki/​wiki/​Development-Process
 +
 +[12:38:45] <​purplefox>​ TLDR; basically all changes need to be done via PR, unless they are small < 10 or 20 lines or so then you can do directly in master. everyone follows this including me and julien
 +
 +[12:39:12] <​purplefox>​ i think ur probably already familiar with this anyway
 +
 +[13:01:32] <​purplefox>​ cescoffier: pmlopes: i've added you both the committers list so you should have push/pull rights to most of the Vert.x official repos to make small changes. If you don't just ping me and I will sort it out :)
 +
 +[13:01:44] <​pmlopes>​ purplefox: currently I use git-flow, it works well with the whole PR and even integrates with maven
 +
 +[13:05:16] <​pmlopes>​ purplefox: about the PRs, we also have a cloudbees account, we could have it automatically building the the PRs and reporting a build status badge on the github page for each sub project. I currently do it at work and it quite nice since when reviewing PR i just look at the code and do not bother to see if it breaks the build
 +
 +[13:05:52] <​purplefox>​ pmlopes: that's a good idea
 +
 +[13:06:42] <​purplefox>​ out cloudbees ci is here https://​vertx.ci.cloudbees.com/​view/​vert.x-3/​
 +
 +[13:06:46] <​purplefox>​ s/out/our
 +
 +[13:06:57] <​cescoffier>​ yes, that would be great
 +
 +[13:07:11] <​purplefox>​ i can add you as admin if you send me your cloudbees email address you use for your account
 +
 +[13:08:58] <​cescoffier>​ BTW, for custom build, I've my own CI if we need (use it to test part of my code against non public TCK)
 +
 +[13:09:34] <​purplefox>​ ok, cool
 +
 +[13:12:56] <​purplefox>​ cescoffier: if you submit a PR for this page, we can get you up there on the team section too http://​vert-x3.github.io/​community/​
 +
 +[13:13:32] <​purplefox>​ https://​github.com/​vert-x3/​web-site/​blob/​master/​src/​site/​community/​index.html
 +
 +[13:17:04] <​cescoffier>​ ok will do
 +
 +[13:40:25] <​AlexLehm>​ purplefox: I have done some improvements to the tests of the mail module for the connection pool and I think I fixed one thread issue
 +
 +[13:41:53] <​purplefox>​ AlexLehm: ok great. do the tests all run through nicely now?
 +
 +[13:43:33] <​purplefox>​ temporalfox:​ julien, I'm adding an @Ignore to the MetricsContextTest for now in core, as it causes the test suite to hang for me
 +
 +[13:46:32] <​Narigo>​ cescoffier, pmlopes: Just wanted to say hi and great to see more people joining Vert.x officially :)
 +
 +[13:46:44] <​AlexLehm>​ currently one test fails on the jenkins, which didn't fail when i run the tests locally, everything else works
 +
 +[13:47:11] <​AlexLehm>​ it doesn'​t take so long anymore
 +
 +[13:48:19] <​AlexLehm>​ maybe the test doesn'​t make sense after all
 +
 +[13:48:42] <​purplefox>​ AlexLehm: in my experience when tests fail on CI but not locally it is often a timing issue, e.g. you are relying on things to complete in a certain time, and problem is CI can often be slow or subject to big pauses
 +
 +[13:49:18] <​purplefox>​ so basically non deterministic tests, e.g. ones which rely on timing are usually a bad idea
 +
 +[13:49:30] <​purplefox>​ e.g. you wait 250 ms and expect something to happen
 +
 +[13:51:28] <​AlexLehm>​ i think i am doing a race between the two mail send operations and that is apparently not working everywhere
 +
 +[13:51:58] <​pmlopes>​ purplefox my cloudbees username is pmlopes
 +
 +[13:52:35] <​AlexLehm>​ should I remove the tests with Pool*Test?
 +
 +[13:52:56] <​AlexLehm>​ the real ConnectionPool tests are working now
 +
 +[13:53:54] <​AlexLehm>​ or direct ConnectionPool I should say
 +
 +[13:56:07] <​purplefox>​ AlexLehm: what's the difference?
 +
 +[13:56:41] <​cescoffier>​ thanks Narigo
 +
 +[13:56:54] <​AlexLehm>​ the files called Pool*Test create a MailClient and try to test the pool and the ConnectionPool tests create a ConnectionPool and operate on the SMTPConnection
 +
 +[13:56:59] <​AlexLehm>​ (and do not really send a mail)
 +
 +[13:58:17] <​pmlopes>​ Narigo: thanks!
 +
 +[13:58:19] <​AlexLehm>​ using the MailClient requires some assumptions about the operation that are not always correct I think (which I didn't realize when I started writing the tests)
 +
 +[13:59:30] <​purplefox>​ pmlopes: i think i need your email address to add you as a user
 +
 +[13:59:44] <​pmlopes>​ pmlopes at gmail dot com
 +
 +[14:00:25] <​purplefox>​ pmlopes: ok, done :)
 +
 +[14:01:02] <​purplefox>​ AlexLehm: not sure what you mean by "using the MailClient requires some assumptions about the operation that are not always correct"​
 +
 +[14:01:26] <​purplefox>​ if the tests are invalid.. the of course remove them
 +
 +[14:01:43] <​purplefox>​ but generally i am not a fan of fine grained unit tests
 +
 +[14:03:18] <​AlexLehm>​ ok
 +
 +[14:06:43] <​AlexLehm>​ purplefox: i will remove the tests this evening
 +
 +[14:07:23] <​purplefox>​ AlexLehm: ok thanks. bear in mind that the deadline is pretty close now
 +
 +[14:14:01] <​AlexLehm>​ i am not sure if we have enough time to get this reviewed
 +
 +[14:16:15] <​purplefox>​ AlexLehm: well it won't get reviewed unless you submit a PR ;) So.. if you think it is ready then please submit a PR. But prerequisite for this is for all the tests to pass, and Docs to be done :)
 +
 +[14:21:36] <​AlexLehm>​ the old pr is still open, i can close the pr and create a new one
 +
 +[14:22:26] <​purplefox>​ yes, please. I don't know when you are ready ;) as I am not psychic, so you need to signal this to me somehow
 +
 +[14:25:15] <​AlexLehm>​ ok, will do
 +
 +[14:26:04] <​AlexLehm>​ we need a psychic messenger service
 +
 +[14:27:15] <​purplefox>​ lol
 +
 +[14:42:03] <​rajith>​ temporal_: julien ?
 +
 +[14:42:21] <​temporal_>​ rajith hello
 +
 +[14:42:42] <​rajith>​ temporal_: good morning
 +
 +[14:42:46] <​rajith>​ temporal_: would you know where the source docs for the following https://​github.com/​eclipse/​vert.x/​tree/​master/​src/​main/​asciidoc/​java/​override comes from?
 +
 +[14:43:14] <​rajith>​ temporal_: just want to find a way to keep the docs organized as it's hard to put everything inside package-info
 +
 +[14:43:37] <​temporal_>​ override is only for vertx core
 +
 +[14:43:53] <​rajith>​ temporal_: :(
 +
 +[14:43:56] <​temporal_>​ do you have thuch doc ?
 +
 +[14:43:59] <​temporal_>​ that much
 +
 +[14:44:37] <​rajith>​ temporal_: kind of ... I have more additions to make
 +
 +[14:45:06] <​temporal_>​ why don't you just add it at the bottom :-) ?
 +
 +[14:45:10] <​rajith>​ temporal_: I've checked in a fairly recent version. You can have a quick look when u get a chance
 +
 +[14:45:35] <​rajith>​ temporal_: what do u mean by 'add it at the bottom'​ ?
 +
 +[14:45:58] <​rajith>​ temporal_: u mean put everything in package-info ? :p
 +
 +[14:47:52] <​temporal_>​ yes
 +
 +[14:49:35] <​rajith>​ temporal_: that's what I have done. I will leave it as it is until we find a better way.
 +
 +[14:52:40] <​temporal_>​ rajith yes good idea
 +
 +[14:53:14] <​purplefox>​ rajith: did you see all the recent threads on the google groups about client refactorings?​ and how we are moving from service->​ client?
 +
 +[14:55:23] <​rajith>​ purplefox: yes I saw that
 +
 +[14:55:42] <​rajith>​ purplefox: could I tackle any of those changes after the milestone release?
 +
 +[14:56:49] <​rajith>​ purplefox: Is mongo and jdbc a model to follow? I noticed you have already some changes there
 +
 +[14:58:14] <​purplefox>​ yeah, so mongo, jdbc, redis etc are already following this model
 +
 +[15:00:04] <​rajith>​ purplefox: conceptually I don't see any of the methods changing as it's more or less like a client.
 +
 +[15:00:23] <​rajith>​ purplefox: I guess what's needed is to change the '​name'​ to adhere to the new model.
 +
 +[15:15:52] <​aesteve>​ hi everyone :) and welcome to the new people !
 +
 +[15:24:32] <​purplefox>​ temporal_: sendNoContext - is this a test you added recently?
 +
 +[15:25:21] <​temporal_>​ purplefox no
 +
 +[15:25:35] <​temporal_>​ ah
 +
 +[15:25:54] <​purplefox>​ it has a strange naming (no testXXX)
 +
 +[15:25:56] <​temporal_>​ now you're saying it
 +
 +[15:26:15] <​temporal_>​ indeed it's me
 +
 +[15:26:21] <​rajith>​ purplefox: is this the link u were referring to https://​groups.google.com/​forum/#​!searchin/​vertx-dev/​service$20to$20client/​vertx-dev/​kd-P8yje_EQ/​RKJccqU7MXQJ ?
 +
 +[15:26:44] <​purplefox>​ nope
 +
 +[15:26:46] <​temporal_>​ it's the test that always use the same internal context for messages that' don't have a current context
 +
 +[15:26:47] <​purplefox>​ that's old
 +
 +[15:27:17] <​temporal_>​ https://​github.com/​eclipse/​vert.x/​commit/​b6ab4002bde85fb08fab6e72dbd929977ab30579
 +
 +[15:27:22] <​temporal_>​ it fails sometimes
 +
 +[15:28:10] <​temporal_>​ I'm gonig to execute again all the HZ tests on mac
 +
 +[15:28:15] <​temporal_>​ does it fail for you ?
 +
 +[15:29:38] <​purplefox>​ yes it's easy to reproduce with a repeat rule
 +
 +[15:29:50] <​purplefox>​ I.e. add this to HazelcastClustsredEventBusTest:​
 +
 +[15:29:50] <​purplefox>​ @Override
 +
 +[15:29:50] <​purplefox> ​  @Test
 +
 +[15:29:51] <​purplefox> ​  ​@Repeat(times = 100000)
 +
 +[15:29:51] <​purplefox> ​  ​public void sendNoContext() throws Exception {
 +
 +[15:29:51] <​purplefox> ​    ​super.sendNoContext();​
 +
 +[15:29:52] <​purplefox> ​  }
 +
 +[15:30:38] <​temporal_>​ is the test wrong ?
 +
 +[15:30:57] <​temporal_>​ (because the fix in EventBus is pretty trivial)
 +
 +[15:30:58] <​purplefox>​ No, but I wouldn'​t expect it to pass
 +
 +[15:31:10] <​temporal_>​ why ?
 +
 +[15:31:12] <​purplefox>​ unless you have added the code for the default context
 +
 +[15:31:32] <​temporal_>​ that was added
 +
 +[15:31:40] <​temporal_>​ +        };
 +
 +[15:31:40] <​temporal_>​ +        if (Vertx.currentContext() == null) {
 +
 +[15:31:40] <​temporal_>​ +          // Guarantees the order when there is no current context
 +
 +[15:31:40] <​temporal_>​ +          sendNoContext.runOnContext(v -> {
 +
 +[15:31:40] <​temporal_>​ +            subs.get(message.address(),​ resultHandler);​
 +
 +[15:31:40] <​temporal_>​ +          });
 +
 +[15:31:41] <​temporal_>​ +        } else {
 +
 +[15:31:41] <​temporal_>​ +          subs.get(message.address(),​ resultHandler);​
 +
 +[15:31:41] <​temporal_>​ +        }
 +
 +[15:32:21] <​temporal_>​ https://​github.com/​eclipse/​vert.x/​commit/​b6ab4002bde85fb08fab6e72dbd929977ab30579
 +
 +[15:44:51] <​purplefox>​ temporal_: looks like a race on the isInitialised on the ChoosableSet
 +
 +[15:45:06] <​purplefox>​ (if you comment out the setInitialised it passes)
 +
 +[15:45:27] <​temporal_>​ shave that yak :-)
 +
 +[15:45:35] <​rajith>​ purplefox: I have a hard time finding that you mentioned about. If you could pls point me to it :)
 +
 +[15:45:41] <​temporal_>​ my machine is still running HZ tests again
 +
 +[15:45:53] <​rajith>​ purplefox: I meant the thread :p
 +
 +[15:46:44] <​purplefox>​ rajdavies: search for "​client service"​ on the google group. it is the 3rd result returned
 +
 +[15:47:25] <​purplefox>​ https://​groups.google.com/​forum/?​fromgroups#​!searchin/​vertx/​client$20service/​vertx/​pK_Tcem4MXs/​ns-M_pKuVWIJ
 +
 +[15:49:54] <​rajith>​ purplefox: thanks
 +
 +[15:51:04] <​purplefox>​ and it's the first result (after the google group itself) on google ;)
 +
 +[15:56:37] <​rajith>​ purplefox: only if u know what to search for :p
 +
 +[15:58:02] <​purplefox>​ rajith: well the words "​client"​ and "​service"​ take you straight there ;) but don't worry I quite understand it's a pain with all the refactorings going on but unfortunately that is the nature of the beast right now as we're in a mad development phase, but everything will settle down after 3.0 :)
 +
 +[15:58:15] <​purplefox>​ so no hard feelings, i'm just teasing you ;)
 +
 +[15:59:22] <​rajith>​ purplefox: not at all sir .. I will make every effort to conform to the new model. I don't see many disruptive changes on my end.
 +
 +[16:02:44] <​purplefox>​ temporal_: would you like me to take a look at that test or are you ok with it?
 +
 +[16:03:17] <​temporal_>​ purplefox you mean the choosable set race ?
 +
 +[16:03:41] <​temporal_>​ purplefox I can have a look and ping you if I realize I'm not able to reproduce
 +
 +[16:03:47] <​temporal_>​ I mean fix
 +
 +[16:03:51] <​purplefox>​ ok
 +
 +[16:04:22] <​purplefox>​ i'm pretty sure it's sometihng to do with the caching of the results as if you comment out the caching it works for me
 +
 +[16:05:16] <​temporal_>​ which caching ?
 +
 +[16:06:05] <​temporal_>​ entries.isInitialised() / sids.setInitialised();​ ?
 +
 +[16:07:08] <​temporal_>​ indeed it passes
 +
 +[16:16:45] <​purplefox>​ temporal_: do you have a link to the reproducers you created for the executeOnIO issues?
 +
 +[16:17:36] <​temporal_>​ so
 +
 +[16:17:47] <​temporal_>​ there is a branch with 3 test cases
 +
 +[16:17:57] <​temporal_>​ 1 is not solved (websocket big block)
 +
 +[16:18:05] <​temporal_>​ 2 are tested and (according to me) fixed
 +
 +[16:18:29] <​temporal_>​ is this this branch : https://​github.com/​eclipse/​vert.x/​tree/​network-worker-bugs
 +
 +[16:18:43] <​temporal_>​ then I made another reproducer
 +
 +[16:19:01] <​temporal_>​ that reproduce same bug with websocket client
 +
 +[16:19:06] <​temporal_>​ that is more low level
 +
 +[16:19:16] <​temporal_>​ and use a TCP server to send an handshake to the client
 +
 +[16:19:17] <​temporal_>​ quickly
 +
 +[16:19:33] <​temporal_>​ I believe it's worth checking it works too
 +
 +[16:19:39] <​temporal_>​ it is in this  branch : https://​github.com/​eclipse/​vert.x/​tree/​client-worker-websocket-handshake-race-condition
 +
 +[16:21:49] <​purplefox>​ do you have a link to the actual tests, not the entire repo?
 +
 +[16:22:24] <​temporal_>​ ok
 +
 +[16:22:26] <​temporal_>​ one sec
 +
 +[16:22:36] <​temporal_>​ "let me use github for you"
 +
 +[16:23:58] <​purplefox>​ lol
 +
 +[16:24:36] <​purplefox>​ yeah i guess i could pull all branches and then do  a diff, but a link to the actual reproducer in the bug report would be quite helpful ;)
 +
 +[16:25:52] <​temporal_>​ here is one test
 +
 +[16:25:53] <​temporal_>​ https://​github.com/​eclipse/​vert.x/​commit/​5ba0d60301947a6305c19797fdcea702efe44cb8#​diff-04dadd1b91359310cc70281df3bc3b6bR1950
 +
 +[16:25:53] <​purplefox>​ "hey the test is somewhere in this repo, it's my fun game for the next 15 mins to find where is is ...."
 +
 +[16:26:47] <​temporal_>​ the trick is to drain the worker pool from the server
 +
 +[16:26:52] <​temporal_>​ I mean vertx
 +
 +[16:27:02] <​temporal_>​ so the server receives a netty event
 +
 +[16:27:07] <​temporal_>​ but has no worker to process it
 +
 +[16:27:27] <​temporal_>​ and then send a message
 +
 +[16:27:54] <​temporal_>​ when the message is processed the connection that is not yet in the connection map
 +
 +[16:27:59] <​temporal_>​ because it's done by the worker
 +
 +[16:28:09] <​temporal_>​ and so the buffer is lost
 +
 +[16:28:12] <​purplefox>​ ok... that commit, i can see it is correct without running it, so feel free to commit that to master :)
 +
 +[16:29:02] <​temporal_>​ there is one unsolved
 +
 +[16:29:03] <​temporal_>​ https://​github.com/​eclipse/​vert.x/​commit/​c04d33f3f66ea7f73f5f33a8f5d87475c4cc6a57#​diff-823a0f985a6c71bbfafac4ea06cbab71R1102
 +
 +[16:29:24] <​temporal_>​ because it involves the synchronized / big block in websocket lcient
 +
 +[16:29:55] <​temporal_>​ so if you fix this bug in this branch
 +
 +[16:30:01] <​temporal_>​ I think you can then merge the branch
 +
 +[16:33:17] <​rajith>​ temporal_: purplefox this is how the amqp docs look atm http://​people.apache.org/​~rajith/​vert.x/​docs/​java/​
 +
 +[16:33:51] <​rajith>​ purplefox: the advanced example uses the service API. I might as well convert it to the new "​client model" and complete the docs for that part.
 +
 +[16:34:11] <​rajith>​ purplefox: temporal_ that is the only missing part.
 +
 +[16:34:22] <​cescoffier>​ just for information,​ openshift provides java 7, not 8[unknown:​hellip]. (current), in 28 days, they provides a completely new openshift (docker based)
 +
 +[16:34:54] <​temporal_>​ cescoffier good to know
 +
 +[16:35:22] <​cescoffier>​ so, for now, we are a bit stuck
 +
 +[16:35:39] <​aesteve>​ cescoffier: just in case this might be helpful https://​gist.github.com/​aesteve/​50e366a2efd6571f414b
 +
 +[16:35:48] <​aesteve>​ (i faced the same issue some months ago)
 +
 +[16:36:00] <​cescoffier>​ cool ! Thanks
 +
 +[16:36:07] <​purplefox>​ cescoffier: interesting.. i suspect they are timing their release to Red hat summit
 +
 +[16:36:08] <​rajith>​ temporal_: btw I noticed that any formatting done inside a table is ignored (see the config section in the link I posted). Not sure if it's bug in the assiidoc generation or a bug on my part.
 +
 +[16:36:11] <​cescoffier>​ yes, we can provision the JVM ourself
 +
 +[16:36:20] <​purplefox>​ cescoffier: and we are releasing at the same time
 +
 +[16:37:26] <​purplefox>​ cescoffier: yeah i guess we do that for now, we can also enquire internally to see if we can get early access to the new openshift
 +
 +[16:37:45] <​purplefox>​ temporal_: that test times out for me, as that what you get?
 +
 +[16:38:54] <​purplefox>​ rajith: the other thing for the client api.. .as it does not need to be proxygen any more it means it can be richer
 +
 +[16:40:44] <​temporal_>​ purplefox yes
 +
 +[16:40:54] <​temporal_>​ it cannot really fail
 +
 +[16:41:24] <​temporal_>​ I think it can only pass or timeout
 +
 +[16:43:12] <​rajith>​ purplefox: I went through the thread and the use cases I had in mind ... I think we can make the case for both a service and a client. The beauty of the current impl I have is, that you can get existing vertx apps and amqp apps to talk without much changes in code
 +
 +[16:44:18] <​rajith>​ purplefox: The bridge seems a very useful piece and the Service API was a really nice way to interact with it. But I do see the value of the "​client API"
 +
 +[16:44:34] <​rajith>​ purplefox: maybe AMQP is one case where you could have both. What do you think?
 +
 +[16:45:42] <​rajith>​ purplefox: I think advocated for both right at the beginning ;)
 +
 +[16:47:41] <​rajith>​ purplefox: I have examples (not in doc yet) which uses the service API to do the traditional publish/​consume from a message broker and the more modern peer-to-peer approach of communicating with other AMQP apps directly. The "​Client API" is great option for the former use case as there is no reason to really go through the bridge.
 +
 +[16:48:16] <​rajith>​ But for the latter use case I see both the '​service'​ approach and '​client'​ approach being useful.
 +
 +[16:49:53] <​rajith>​ purplefox: the bridge merely extends the Vert.x event-bus into the AMQP space. So a Verticle can communicate with an AMQP node as it's just another Verticle :)
 +
 +[16:50:32] <​purplefox>​ temporal_: did you see my message before about marking MetricsContextTest as Ignore?
 +
 +[16:50:55] <​purplefox>​ rajith: we will take a look before long, but we are just very overwhelmed with other  stuff at the moment
 +
 +[16:51:24] <​temporal_>​ purplefox yes
 +
 +[16:51:33] <​temporal_>​ purplefox but fixing this bug will fix the MetricsContextTest
 +
 +[16:51:44] <​temporal_>​ purplefox as they are just failing because of this
 +
 +[16:51:46] <​rajith>​ purplefox: I understand. Maybe after friday? I understand u are busy with the milestone release for this friday
 +
 +[16:53:02] <​temporal_>​ purplefox so about Hazelcast : the problem is that there are two kinds of tasks that go into AsyncMultiMap#​get
 +
 +[16:53:15] <​temporal_>​ the one that go in the executeBlockign and are serialized properly
 +
 +[16:53:32] <​temporal_>​ and the other that find the boolean and are executed directly (already in the context)
 +
 +[16:53:46] <​temporal_>​ so we endup with two ordered series
 +
 +[16:53:51] <​purplefox>​ right
 +
 +[16:53:59] <​temporal_>​ one suggestion I had
 +
 +[16:54:06] <​temporal_>​ was to do like CompletableFuture and such
 +
 +[16:54:21] <​temporal_>​ to have a List of actions on the ChoosableSet
 +
 +[16:54:34] <​temporal_>​ to reorder actions
 +
 +[16:54:39] <​temporal_>​ and use that list until it's not empty
 +
 +[16:54:58] <​temporal_>​ do you have a more trivial fix ?
 +
 +[16:55:10] <​purplefox>​ the trivial fix would be to always use executeBlocking
 +
 +[16:55:13] <​temporal_>​ yes
 +
 +[16:55:28] <​purplefox>​ but.. it's slow
 +
 +[16:55:30] <​purplefox>​ (er)
 +
 +[16:55:49] <​purplefox>​ you could keep an atomic count of outstanding executeblocking
 +
 +[16:56:07] <​purplefox>​ and use executeblocking only if count > 0
 +
 +[16:56:12] <​temporal_>​ yes
 +
 +[16:56:14] <​purplefox>​ but you have to be careful of races there
 +
 +[16:56:32] <​temporal_>​ the issue I think will be to block event loop thread
 +
 +[16:56:39] <​temporal_>​ well no
 +
 +[16:57:08] <​temporal_>​ I think we can remove the boolean initiliazed and have this count
 +
 +[16:57:22] <​temporal_>​ as having count > 0 means it's not initialized
 +
 +[16:57:28] <​temporal_>​ and use CAS operations
 +
 +[16:58:40] <​purplefox>​ hmm another thought is now to update the cache until the resultrHandler of the executeblocking
 +
 +[16:58:47] <​purplefox>​ and then should always be run on the callers context
 +
 +[16:58:53] <​purplefox>​ so it should be non racy
 +
 +[16:59:20] <​temporal_>​ I did that first
 +
 +[16:59:40] <​temporal_>​ I did that
 +
 +[16:59:41] <​temporal_>​ , ar -> {
 +
 +[16:59:41] <​temporal_> ​        if (ar.succeeded()) {
 +
 +[16:59:41] <​temporal_> ​          ​ChoosableSet<​V>​ sids = ar.result();​
 +
 +[16:59:41] <​temporal_> ​          ​sids.setInitialised();​
 +
 +[16:59:41] <​temporal_> ​          ​resultHandler.handle(Future.succeededFuture(sids));​
 +
 +[16:59:41] <​temporal_> ​        } else {
 +
 +[16:59:43] <​temporal_> ​          ​resultHandler.handle(Future.failedFuture(ar.cause()));​
 +
 +[16:59:43] <​temporal_> ​        }
 +
 +[16:59:43] <​temporal_> ​      }
 +
 +[16:59:47] <​temporal_>​ that fixes some order
 +
 +[16:59:53] <​temporal_>​ but we still endup with two series
 +
 +[16:59:59] <​purplefox>​ yeah
 +
 +[17:00:01] <​temporal_>​ the very first invocation is always first
 +
 +[17:00:12] <​temporal_>​ but the pending are interveaved
 +
 +[17:00:15] <​temporal_>​ interleaved
 +
 +[17:08:47] <​purplefox>​ temporal_: I'm trying to understand the sequence of actions that make the websocket context test fail... I understand from you this is because the netty stack is changed, but do you have something a bit more specific?
 +
 +[17:09:06] <​temporal_>​ yes
 +
 +[17:09:15] <​temporal_>​ let me find that back in my memory for you
 +
 +[17:10:55] <​temporal_>​ one way to find out is to set a breakpoint in Netty stack
 +
 +[17:11:34] <​temporal_>​ there is also this test I wrote https://​github.com/​eclipse/​vert.x/​commit/​7862e3f22da716f73ff515af02e8fd9644cc9dc9
 +
 +[17:11:40] <​temporal_>​ that reproduce the same bug
 +
 +[17:12:12] <​temporal_>​ what is does : send in one buffer the handshake + a buffer to the client
 +
 +[17:12:18] <​purplefox>​ i have a reproducer working. what I don't quite understand right now, is why the issue occurs
 +
 +[17:12:56] <​temporal_>​ yes it's tricky
 +
 +[17:13:02] <​temporal_>​ I'm looking for the class
 +
 +[17:15:39] <​temporal_>​ so in ClientConnection#​channelRead
 +
 +[17:15:49] <​temporal_>​ we do have
 +
 +[17:15:50] <​temporal_>​ handshakeComplete(ctx,​ response);
 +
 +[17:15:55] <​temporal_>​ that modifies the Netty stack
 +
 +[17:16:03] <​temporal_>​ to add the correct websocket protocol decoder
 +
 +[17:16:19] <​temporal_>​ and this protocol decoder arrives after the buffer is received as it is executed in the worker
 +
 +[17:16:30] <​temporal_>​ and the websocket frame is just ignored
 +
 +[17:17:13] <​temporal_>​ this happens when the message is handled by netty before the worker thread process the lambda of executeFromIO
 +
 +[17:18:01] <​temporal_>​ as far as I remember it happens in "​handshaker.finishHandshake(channel,​ response);"​
 +
 +[17:18:49] <​temporal_>​ Netty'​s WebSocketClientHandshaker finishHandshake method
 +
 +[17:18:56] <​temporal_>​ modifies the stack
 +
 +[17:18:59] <​temporal_>​ p.replace(ctx.name(),​ "​ws-decoder",​ newWebsocketDecoder());​
 +
 +[17:19:48] <​purplefox>​ ok, so there is already a mechanism there to buffer messages that arrive
 +
 +[17:19:57] <​purplefox>​ buffered.add(msg);​
 +
 +[17:20:16] <​purplefox>​ maybe an easy fix would be to remove that outside of the executeonIo block
 +
 +[17:20:33] <​temporal_>​ I missed that one :-)
 +
 +[17:20:35] <​purplefox>​ the handshaker/​handshaking flag would need to be removed too
 +
 +[17:20:40] <​purplefox>​ s/​removed/​moved
 +
 +[17:20:48] <​temporal_>​ my fix was to move everything outside of executeFromIO
 +
 +[17:21:04] <​temporal_>​ and only keep the handler callback inside
 +
 +[17:21:12] <​temporal_>​ to the client handlers
 +
 +[18:11:16] <​purplefox>​ temporal_: i'm splitting vertx-auth into maven submodules and I'm getting a codegen error:
 +
 +[18:11:17] <​purplefox>​ Could not generate model for io.vertx.ext.auth.jdbc:​ A module cannot be nested inside another module
 +
 +[18:11:20] <​purplefox>​ any ideas?
 +
 +[18:24:59] <​purplefox>​ temporal_: ok, it seems i can't have a package-info in one package and more package-infos in subpackages :(
 +
 +[18:40:00] <​temporal_>​ purplefox this is a codegen problem
 +
 +[18:40:04] <​temporal_>​ not a doc problem
 +
 +[18:40:17] <​temporal_>​ you need to remove a @GenModule annotation that you forgot
 +
 +[18:40:37] <​temporal_>​ that's the annotation that generates JS modules
 +
 +[18:40:39] <​temporal_>​ and ruby modules
 +
 +[18:40:47] <​temporal_>​ (so it does not make sense to have such nested modules)
 +
 +[18:41:04] <​purplefox>​ where do i remove it from?
 +
 +[18:41:20] <​temporal_>​ look for @GenModule
 +
 +[18:41:30] <​temporal_>​ in package-info.java
 +
 +[18:41:45] <​purplefox>​ i've done a search but they all look ok to me
 +
 +[18:41:46] <​temporal_>​ for instance
 +
 +[18:42:00] <​temporal_>​ push it somewhere and I'll look at it tonight
 +
 +[18:42:06] <​temporal_>​ I need to go soon
 +
 +[18:42:13] <​purplefox>​ i'm trying to understand ​ the restriction
 +
 +[18:42:28] <​purplefox>​ so now we have io.vertx.auth - which contains the common auth interfaces
 +
 +[18:42:43] <​purplefox>​ and we have, for example, io.vertx.auth.jdbc which contains the jdbc implementation
 +
 +[18:42:55] <​purplefox>​ and they both have  package-info for their docs
 +
 +[18:42:56] <​temporal_>​ https://​github.com/​vert-x3/​vertx-codegen/​blob/​master/​src/​main/​java/​io/​vertx/​codegen/​CodeGen.java#​L156
 +
 +[18:43:08] <​purplefox>​ not sure why this doesn'​t make sense
 +
 +[18:43:10] <​temporal_>​ it's a codgen failure
 +
 +[18:43:25] <​temporal_>​ not sure why it's related to doc
 +
 +[18:43:31] <​temporal_>​ I need to go :-)
 +
 +[18:43:38] <​purplefox>​ ok, i don't understand
 +
 +[18:43:53] <​temporal_>​ push it somewhere and I try to understand later
 +
 +[18:44:00] <​temporal_>​ just send me a link in a mail
 +
 +[18:44:42] <​purplefox>​ ok, i don't understand why we make the restriction
 +
 +[18:44:57] <​temporal_>​ because ​ @GenModule generates a JavaScript
 +
 +[18:44:58] <​temporal_>​ module
 +
 +[18:45:06] <​purplefox>​ it's seems quite ok to me to have one package with docs and a subpackage with docs too
 +
 +[18:45:14] <​temporal_>​ but that's a codegen failure
 +
 +[18:45:22] <​temporal_>​ I htink it works fine with doc
 +
 +[18:45:29] <​temporal_>​ so this error does not make sense to me
 +
 +[18:45:33] <​temporal_>​ that's why I want to look at it :-)
 +
 +[18:45:51] <​purplefox>​ if i rename the packages so there is a flat hierarchy it works fine
 +
 +[18:46:57] <​temporal_>​ do you have nested @GenModule ?
 +
 +[18:47:07] <​temporal_>​ because this is only that triggers this
 +
 +[18:47:12] <​temporal_>​ if not , there is a bug
 +
 +[18:47:23] <​temporal_>​ anyway, need to disconnect and reconnect later
 +
 +[18:50:14] <​jua03>​ hi!, is there any "​3.0.0"​ compatible gradle template out there?
 +
 +[18:50:45] <​jua03>​ everything I seem to find is 2.x and somehow different :)
 +
 +[18:55:11] <​purplefox>​ ?
 +
 +[20:19:53] <​purplefox>​ pmlopes: hi paulo - one thing i noticed is i get lots of NPEs when running the JWT auth tests, but they all pass ok. Is this deliberate?
 +
 +[20:39:05] <​pmlopes_>​ purplefox: please read the following issue: https://​github.com/​vert-x3/​vertx-auth/​issues/​16
 +
 +[20:42:36] <​purplefox>​ pmlopes: i'm not sure i understand the logic in your example
 +
 +[20:43:23] <​purplefox>​ pmlopes: i can see the value in having a simple isPermitted(),​ that's fine. But I can't see why the current implementation is wrong...
 +
 +[20:44:22] <​purplefox>​ if you want to know is Paulo can push to production why is the following not sufficient? :
 +
 +[20:44:30] <​purplefox>​ paulo.hasPermission("​push"​)
 +
 +[20:44:45] <​pmlopes_>​ because there is no context push can be either from dev or devops
 +
 +[20:45:37] <​purplefox>​ not sure i follow...
 +
 +[20:46:02] <​purplefox>​ isn't it up to the implementation to work this out?
 +
 +[20:46:42] <​purplefox>​ for example the jdbc impl does a join between user / user_roles / roles_permissions to get the set of permissions for the user
 +
 +[20:48:30] <​pmlopes_>​ ok let me use some json {roles: {dev: [push], devops: [read]}} this is the data model graph however from the auth api we do: user.hasPermission("​push"​),​ since there is context we don't know if we should read the "​push"​ from dev role or devops role
 +
 +[20:48:47] <​pmlopes_>​ {roles: {dev: [push], devops: [read, push]}}
 +
 +[20:49:05] <​pmlopes_>​ in the last example which permission "​push"​ is the correct one?
 +
 +[20:49:18] <​purplefox>​ the implementation should calculate the set of permissions by traversing the graph of roles that the user has
 +
 +[20:49:30] <​pmlopes_>​ and from the first we cannot assume just becaus i can push it is the devops one
 +
 +[20:50:19] <​purplefox>​ are you saying there are two different permissions both called "​push"?​
 +
 +[20:50:44] <​pmlopes_>​ yes, that is a fair assumtion, think of "​read"​ is can be applied to many roles
 +
 +[20:51:00] <​purplefox>​ i think the assumption is that the permission name is globally unique
 +
 +[20:52:03] <​purplefox>​ otherwise the whole role/​permissions model doesn'​t really work as you'd have to prefix the permision with the role every time
 +
 +[20:52:17] <​pmlopes_>​ ok, but if you do have unique permissions they are explicit and i would say the role is just noise, for example in my case it would be devops_push,​ dev_push, devops_read
 +
 +[20:52:19] <​purplefox>​ which would be kind of pointless, then you'd have just a roles model really
 +
 +[20:52:31] <​pmlopes_>​ exactly :)
 +
 +[20:52:55] <​purplefox>​ but the value in a roles/​permissions model is it allows you to group permissions
 +
 +[20:53:13] <​pmlopes_>​ now we can call it roles, permissions or authorities,​ after reading the apache shiro docs today i kind of like the hasPermission
 +
 +[20:53:45] <​purplefox>​ my 2c on this is.. a standard roles/​permissions model like we currently have is fine.. IF you like roles/​permisions models ;)
 +
 +[20:53:54] <​purplefox>​ but I agree that a simple isPermitted is more flexible
 +
 +[20:54:13] <​purplefox>​ and allows us to support basically anything
 +
 +[20:54:19] <​purplefox>​ e.g. hierarchies and prefixes etc etc
 +
 +[20:54:59] <​pmlopes_>​ well we can make it like in string, so in spring they have the strings and then there is a helper hasRole() which just filters the authorities based on a prefix
 +
 +[20:54:59] <​purplefox>​ so I like your proposal. but I just didn't agree the current roles/​permission is broken ;) basically
 +
 +[20:55:36] <​pmlopes_>​ ok, i will be more positive with my comments :)
 +
 +[20:56:33] <​purplefox>​ i think it makes sense to make the string meaning opaque as you suggested :)
 +
 +[20:56:39] <​purplefox>​ so... do you want to implement this? ;)
 +
 +[20:57:36] <​pmlopes_>​ yes, sure, but i cannot promise that it will be ready thursday :)
 +
 +[20:57:43] <​pmlopes_>​ but next week for sure!
 +
 +[20:58:07] <​purplefox>​ we would need it done before monday as that's when julien will do the release
 +
 +[20:58:48] <​pmlopes_>​ ok, i think i can make it.
 +
 +[20:58:56] <​pmlopes_>​ deal!
 +
 +[20:59:27] <​purplefox>​ awesome, thanks paulo
 +
 +[20:59:49] <​purplefox>​ tbh i don't think it's a very big change as the change are isolated to vertx-auth and vertx-web
 +
 +[21:00:17] <​pmlopes_>​ I will keep hasPermission and modify hasRole for filtering on on a pattern so we don't change the API
 +
 +[21:04:22] <​purplefox>​ pmlopes: why do we need to keep the current API?
 +
 +[21:06:28] <​purplefox>​ it seems to me that if we think isPermitted() is better, why keep hasRole/​hasPermission at all?
 +
 +[22:01:37] <​AlexLehm>​ jua03, https://​github.com/​vert-x3/​vertx-examples
 +
 +[22:01:48] <​AlexLehm>​ the gradle-simplest should work as a gradle template
 +
 +[22:04:12] <​jua03>​ thanks... already tried, but probably was missing some point... probably something misconfigured in my side, will try again :)
 +
 +[22:16:17] <​AlexLehm>​ haven'​t tried gradle in a while though