Differences

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

Link to this comparison view

irc:1462658400 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[00:28:26] *** ChanServ sets mode: +o temporal_
 +
 +[10:39:02] <​aesteve>​ hi temporal_ , cescoffier . Are you planning a conf / workshop for Paris Web ?
 +
 +[10:39:16] <​temporal_>​ no I don't
 +
 +[10:39:20] <​cescoffier>​ aesteve : Hi, no. Nothing planned.
 +
 +[10:41:55] <​cescoffier>​ Paris Web is very web no ?
 +
 +[10:42:24] <​aesteve>​ I had never heard about it before this morning actually, that's why I was wondering
 +
 +[10:44:12] <​aesteve>​ I'm currently looking at previous years' confs
 +
 +[10:45:55] <​aesteve>​ yes it looks very front-end oriented
 +
 +[10:46:05] <​cescoffier>​ I already sent people there a couple of years ago (in a previous life). From what I remember it's about usability, css, frontend technologies...
 +
 +[10:46:50] <​cescoffier>​ maybe with this universal app trend, there will be a bit more backend stuff this year, but even with this, vert.x is not providing anything for universal app (you have to build it yourself)
 +
 +[10:47:58] <​aesteve>​ https://​github.com/​aschrijver/​vertx-react-example
 +
 +[10:48:22] <​aesteve>​ I didn't have the time to give it a look yet, but why not !
 +
 +[10:49:31] <​cescoffier>​ that's more about how to use react with vert.x
 +
 +[10:49:38] <​aesteve>​ that : https://​github.com/​aschrijver/​vertx-react-example/​blob/​master/​src/​main/​java/​org/​example/​MainVerticle.java#​L63 ​ sounds blocking ?
 +
 +[10:50:31] <​temporal_>​ guys any feedback on vertx-unit :-) ?
 +
 +[10:50:41] <​aesteve>​ yes but that's a first step. Once you can render react components within a template handler, you just have to play with html placeholders to re-execute the same code on client-side
 +
 +[10:52:05] <​aesteve>​ the real issue with universal rendering is ajax, some people actually use the exact same code they's use within the client'​s browser to render the pages (meaning XMLHttpRequest to a distant server)
 +
 +[10:52:28] <​aesteve>​ that'​ll never be possible with Nashorn, and that's (imo) a poor design
 +
 +[10:53:36] <​cescoffier>​ temporal_ : didn't have the time yet
 +
 +[10:53:42] <​cescoffier>​ temporal_ probably not next week
 +
 +[10:53:53] <​aesteve>​ temporal_: I haven'​t played with it, I just read the docs yesterday
 +
 +[10:53:59] <​temporal_>​ ok
 +
 +[10:54:17] <​temporal_>​ so the tcnative boringssl uber jar has not yet been released
 +
 +[10:54:24] <​temporal_>​ on wonder why it never worked
 +
 +[10:54:26] <​temporal_>​ no wonder
 +
 +[10:54:45] <​temporal_>​ it seems that the classifier detection with the maven build extension works in Intellij IDE
 +
 +[10:55:20] <​aesteve>​ actually temporal_ is there another way to read the docs than : https://​github.com/​vert-x3/​vertx-unit/​pull/​33/​files
 +
 +[10:55:38] <​temporal_>​ and if you have Asciidoctor.js in Chrome plugin
 +
 +[10:55:43] <​temporal_>​ you can read the file natively
 +
 +[10:57:04] <​temporal_>​ I'm surprised it works in intellij
 +
 +[10:57:21] <​temporal_>​ cescoffier do you think that intellij runs the maven build extension to figure out the classifier value ?
 +
 +[10:57:26] <​aesteve>​ this one ? https://​chrome.google.com/​webstore/​detail/​asciidoctorjs-live-previe
 +
 +[10:57:59] <​temporal_>​ aesteve yes
 +
 +[10:58:10] <​temporal_>​ when I do "show effective pom" in intellij it showws indeed
 +
 +[10:58:10] <​temporal_> ​    <​tcnative.classifier>​osx-x86_64</​tcnative.classifier>​
 +
 +[10:58:13] <​cescoffier>​ temporal_ : probably not, maven support is getting worse... I don't thing they would do that
 +
 +[10:58:14] <​aesteve>​ ok thanks
 +
 +[10:58:22] <​temporal_>​ but it works
 +
 +[10:58:24] <​temporal_>​ so...
 +
 +[10:58:44] <​cescoffier>​ try on eclipse, and see....
 +
 +[10:58:48] <​temporal_>​ yes...
 +
 +[10:58:55] <​temporal_>​ which plugin should I used on eclipse ?
 +
 +[10:58:59] <​cescoffier>​ m2e
 +
 +[10:59:02] <​cescoffier>​ always the same
 +
 +[10:59:04] <​temporal_>​ ok
 +
 +[10:59:17] <​temporal_>​ I will give a try
 +
 +[10:59:31] <​temporal_>​ I hope they will release tcnative boring ssl uber jar soon
 +
 +[11:32:28] <​aesteve>​ temporal_: doc seems pretty clear to understand
 +
 +[11:32:47] <​aesteve>​ I'll try to use it in Nubes this afternoon so that it's a real-life usage
 +
 +[11:33:40] <​aesteve>​ I'm even wondering if :   ​vertx.exceptionHandler(testContext.exceptionHandler());​
 +
 +[11:33:40] <​aesteve> ​ shouldn'​t be set as default
 +
 +[11:43:42] <​temporal_>​ we can't do that as default
 +
 +[11:43:47] <​temporal_>​ as we don't control vertx
 +
 +[11:43:55] <​temporal_>​ and I think it's quite simple to do
 +
 +[11:44:04] <​temporal_>​ and gives control / responsiblity to user
 +
 +[11:44:04] <​temporal_>​ (i.e no magic thing)
 +
 +[11:44:19] <​temporal_>​ you may have a vertx instance that don't need this default in your test
 +
 +[11:46:31] <​aesteve>​ if we can' we can't :( but my point was : this is probably the bahaviour most users will except : "if an exception occurs during my test execution : that's not expected unless I explicitely mentionned it", see what I mean ?
 +
 +[11:49:20] <​AlexLehm>​ temporal_: i have commited the unit test for the proxy code, should I do a new pr for that?
 +
 +[11:49:22] <​AlexLehm>​ https://​github.com/​alexlehm/​vert.x/​tree/​issues/​%231361-add_unit_test
 +
 +[11:49:54] <​temporal_>​ yes please do a pr
 +
 +[11:52:21] <​AlexLehm>​ https://​github.com/​eclipse/​vert.x/​pull/​1413
 +
 +[11:53:35] <​temporal_>​ thanks!
 +
 +[12:07:18] <​AlexLehm>​ what is estimated date for the 3.3.0 milestone? github currently has 1 may 2017
 +
 +[13:07:10] <​aesteve>​ https://​github.com/​vert-x3/​wiki/​wiki/​3.3.0-Breaking-Changes you should add JwtAuthHandler.create no longer works with a simple AuthHandler,​ it's expecting a JWTAuthHandler
 +
 +[13:07:12] <​temporal_>​ AlexLehm we are aiming at 3.3.0 in June - it highly depends on Eclipse CQ and Netty 4.1.0.Final release date
 +
 +[13:07:18] <​aesteve>​ this is a major change for me
 +
 +[13:07:25] <​temporal_>​ aesteve can you make an issue or PR for this ?
 +
 +[13:07:45] <​aesteve>​ I think I can't update the wiki, or I didn't find how to
 +
 +[13:34:26] <​aesteve>​ temporal_: after upgrading to 3.3.0-SNAPSHOT I've a few weird errors happening on my CI server and not locally
 +
 +[13:34:46] <​temporal_>​ aesteve what are thse ?
 +
 +[13:34:54] <​aesteve>​ java.lang.IllegalStateException:​ Uh oh! Event loop context executing with wrong thread! Expected null got Thread[Test worker,​5,​main]
 +
 +[13:34:54] <​aesteve> ​ at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:​343)
 +
 +[13:34:54] <​aesteve> ​ at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:​240)
 +
 +[13:34:54] <​aesteve> ​ at io.vertx.core.http.impl.ConnectionManager$ConnQueue.http1xConnected(ConnectionManager.java:​422)
 +
 +[13:35:43] <​temporal_>​ do you have a reproducer ?
 +
 +[13:36:04] <​aesteve>​ here for instance : https://​github.com/​aesteve/​nubes/​blob/​master/​src/​test/​java/​integration/​params/​QueryParametersTest.java#​L17
 +
 +[13:36:19] <​temporal_>​ do you have full stack trace ?
 +
 +[13:36:26] <​aesteve>​ yeah sure
 +
 +[13:37:16] <​aesteve>​ https://​gist.github.com/​aesteve/​73811921c0f302c53df21ac4720a1d11
 +
 +[13:38:04] <​temporal_>​ looking at it
 +
 +[13:38:13] <​aesteve>​ weird, it doesn'​t happen at all locally
 +
 +[13:39:02] <​aesteve>​ (but actually I think I shouldn'​t create a new httpclient for each test and close the httpclient after each test)
 +
 +[13:39:28] <​aesteve>​ but if my bad practices can help debugging...
 +
 +[13:39:55] <​temporal_>​ so this does not happen locally ?
 +
 +[13:39:57] <​temporal_>​ or does it ?
 +
 +[13:40:48] <​aesteve>​ it doesnt, at all
 +
 +[13:41:02] <​aesteve>​ same stuff, "​./​gradlew test"
 +
 +[13:41:20] <​aesteve>​ the difference is here : mybook air, CI : AWS t2.micro
 +
 +[13:41:49] <​aesteve>​ (neither "​gradlew test" nor in IntelliJ on my machine)
 +
 +[13:42:12] <​temporal_>​ the problem seems to be related to Async dns resolution
 +
 +[13:42:37] <​temporal_>​ I can push something in a branch
 +
 +[13:42:41] <​temporal_>​ and you can test it from that server ?
 +
 +[13:43:45] <​temporal_>​ I understand why it happens
 +
 +[13:43:48] <​temporal_>​ now
 +
 +[13:44:25] <​temporal_>​ and effectively CI is slower
 +
 +[13:44:40] <​temporal_>​ and it's not suprising that this happens
 +
 +[13:45:46] <​aesteve>​ cool
 +
 +[13:46:05] <​aesteve>​ let me know what I can do to help
 +
 +[13:46:13] <​temporal_>​ you can test something when I have a fix
 +
 +[13:46:15] <​temporal_>​ hopefully soon
 +
 +[13:46:24] <​aesteve>​ no problem, ​ just tell me
 +
 +[13:46:57] <​aesteve>​ I'll install maven + checkout your branch locally on CI server & install it
 +
 +[13:49:22] <​temporal_>​ thanks
 +
 +[13:49:27] <​temporal_>​ what is your CI ?
 +
 +[13:49:29] <​temporal_>​ jenkns ?
 +
 +[13:49:31] <​aesteve>​ yep
 +
 +[13:49:40] <​temporal_>​ you run it yhourself ?
 +
 +[13:50:14] <​aesteve>​ yes
 +
 +[13:50:30] <​aesteve>​ I wanted to give "​raw"​ AWS a try
 +
 +[13:51:29] <​temporal_>​ ok
 +
 +[14:17:51] <​temporal_>​ almost got something
 +
 +[14:19:53] <​temporal_>​ I will push a change in a branch
 +
 +[14:19:57] <​temporal_>​ so you can try
 +
 +[14:20:05] <​temporal_>​ and after I'll try to make a reproducer case
 +
 +[14:20:13] <​temporal_>​ so it can be tested
 +
 +[14:26:09] <​temporal_>​ aesteve can you try this ? https://​github.com/​eclipse/​vert.x/​tree/​bind-connect-helper-listener-fix
 +
 +[14:27:20] <​temporal_>​ I need to go out for a little while, let me know how it goes, I think it should solve it
 +
 +[14:29:24] <​aesteve>​ ok I'll give it a try :)
 +
 +[16:00:32] <​temporal_>​ aesteve is there an improvement ?
 +
 +[16:01:01] <​aesteve>​ no I'm struggling because the user jenkins has no access to the maven repo (I guess)
 +
 +[16:06:11] <​aesteve>​ ok now it finds vert.x-core in mavenLocal()
 +
 +[16:06:30] <​aesteve>​ I think I can add back SNAPSHOTS for other artifacts resolution
 +
 +[16:07:08] <​aesteve>​ sorry I'm playing with Elm in the meantime :P
 +
 +[16:12:59] <​aesteve>​ it's working temporal_ yeah !
 +
 +[16:13:08] <​temporal_>​ cool
 +
 +[16:13:15] <​temporal_>​ I'm going to add some test and merge this in master
 +
 +[16:13:37] <​aesteve>​ but I still think I should refactor to use a single httpClient forEach test, it's a poor design I'm using
 +
 +[16:15:49] <​temporal_>​ the main problem I think is rather that the client could reuse a stale connection between tests
 +
 +[16:15:54] <​temporal_>​ stale pooled
 +
 +[16:17:25] <​aesteve>​ I'll let things as is, time for you to create the test, merge the branch and push it as a snapshot
 +
 +[16:17:42] <​aesteve>​ then I'll retry without mavenLocal() so you can be sure everything'​s working fine
 +
 +[16:17:49] <​aesteve>​ then I'll change my implementation :)
 +
 +[16:23:13] <​temporal_>​ ok
 +
 +[16:23:16] <​temporal_>​ should not be long
 +
 +[16:25:05] <​temporal_>​ I merged the change with the test
 +
 +[16:26:14] <​aesteve>​ ok I'll remove m2 repo
 +
 +[16:30:28] <​temporal_>​ thanks for the feedback
 +
 +[16:30:58] <​temporal_>​ that's cool you can find such issues and we fix them before 3.3
 +
 +[16:31:26] <​aesteve>​ say thanks to Amazon !
 +
 +[16:32:17] <​aesteve>​ Actually I'm planning Nubes 2.0 release to match Vert.x 3.3.0 so I have to prepare the field
 +
 +[16:33:15] <​aesteve>​ I've so many things to do, I'd like to re-work authentication completely, maybe include the "​typesafe"​ config stuff I did last week too
 +
 +[16:33:53] <​aesteve>​ and the Spring Boot conf inspired me alot, too. There'​s a lot of opinionated stuff that helps alot