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

[08:56:15] <minus> i'm looking for a vertx (2) project that has multiple verticles in one repo, using a settings.gradle, because i'm having troubles getting that right, can someone point me at one?

[09:13:19] <minus> found some, mod-redis and jca-adaptor have it

[10:11:14] <purplefox> morning temporalfox

[10:11:20] <temporalfox> hello purplefox

[10:11:23] <purplefox> temporalfox: could you take a look at ?

[10:11:32] <temporalfox> ok I will soon

[10:11:46] <purplefox> temporalfox: i need this merged before i can merge the other PRs in Apex and auth

[10:11:53] <temporalfox> purplefox ok

[10:11:58] <purplefox> temporalfox: it's a simple one, should only take 5 mins :)

[10:12:10] <temporalfox> could you validate the metrics one ?

[10:12:20] <temporalfox> I need it too for finishing the dropwizard tests :-)

[10:12:34] <purplefox> temporalfox: yeah, i have looked at it a few times.. i am still not sure about a few things, hence the delay

[10:12:47] <purplefox> i need to spend some time looking at it

[10:13:16] <temporalfox> purplefox this week I'll be travelling thursday afternoon and friday morning

[10:13:55] <purplefox> going somewhere nice?

[10:14:41] <temporalfox> Clermontferrand for a JUG session thurday night

[10:14:56] <temporalfox> I'll be working in the train though :-)

[10:16:04] <temporalfox> purplefox I found and fixed a couple of race conditions with worker servers

[10:16:17] <temporalfox> issue is that they are hard to reproduce and only happens with the entire test suite

[10:16:26] <temporalfox> (unlike the http server one)

[10:16:56] <temporalfox> I think there is one also with websocket server but I'm 100% sure

[10:17:48] <temporalfox>

[10:19:03] <temporalfox> the connection map is updated inside a lambda executed in lambda passed in the executeFromIO black

[10:19:05] <temporalfox> block

[10:19:12] <temporalfox> so sometimes later :-)

[10:19:39] <temporalfox> but I think it's only for handshake callback purpose

[10:19:53] <temporalfox> and the connectMap put can be moved out of the block like for others

[10:20:24] <purplefox> I think that is correct.

[10:21:17] <purplefox> what's the main thing you are working on at the moment?

[10:21:47] <temporalfox> I've finished the metrics in vertx core and yesterday more tests in dropwizard with multiple http servers scaled

[10:22:07] <temporalfox> I fixed a couple of bugs like this one and the ordering

[10:22:19] <purplefox> ok, what is remaining to do in metrics? we need to make sure this doesn't drag on too long.

[10:22:21] <temporalfox> I plan to do the List<@DataObject> today

[10:22:31] <temporalfox> metrics I think is honnestly done :-)

[10:22:42] <temporalfox> if not, I'll do it on my meta spare time :-)

[10:23:13] <purplefox> you have spare time? ;)

[10:23:19] <temporalfox> the meta one

[10:23:43] <temporalfox> I've improved some parts of ruby and finished the ruby docs

[10:23:53] <temporalfox> and also done with http server factory

[10:23:53] <purplefox> ok let's not forget that *everything* needs to be complete in about 1 week

[10:24:10] <temporalfox> ok so let's say I'm done with Ruby, metrics, http server factory

[10:24:25] <temporalfox> there is this List<@DataObject> todo

[10:24:27] <temporalfox> not difficult

[10:24:38] <purplefox> http service factory redirects and proxies are complete?

[10:24:54] <temporalfox> yes

[10:25:05] <purplefox> awesome

[10:25:06] <temporalfox> and there is a bintray section

[10:25:17] <temporalfox> in the doc

[10:25:33] <purplefox> vertx-stack is important

[10:25:59] <temporalfox> yes, I haven't had much feedback on it though

[10:26:24] <purplefox> i think you will just have to take an “executive decision” :)

[10:26:37] <temporalfox> yes

[10:26:43] <temporalfox> more can be added after

[10:26:58] <temporalfox> there is one thing I would like to have before release

[10:27:14] <temporalfox> some repos don't run tests if they are not executed from the main dir

[10:27:25] <temporalfox> because they use some hardcoded file path

[10:27:45] <temporalfox> for releasing I'm using a kind of uber pom.xml

[10:27:52] <temporalfox> that have all the projects as modules

[10:28:10] <temporalfox> so this prevnts testing all the modules

[10:28:16] <temporalfox> with this pom

[10:29:15] <purplefox> ok so i guess we'll have to fix those test suites too

[10:29:46] <purplefox> btw regarding amqp and rabbit - i suspect this will be dropped from the 3.0 release

[10:29:49] <purplefox> as they won't be ready

[10:29:51] <temporalfox> ok

