Differences

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

Link to this comparison view

— irc:1444168800 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[00:21:34] *** ChanServ sets mode: +o purplefox
 +
 +[07:18:15] *** ChanServ sets mode: +o purplefox
 +
 +[08:01:37] <purplefox> temporalfox: morning
 +
 +[08:01:52] <temporalfox> purplefox hi
 +
 +[08:16:15] <purplefox> temporalfox: so are we ready to press the magic "do release" button? ;)
 +
 +[08:16:30] <temporalfox> yes, it should be ok
 +
 +[08:16:49] <temporalfox> there still the tcpbridge from pmlopes that is unmerged
 +
 +[08:16:55] <purplefox> maybe we should wait for clement/paulo as they might have something to do
 +
 +[08:16:58] <temporalfox> yes
 +
 +[08:17:06] <purplefox> i can see clement writing emails, so he is awake
 +
 +[08:17:07] <temporalfox> anyway I need to carry my daughter at school now :-)
 +
 +[08:17:20] <purplefox> sure, see you in a bit
 +
 +[09:12:03] <cescoffier> purplefox, temporalfox pmlopes : hi
 +
 +[09:12:07] <temporalfox> hi
 +
 +[09:12:12] <cescoffier> everything is ready from my side
 +
 +[09:12:26] <cescoffier> so, you can push the magic button
 +
 +[09:12:42] <cescoffier> I will then push docker, NPM and bower
 +
 +[09:12:58] <cescoffier> merge the example back (beofre I need to replace all SNAPSHOT
 +
 +[09:13:12] <cescoffier> and the web site
 +
 +[09:15:15] <temporalfox> I'm updating the magic aggregator
 +
 +[09:15:24] <temporalfox> then the release will take some time
 +
 +[09:15:29] <temporalfox> according to my DSL :-)
 +
 +[09:15:39] <temporalfox> I'll let you know when the staging repo is ok
 +
 +[09:15:47] <cescoffier> BTW, I've updated the breaking change list
 +
 +[09:15:51] <temporalfox> I  think I'm going to switch on my cellphone for the release
 +
 +[09:18:18] <purplefox> pmlopes: paulo are you ready?
 +
 +[09:19:37] <cescoffier> (so you have my go, switching to a coworking place right now, be back in 15 minutes)
 +
 +[09:19:49] <purplefox> temporalfox: are we also ready with respect to the Eclipse process? Have you done the special dance under the full moon, and sacrificed some chickens? ;)
 +
 +[09:20:02] <temporalfox> ecllipse process is green
 +
 +[09:20:09] <temporalfox> the PMC gave review approval monday
 +
 +[09:21:51] <temporalfox> I'll let you know when staging is done, you can go at the coffee shop meanwhile :-)
 +
 +[09:25:17] <purplefox> let's just wait for Paulo in case there is something he needs to do
 +
 +[09:37:41] <purplefox> temporalfox: the initial release part is staging right? If so I think we can just start that now then we don't waste time.
 +
 +[09:37:52] <temporalfox> I'm working on it
 +
 +[09:37:56] <temporalfox> but yes it's staging
 +
 +[09:38:16] <temporalfox> after staging anyone can verify the bits
 +
 +[09:38:57] <purplefox> temporalfox: i think we also need to force a CI run. some of the projects haven't run for days
 +
 +[09:39:05] <purplefox> e.g. codegen
 +
 +[09:39:27] <temporalfox> codegen hasn't been pushed for a while :-)
 +
 +[09:39:45] <temporalfox> I thought you added periodic build in jenkins
 +
 +[09:39:47] <temporalfox> like once a day
 +
 +[09:39:54] <purplefox> we should have at least one clear run from each project after the last commit
 +
 +[09:40:08] <purplefox> i guess this one got missed
 +
 +[09:40:32] <purplefox> even if there are no commits on the project we still need a clear run, as it might depend on something else that has changed
 +
 +[09:41:04] <temporalfox> at some point I had a Docker project
 +
 +[09:41:11] <temporalfox> that was cloning the whole stack
 +
 +[09:41:15] <temporalfox> and build everything
 +
 +[09:41:21] <temporalfox> so it had everything fresh
 +
 +[09:43:20] <purplefox> i noticed you just pushed a commit too on codetrans
 +
 +[09:45:11] <temporalfox> yes
 +
 +[09:45:20] <temporalfox> it was failing with openjdk latest
 +
 +[09:45:29] <temporalfox> because for some test we use nashorn objects
 +
 +[09:45:43] <temporalfox> I think we don't have the last oracle JDK in jenkins
 +
 +[09:45:52] <temporalfox> and / or
 +
 +[09:45:56] <temporalfox> some projects don't use it
 +
 +[09:46:43] <temporalfox> it's codetrans failure, so the tests that test the code translation for examples and docs :-)
 +
 +[09:46:49] <temporalfox> so nothing that will go in user bits :-)
 +
 +[09:47:30] <temporalfox> actually this project uses OracleJDK8
 +
 +[09:47:43] <temporalfox> and it's build periodically
 +
 +[09:47:53] <temporalfox> it's weird error wasn't reported
 +
 +[09:48:13] <purplefox> i've just set off a codegen build
 +
 +[09:48:30] <purplefox> after that i will setoff docgen too
 +
 +[09:49:07] <purplefox> also redis-client is disabled so i'll kick that off too
 +
 +[09:49:08] <temporalfox> btw I've started working on real codegen docs
 +
 +[09:49:25] <temporalfox> I've got some students yelling at me they don't understand it
 +
 +[09:49:46] <temporalfox> redis client auto self disabled I think
 +
 +[09:49:51] <temporalfox> it is just the last build
 +
 +[09:51:22] <temporalfox> and we should maybe drop the "vert.x3-mail-client-wip" ?
 +
 +[09:53:31] <purplefox> already done
 +
 +[09:54:46] <purplefox> the stack and examples-it projects now seem to build on CI
 +
 +[09:54:47] <purplefox> :)
 +
 +[09:56:12] <purplefox>  I also want to get a clear run of vertx-examples and examples-it as there was a commit in there too this morning
 +
 +[09:56:29] <temporalfox> what we should do
 +
 +[09:56:37] <temporalfox> it build vertx-examples with the staged released
 +
 +[09:56:43] <temporalfox> s/it/is
 +
 +[09:56:47] <temporalfox> 3.1.0
 +
 +[09:57:52] <purplefox> sec brb
 +
 +[10:01:45] <pmlopes> good morning guys, just had a bad night with sick kids :/ where can i help?
 +
 +[10:04:27] <purplefox> temporalfox: we have a failure on rx: https://vertx.ci.cloudbees.com/view/vert.x-3/job/vert.x3-rx/lastCompletedBuild/testReport/
 +
 +[10:04:39] <temporalfox> ok
 +
 +[10:06:54] <purplefox> looks like a race condition
 +
 +[10:07:30] <purplefox> i think you need another latch, let me fix it
 +
 +[10:08:23] <temporalfox> thanks
 +
 +[10:08:42] <temporalfox> where is the race happening ?
 +
 +[10:09:31] <purplefox> by looking at the code.. you await the latch
 +
 +[10:09:48] <purplefox> at that point called = 0
 +
 +[10:10:01] <purplefox> and then you pretty much immediately assert called to be 1
 +
 +[10:10:08] <purplefox> without waiting
 +
 +[10:10:17] <purplefox> so seems to be a race there
 +
 +[10:12:19] <purplefox> yep that fixes it
 +
 +[10:13:55] <temporalfox> oh right
 +
 +[10:13:59] <temporalfox> called.getAndIncrement();
 +
 +[10:14:00] <purplefox> fixed is oushed
 +
 +[10:14:01] <temporalfox> should be before
 +
 +[10:14:03] <temporalfox> action.call();
 +
 +[10:14:35] <temporalfox> thanks
 +
 +[10:15:39] <purplefox> btw, i noticed when I ran the build in vertx-rx it regened the docs and there were changes, which tells me we need to rebuild all the docs and commit them before release
 +
 +[10:16:50] <temporalfox> the doc in the src/main/asciidoc are not the one released
 +
 +[10:17:02] <temporalfox> I mean if it's not updated and commited
 +
 +[10:17:08] <temporalfox> the docs will still be good
 +
 +[10:17:58] <purplefox> as long as we rebuild it and commit it before tagging the release i guess that's ok
 +
 +[10:18:15] <purplefox> but whatever is tagged should contain the right generated docs
 +
 +[10:18:57] <temporalfox> when we do release and tag
 +
 +[10:19:08] <temporalfox> it should update the doc I think
 +
 +[10:19:21] <temporalfox> as the process does install / git add . / git commit
 +
 +[10:21:41] <purplefox> right, also other builds generate other stuff so the release process will need to be "two phase"
 +
 +[10:21:50] <purplefox> i.e.
 +
 +[10:21:51] <purplefox> checkout
 +
 +[10:21:52] <purplefox> build
 +
 +[10:21:55] <purplefox> commit
 +
 +[10:22:01] <purplefox> tag
 +
 +[10:22:04] <purplefox> release
 +
 +[10:22:28] <purplefox> e.g. the options classes are generated
 +
 +[10:24:17] <temporalfox> that is what is done by aggregator project
 +
 +[10:24:20] <temporalfox> https://github.com/vietj/vertx-aggregator
 +
 +[10:24:43] <temporalfox> I need to check that the "mvn io.vertx:releaser-maven-plugin:release"
 +
 +[10:24:58] <temporalfox> will commit the asciidoc
 +
 +[10:26:07] <temporalfox> it seems to do that
 +
 +[10:26:12] <temporalfox> https://github.com/vietj/releaser-maven-plugin/blob/master/src/main/java/io/vertx/releaser/ReleaseMojo.java
 +
 +[10:29:18] <purplefox> cool
 +
 +[10:29:35] <purplefox> on a different note i have found what looks like a big issue with the jgroups cluster manager
 +
 +[10:29:50] <temporalfox> do ewe need to withdraw ?
 +
 +[10:30:03] <purplefox> if it can't be fixed quickly then yes
 +
 +[10:30:07] <purplefox> I am trying to contact fabio
 +
 +[10:30:12] <temporalfox> ok let me know
 +
 +[10:30:51] <famarine> hi
 +
 +[10:32:16] <purplefox> famarine: hi fabio
 +
 +[10:32:33] <purplefox> famarine: ok so here's the issue we have
 +
 +[10:32:46] <temporalfox> Tim
 +
 +[10:32:53] <purplefox> i noticed that thread checking had been disabled in the jgroups clustering tests
 +
 +[10:32:54] <temporalfox> purplefox the vertx embedded maven plugin
 +
 +[10:33:01] <temporalfox> makes the thread blocked
 +
 +[10:33:06] <temporalfox> when it downloads mongo db :-)
 +
 +[10:33:13] <purplefox> temporalfox: one sec
 +
 +[10:33:15] <temporalfox> k
 +
 +[10:33:17] <famarine> yes that's right
 +
 +[10:33:21] <purplefox> temporalfox: can i just chat to fabio first :)
 +
 +[10:33:27] <temporalfox> yep
 +
 +[10:33:34] <famarine> a lot of communication happens in jgroups threding
 +
 +[10:33:40] <purplefox> famarine: and it makes a lot of tests fail
 +
 +[10:33:56] <purplefox> famarine: in particular, it seems callbacks are being executed on jgroups threads
 +
 +[10:34:04] <purplefox> famarine: which breaks the vert.x threading model
 +
 +[10:34:19] <famarine> ok
 +
 +[10:34:28] <purplefox> the test is JGroupsClusterWideMapTest
 +
 +[10:34:34] <famarine> so it needs a massive rework
 +
 +[10:35:12] <purplefox> i'm not sure it needs a massive rework
 +
 +[10:35:29] <purplefox> but it's a general rule that blocking stuff in vert.x should never be done on event loops
 +
 +[10:35:33] <famarine> Jgroups use is own thread groups
 +
 +[10:35:47] <purplefox> for example the get method:
 +
 +[10:35:48] <purplefox> @Override
 +
 +[10:35:48] <purplefox>   public void get(K k, Handler<AsyncResult<V>> handler) {
 +
 +[10:35:48] <purplefox>     handler.handle(Future.succeededFuture(map.get(k)));
 +
 +[10:35:48] <purplefox>   }
 +
 +[10:36:01] <purplefox> this simply calls the map.get() method (which blocks) on the vert.x event loop
 +
 +[10:36:13] <purplefox> and would need to be wrapped in an executeBlocking call
 +
 +[10:36:39] <famarine> wait
 +
 +[10:37:12] <famarine> that's a get from a local map
 +
 +[10:37:17] <famarine> no network involved
 +
 +[10:37:27] <famarine> do you want to wrap also those calls?
 +
 +[10:39:05] <purplefox> this is a cluster wide map
 +
 +[10:39:18] <famarine> I know
 +
 +[10:39:22] <famarine> it's a replicated map
 +
 +[10:39:52] <famarine> but I've a my local cache
 +
 +[10:40:14] <purplefox> tbh i don't have the time right now to debug it in detail, but the way it is right now we can't put it into the release :(
 +
 +[10:40:31] <famarine> ok
 +
 +[10:40:49] <famarine> sorry guys I've to leave
 +
 +[10:41:05] <famarine> we'll discuss it later on if you are available (next week)
 +
 +[10:41:10] <purplefox> ok thanks
 +
 +[10:42:05] <purplefox> temporalfox: ok, we're going to have to remove jgroups
 +
 +[10:42:09] <temporalfox> ok
 +
 +[11:43:45] <famarine> sorry I'm in a rush, but I've fixed the thread model issue, could you please review it? https://github.com/vert-x3/vertx-jgroups/pull/16
 +
 +[12:08:19] <Sticky> has there been any thought of adding something similar to TestScheduler in RX? http://reactivex.io/RxJava/javadoc/rx/schedulers/TestScheduler.html
 +
 +[12:09:10] <Sticky> allows you to make tests more reliable by manualy controling the clock that schedules events
 +
 +[12:14:58] *** ChanServ sets mode: +o temporalfox
 +
 +[12:39:55] <temporalfox> Sticky I believe this should be in vertx-core context scheduling itself
 +
 +[12:41:07] <Sticky> should be asin it is a good idea to do it, or it is already there?
 +
 +[12:44:15] <temporalfox> I don't know if it would be a good idea
 +
 +[12:44:31] <temporalfox> do you have a precise use case in mind ?
 +
 +[12:45:24] <Sticky> fire event x, assert event y happens on the event bus without waiting 10 seconds for a timeout and failing
 +
 +[12:46:23] <Sticky> so insted of waiting and timing out you just roll the clock forward 10 seconds, or until there are no more events to execute on the event loop
 +
 +[12:53:24] <Sticky> or doing tests on periodic/scheduled stuff, at the moment you would be required to scale down all of your times to fit within an acceptable test time period. With test timeout you can simply advance the clock at a faster rate
 +
 +[12:59:32] <temporalfox> so basically implement a kind of schedulable vertx
 +
 +[13:00:11] <temporalfox> at the same time, I think it's a good idea to write tests with the same vertx you would run in production
 +
 +[13:00:23] <temporalfox> given that vertx is very easy and cheap to start in tests
 +
 +[13:00:40] <temporalfox> I think you would lose value in your tests by doing such things
 +
 +[13:00:56] <temporalfox> i;e they would miss to capture some concurrency pitfalls that happens with real vertx
 +
 +[14:15:41] <amr> is it possible to set default web response headers?
 +
 +[14:15:53] <amr> content-type app/json & utf8 basically
 +
 +[14:17:00] <temporalfox> amr I think such feature was added recently in web
 +
 +[14:17:20] <temporalfox> amr https://github.com/vert-x3/vertx-web/commit/0c6e76991cd514692861538be0e0445cb1ccaa69
 +
 +[14:17:26] <temporalfox> not sure it's what you are looking for :-)
 +
 +[14:19:14] <pmlopes> @amr the commit @temporalfox posted relates to the vertx-eventbus.js client if you want to set default headers in your handlers i'd suggest you to create a handler and mount it on the router before your main handlers
 +
 +[14:20:06] <pmlopes> router.route().handler(ctx -> { ctx.response().putHeader("content-type", "application/json"); ctx.next(); });
 +
 +[14:54:04] <cescoffier> I've executed all our examples on 3.1.0
 +
 +[14:54:07] <cescoffier> everything is fine
 +
 +[14:57:41] <Sticky> temporalfox: maybe but 99% of the time in my experiance the concurrency issues discovered are with the testing framework and not the code
 +
 +[18:58:33] <purplefox> cescoffier: temporal_ pmlopes: how's it going guys?
 +
 +[18:58:43] <temporal_> almost done
 +
 +[18:58:49] <purplefox> great
 +
 +[18:58:50] <temporal_> tomorrow I'll finish with Eclipse
 +
 +[18:58:55] <cescoffier> purplefox: almnost done
 +
 +[18:59:01] <cescoffier> updating the web site
 +
 +[18:59:03] <temporal_> cescoffier is wrapping up website
 +
 +[18:59:19] <purplefox> ah, regarding the website - we should regenerate the contrinutor list if not done already
 +
 +[19:00:12] <purplefox> shall we announce tomorrow?
 +
 +[19:00:53] <purplefox> brb
 +
 +[19:01:23] <temporal_> announce whenver you want :-)
 +
 +[19:02:10] <cescoffier> purplefox: OK done
 +
 +[19:02:22] <cescoffier> so the web site already have 3.1.0 content
 +
 +[19:02:26] <cescoffier> (doc, download...)
 +
 +[19:02:51] <cescoffier> in the announce, you can link the release notes
 +
 +[19:31:43] <purplefox> cescoffier: temporal_ pmlopes: ok great work guys. I will probably announce tomorrow as I have to go to my daughters parents evening at school shortly
 +
 +[19:32:17] <pmlopes> i've tested the npm and it works fine
 +
 +[19:33:10] <pmlopes> for the announcement we should also include it on the blog
 +
 +[19:36:01] <purplefox> pmlopes: cescoffier temporal_ ; ok, if there's anything you want in the blog announcement that's not on the roadmap, can you send me an email with the links and I'll include it tomorrow morning
 +
 +[19:53:02] <amr> pmlopes: thx for the tip on the handlers :)
 +
 +[19:53:17] <pmlopes> sure! :)
 +
 +[19:57:43] <amr> what is the charset that .encodePretitly() uses?
 +
 +[19:59:06] <amr> i've got a bunch of utf8 strings going into mongo and coming back out... it appears to work ok, but i not sure if thats on purpose or by accident
 +
 +[19:59:11] <amr> i suspect the latter
 +
 +[20:02:36] <pmlopes> i think it is utf8 since that is the spec only supported encoding for json
 +
 +[20:06:42] <amr> ah
 +
 +[20:06:47] <amr> that's handy :)