Differences

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

Link to this comparison view

irc:1431986400 [2017/05/27 13:44] (current)
Line 1: Line 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 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:17:48] <​temporalfox>​ https://​github.com/​eclipse/​vert.x/​blob/​master/​src/​main/​java/​io/​vertx/​core/​http/​impl/​HttpServerImpl.java#​L587
 +
 +[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