[10:29:58] <temporalfox> how about jgroups ?

[10:30:00] <purplefox> so don't worry about them

[10:30:15] <purplefox> jgroups is optional, but doesn't need to be in a distro

[10:30:30] <temporalfox> ok

[10:32:15] <purplefox> i will spend some time next looking at your core PR

[10:44:49] <purplefox> temporalfox: regarding the PR for context changes.. i think it would make things a lot simpler if you said that metrics objects could be created or closed from any thread. i don't think that is an issue -it's only really the metrics *gathering* ops where it's important the same thread is used as those are the performance sensitive onies

[10:45:09] <purplefox> i think if you do that, the PR becomes a lot simpler :)

[10:45:23] <temporalfox> if I do that the PR only beocmes javadoc :-)

[10:45:30] <temporalfox> (well no there are missing closes)

[10:45:38] <temporalfox> I don't it much complicated though

[10:45:49] <purplefox> saying the metrics object must be created and closed on the same thread seems a bit unnecessary and anal

[10:46:09] <purplefox> i think the event bus registration changes are not related to closing metrics

[10:46:53] <purplefox> also closing metrics on a context might sometimes be problematic as often things are closed when the system shuts down, so they might never be run

[10:47:55] <temporalfox> so basically I should not check thread/context in tests

[10:48:01] <temporalfox> and remove the runOnContext

[10:48:11] <temporalfox> but keep the closes that were missing (bugs)

[10:48:33] <purplefox> i think it's ok to check contextx for metrics gathering, but for creation/close it seems unnecessary to me (what does this add?) and adds extra complexity

[10:48:41] <temporalfox> ok

[10:49:46] <temporalfox> I see

[11:13:27] <aesteve> hi everyone :)

[11:14:19] <aesteve> just something : I think I've run into a bug in RedisClient but I'm not sure if I did something wrong… so here is the bug report :

[11:27:36] <temporalfox> aesteve hi

[11:29:07] <aesteve> hi :)

[11:29:53] <purplefox> temporalfox: i think it is time to rename apex… any last thoughts?

[11:30:07] <temporalfox> purplefox vertx-web seems to do the job

[11:30:13] <temporalfox> and everyone seems to agree

[11:30:17] <purplefox> +1 i think it's ok too

[11:30:24] <purplefox> well _most_ people agree

[11:30:30] <temporalfox> yes :-)

[11:30:39] <purplefox> but you can't always please everyone

[14:50:11] <D-Spair> FYI: For anyone interested in helping, I am writing an SSH client implementation for Vert.x 3.0.0…

[14:50:49] <D-Spair> I plan to implement without Rx initially, and we can add Rx in a later iteration.

[14:51:37] <D-Spair> My use case is to be able to Pump data from a websocket to an SSH channel and vice-versa.

[14:51:58] <D-Spair> I am also working on an SCPClient as part of the same module

[14:52:20] <aesteve> D-Spair: you're using jsch ?

[14:52:28] <D-Spair> The SCPClient CAN use the same JSch Session object if there is an existing SSH Session, otherwise it will form a new session.

[14:52:34] <D-Spair> aesteve: Yep

[14:52:52] <aesteve> good luck :\ sometimes it can be absolutely awful to deal with

[14:52:56] <D-Spair> I will have to write my own reactor for the Input/Output streams and do my own thread handling.

[14:53:30] <D-Spair> Lots of “synchronize” blocks.

[14:53:47] <D-Spair> Unless someone knows of a JSch implementation which uses Netty?

[14:56:21] <D-Spair> Eventually, I'd like to see a Netty based port of JSch, but that would be a life's work.

[15:25:38] <purplefox> temporalfox: hi

[15:25:45] <temporalfox> purplefox hey

[15:26:07] <purplefox> temporalfox: i just noticed you merged that PR about contexts.. i wasn't finished reviewing it yet :)

[15:26:14] <temporalfox> oh

[15:26:14] <purplefox> temporalfox: also, it causes the test suite to hang on my machine

[15:26:16] <temporalfox> sorry

[15:26:26] <temporalfox> what does hang ?

[15:26:39] <purplefox> testHttpClientWebsocketWorker

[15:26:52] <temporalfox> I've got this one hanging too sometimes

[15:26:58] <temporalfox> I'm trying to find out

[15:27:07] <temporalfox> in my mahcine it happens only with full test suite

[15:27:11] <temporalfox> and 1 times of 10

[15:27:16] <temporalfox> (found out after merging)

[15:27:34] <temporalfox> on my mahcine I also have

[15:27:36] <temporalfox> before

[15:27:43] <temporalfox> NetTest#testWorker hanging sometimes

[15:27:46] <temporalfox> do you have it ?

