[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 https://github.com/eclipse/vert.x/pull/1040 ?
[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: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 : https://github.com/vert-x3/vertx-redis-client/issues/8
[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… https://github.com/InfoSec812/vertx-ssh-client
[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 http://codepaste.net/rvjcav … 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 http://codepaste.net/rvjcav 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 http://pastebin.com/hdMERuvL 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> https://discuss.gradle.org/t/right-way-to-copy-contents-from-dependency-archives/7449/11 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