[15:28:01] <temporalfox> NetTest#testInWorker

[15:28:18] <temporalfox> I updated a couple of issues with workers

[15:28:22] <temporalfox> and now it seems gone

[15:30:50] <purplefox> can we just revert the PR for now?

[15:31:08] <temporalfox> yes

[15:31:15] <temporalfox> the whole PR ?

[15:31:20] <temporalfox> or can you just comment the test ?

[15:31:20] <purplefox> yes please

[15:31:29] <temporalfox> I think that it's not realted to the changes I did

[15:31:32] <purplefox> well it needs to finish review as well

[15:31:34] <temporalfox> but rather is already here

[15:31:47] <purplefox> trouble is, this is stopping me from doing other stuff in core as I can't run the test suite

[15:32:09] <temporalfox> I will revert all commits

[15:32:13] <temporalfox> including the fixes I did for worker

[15:38:41] <temporalfox> purplefox it is reverted

[15:39:31] <purplefox> thanks

[15:40:42] <temporalfox> I've done a new branch for this mass revert, the previous PR was not usable anymore

[15:47:30] <temporalfox> I reverted another commit I forgot, please update @purplefox

[15:56:26] <aesteve> temporalfox: does varargs translate through codegen ? or is it forbidden ?

[15:56:29] <temporalfox> aesteve no they don't

[15:56:58] <aesteve> ok thanks

[15:57:30] <aesteve> so in this case whats the favorite pattern ? List<> ? Collection<> ?

[15:57:45] <temporalfox> List is supported

[15:57:45] <temporalfox> not Collection

[15:57:48] <temporalfox> List or Set

[15:57:53] <aesteve> nvm anyway I need ordering

[15:57:55] <aesteve> sry

[15:58:56] <aesteve> and what about name-clashing ? like public void myMethod(String param) and public void myMehthod(List<String> params) ?

[15:59:45] <aesteve> without the typo… obviously :|

[16:09:33] <aesteve> (method overloading)

[16:09:39] <saltuk> hi can i ask a question .. Handler<T> or Handler<AsyncResult<T» which is best for performance (for Example operation that does multiple db read updates ) … is it bad or good doing like this way … sorry if i am taking your time ..

[16:09:43] <saltuk> using much asyncresult is good or bad habit . ?

[16:09:51] <aesteve> AsyncResult provides some information to know if your operation actually succeeded or not

[16:10:16] <saltuk> yeah i like it and using too much ..and start to think if i am doing something bad for perfomance ..

[16:10:31] <saltuk> for example i convertx OrientDb nearly as VertxDb :P with multiple async ops..

[16:10:42] <aesteve> can the db operation fail ? Do you want the user to be able to know why it failed ? In this case I'd go with Handler<AsyncResult<T»

[16:10:45] <aesteve> if you don't want to wrap the exception / or the operation cannot fail, simply go with Handler<T>

[16:10:47] <aesteve> but I could be missing some point here

[16:14:15] <saltuk> i am thinking about the performance…

[16:14:31] <saltuk> aesteve have u look this example ? .. looks how ? .. problematic or not?..

[16:14:57] <saltuk> sorry if disturbing and taking ur time..

[16:15:06] <aesteve> not taking my time at all, don't worry

[16:15:15] <aesteve> but I guess I'm not really qualified to answer a performance question.

[16:15:35] <saltuk> thanx for help aesteve

[16:45:37] <purplefox> temporalfox: I also get an intermittent failure in MetricsTest (been getting this for a long time)

[16:45:38] <purplefox> Failed tests:

[16:45:38] <purplefox> MetricsTest.lambda$null$832:250→AsyncTestBase.assertEquals:231 expected:<1> but was:<0>

[16:48:02] <temporalfox> purplefox ok

[16:48:17] <temporalfox> purplefox never NetTest#testInWorker ?

[16:48:33] <purplefox> not for me

[17:25:51] <minus> quick gradle question: i'm trying to get gradle to download/unpack the dependent vertx modules (e.g. mod-redis) into the build directory, any hints on how to get it right? i have this so far, which won't work because “You can't change a configuration which is not in unresolved state!”. my gradle code is based on this

[17:25:53] <minus> but i obviously need to extract into appropriately named subdirectories

[18:28:25] <minus> damn, this seems impossible. how could i pull the deps beforehand otherwise

[18:30:49] <aesteve> yeah minus I'm sorry I'm no longer familiar with the v2 way of dealing with modules.

[18:31:10] <aesteve> in v3 it's waaaaaaaaaaay easier, modules are simply standard dependencies

[19:30:38] <TheSteve0> purplefox: what ya got for me with vert.x 3 and OpenShift. New cartridge? Docker containers? Gimme gimme