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

[00:52:21] <AlexLehm> actually when I run my tests on the jenkins, it says The Async complete method cannot be called more than one time, so there seems to be a check already

[00:52:28] <AlexLehm> not sure why I didn't get that

[13:20:36] <AlexLehm> purplefox: who can i ask about pr for the eclipse repo ? julian and you?

[13:22:02] <AlexLehm> I have two prs for the core project open, one is a very minor thing I had in an unit test and the other is something completely unrelated to my project (relating to blocked loop logging)

[14:03:20] <D-Spair> Does anyone know if there is a BOM for Vert.x 3.0.0 yet?

[14:04:34] <D-Spair> Hmmm . . . Looks like there was for dev_preview1, but no updates since? http://search.maven.org/#search|ga|1|a%3A%22vertx-stack-bom%22

[15:10:54] <diega> m

[15:16:58] <temporalfox> D-Spair closest thing today is https://github.com/vert-x3/vertx-dependencies/

[15:20:08] <rajith> purplefox: hey Tim, have you had a chance to look at the work on initial-branch yet? I have prepared a tutorial which I will add shortly. Other than that and some doc changes I think it should be in a position to be moved to master. From then onwards I can do any minor bug fixes on the master it self.

[15:20:17] <D-Spair> temporalfox: Thanks, that's perfect!

[15:20:35] <D-Spair> temporalfox: Gonna update my Vert.x archetypes for that now.

[15:21:09] <temporalfox> D-Spair we also have a depchain in vertx-stack

[15:21:20] <temporalfox> https://github.com/vert-x3/vertx-stack/tree/master/stack-depchain

[15:21:47] <D-Spair> temporalfox: That doesn't seem to have the right structure to be used as a BOM in something like an Archetype..

[15:22:30] <temporalfox> D-Spair no it's a “depchain” which is what someone uses when he wants to import dependencies

[15:22:43] <temporalfox> D-Spair it's used a dependency not as dependencyManagement

[15:22:54] <D-Spair> temporalfox: Does it import ALL of the deps or just the ones declared in the user's POM?

[15:23:17] <temporalfox> it imports everything, probably too much when you make a project, but definitely a good way to start

[15:23:28] <temporalfox> then one can consider using selected dependencies from this depchain

[15:23:33] <temporalfox> and instead use bom

[15:25:14] <D-Spair> temporalfox: For my archetypes, I think it makes more sense to use the BOM…

[15:25:34] <temporalfox> D-Spair sure

[15:25:38] <temporalfox> use whateer you need

[15:37:49] <D-Spair> OK, new archetypes are deployed to Central… Should be available later today… GAV = com.zanclus.codepalousa:vertx-js-archetype:3.0.0.8 and com.zanclus.codepalousa:vertx-java-archetype:3.0.0-milestone5

[16:01:09] <purplefox> temporalfox: hi julien, you may have noticed - i dropped a new PR for you to review on apex :)

[16:01:19] <temporalfox> yes I've seen that

[16:01:30] <temporalfox> I did one (very small) for you as well

[16:02:25] <purplefox> in apex?

[16:02:33] <temporalfox> no, in reactive-streams

[16:03:23] <temporalfox> https://github.com/vert-x3/vertx-reactive-streams/pull/5

[16:04:05] <purplefox> ok i'm not sure i understand why that PR is necessary, could you elaborate a bit on it?

[16:04:56] <temporalfox> when we use observable with HttpServer as an Observable<HttpServerRequest>

[16:05:19] <temporalfox> the event with HttpServerRequest is executed in a run on context

[16:05:25] <temporalfox> and if the request receives Buffer

[16:05:39] <temporalfox> the actual event callback is done after receiving buffers

[16:06:09] <D-Spair> Huh! Found a bug in NetBeans and how it handles Maven POM files with BOM…

[16:06:30] <D-Spair> https://netbeans.org/bugzilla/show_bug.cgi?id=252361

[16:06:50] <temporalfox> 1/ reactive-streams handler gets an HttpServerRequest callback and schedule a runOnContext for onNext

[16:06:50] <purplefox> httpserver uses reactive-streams ??

[16:06:54] <temporalfox> no

[16:07:00] * purplefox confused

[16:07:02] <temporalfox> ok

[16:07:17] <temporalfox> HttpServer provides an HttpServerRequestStream

[16:07:24] <D-Spair> Did services get dropped from the scope of the 3.0.0 release?

[16:07:25] <temporalfox> when used with Observable

[16:08:01] <temporalfox> since we are trying to use reactive streams for bridging RxJava and io.vertx.core.streams

[16:08:10] <temporalfox> it uses by an reactive-streams implementation

[16:08:13] <D-Spair> Looks like the PostgreSQL/MySQL service is no longer a thing?

[16:08:37] <purplefox> temporalfox: hmm, i thought you were only using this for backpressure

[16:08:38] <temporalfox> because from the perspective of this code there is no way to make the diff betweean something that supports flow control or not

[16:10:26] <purplefox> ok… my opinion on all this stuff. I'm pretty confused by it, so can we just deal with it after 3.0? I.e. remove reactive-streams from our RX stuff

[16:10:36] <temporalfox> purplefox sure we can

[16:10:44] <temporalfox> actually I have an idea to make this simpler

[16:10:49] <temporalfox> and solve several problems

[16:11:09] <temporalfox> we should have a Read/Write stream that don't support flow control

[16:11:18] <temporalfox> and have ReadStream/WriteStream extend them

[16:11:31] <temporalfox> to add the flow control methods

[16:11:46] <temporalfox> and the thing like HttpServerRequestStream would be non flow control streams

[16:12:05] <temporalfox> and the RxJava version would use the right impl for the right kind of streams

[16:12:43] <purplefox> maybe, but i don't really care until 3.1 ;)

[16:12:55] <purplefox> we have other stuff to worry about ;)

[16:13:03] <temporalfox> purplefox yes that's obviously just a thought, I won't refactor things today

[16:13:38] <temporalfox> I will focus on other tasks

[16:13:54] <temporalfox> wrap up the actual things : metrics and ruby codetranslation

[16:14:10] <temporalfox> and http-service-factory

[16:14:24] <temporalfox> after that I'll ask you for assignment

[16:14:35] <purplefox> ok cool. thanks julien

[16:14:42] <purplefox> I have put the tasks up here:

[16:14:48] <purplefox> https://github.com/vert-x3/wiki/wiki/Vert.x-3-final-stretch

[16:15:19] <temporalfox> http-service=factory you said all good :-)

[16:15:48] <purplefox> what's todo in http-service-factory?

[16:16:00] <temporalfox> port stuff from Vert.x 2

[16:16:05] <temporalfox> like http redirection handling

[16:16:14] <temporalfox> and a tutorial for bintray

[16:16:18] <purplefox> and proxies?

[16:16:21] <temporalfox> yes

[16:16:23] <temporalfox> exactly

[16:16:26] <purplefox> ok

[16:16:33] <temporalfox> and proxy-auth I guess

[16:16:36] <purplefox> how much work do you think that is?

[16:17:00] <temporalfox> I think one good day for http-service-factory with proper testing

[16:17:17] <temporalfox> for ruby I don't know exactly, a couple of days

[16:17:21] <temporalfox> max

[16:17:34] <purplefox> ok, seems reasonable

[16:17:40] <purplefox> let me put some names by the tasks

[16:17:40] <temporalfox> metrics one day max

[16:17:57] <temporalfox> ok

[16:18:02] <purplefox> are you ok with doing the distro task - i think that is your area?

[16:18:12] <purplefox> i.e. maven shit ;)

[16:18:38] <purplefox> what's remaining on metrics?

[16:18:39] <temporalfox> assignme to distro

[16:18:58] <temporalfox> metrics : write tests that just check threads/contexts correctness

[16:19:02] <temporalfox> then report this in the SPI javadoc

[16:19:09] <temporalfox> for instance

[16:19:41] <temporalfox> VertxMetrics.createMetrics(HttpServer server, SocketAddress localAddress, HttpServerOptions options);

[16:19:56] <temporalfox> in the callback I check thread/context

[16:20:00] <temporalfox> then in the doc of this I say that

[16:20:12] <temporalfox> the thread of the callback is the contxt thread of the server

[16:20:33] <temporalfox> so if the implemntor maintains a map of HttpServer → metrics

[16:20:40] <temporalfox> he needs to care about this

[16:20:46] <purplefox> when you say “callback” which method are you referring to?

[16:20:56] <temporalfox> the metrics SPI callbacks

[16:21:17] <temporalfox> what one implements when he writes an implementation of the vertx-core SPI metrics interfaces

[16:21:35] <temporalfox> then HttpServerMetrics gets other callbacks

[16:21:42] <temporalfox> like requestBegin / responseEnd

[16:22:02] <temporalfox> and so we say that there it is the same thread that was used when the HttpServerMetrics was created

[16:22:03] <temporalfox> etc…

[16:22:07] <temporalfox> not really hard

[16:22:34] <purplefox> sorry, i don't follow

[16:22:44] <purplefox> can you give a concrete example?

[16:23:53] <purplefox> i can't see any callbacks in the metrics spi…

[16:26:12] <temporalfox> ah

[16:26:14] <temporalfox> I mean methods

[16:26:23] <temporalfox> which are callbacks done from vertx-core

[16:26:40] <purplefox> vertx-core calls the methods in the SPI

[16:27:02] <temporalfox> yes

[16:27:03] <purplefox> i wouldn't call them callbacks. to me a callback is when you regsiter a handler and sometime later it gets called

[16:27:12] <temporalfox> ok yes I agree with you

[16:27:19] <purplefox> ok, so what's the issue with calling those methods?

[16:27:39] <temporalfox> we need to document the thread for the implementor

[16:28:01] <temporalfox> Thomas that is doing the implementation for Hawkular told me that this is not obvious

[16:28:05] <purplefox> ok, i assume it will be called on the context of whatever object it is relevant to…

[16:28:07] <temporalfox> when you implement it

[16:28:15] <temporalfox> for you it is obvious :-)

[16:28:27] <purplefox> i don't follow.. the implementor does not have to do anything, Vert.x core calls the method

[16:28:37] <purplefox> so vertx-core determines the thread

[16:28:40] <temporalfox> yes but implementor can maintain a data structure

[16:28:48] <temporalfox> for the metrics

[16:29:06] <temporalfox> and they care to know when to apply synchronization or not

[16:29:09] <temporalfox> and how to do it

[16:29:29] <purplefox> synchronization is probably a very bad idea

[16:29:42] <temporalfox> yes it is

[16:29:52] <temporalfox> that's why they need to know about this

[16:30:01] <temporalfox> and we need to document it

[16:30:10] <purplefox> ok but this is just the same rule about blocking an event loop which we have already documented :)

[16:30:39] <temporalfox> I don't think so

[16:30:57] <temporalfox> because I talked to Thomas that implements it

[16:31:03] <purplefox> i guess we should say, the spi will be called on an event loop for a standard verticle, so the normal rules about blocking the event loop apply

[16:31:29] <temporalfox> it's not about blocking

[16:31:33] <temporalfox> he knows that :-)

[16:31:44] <temporalfox> in VertxMetrics

[16:31:48] <purplefox> ok, i don't understand what it is about then ;)

[16:31:53] <temporalfox> you have methods to create metrics object

[16:32:07] <temporalfox> for instance

[16:32:09] <temporalfox> HttpServerMetrics<?, ?, ?> createMetrics(HttpServer server, …)

[16:32:25] <temporalfox> this metric will be called with a different thread, probably the context thread of the http server

[16:32:32] <temporalfox> “called by”

[16:32:39] <temporalfox> then in this particular HttpServerMetrics

[16:32:47] <temporalfox> the methods are called for this server only

[16:32:58] <temporalfox> so the thread should be always the same

[16:32:59] <temporalfox> etc..

[16:33:03] <temporalfox> that's what I want to document

[16:33:07] <temporalfox> not more than that

[16:33:17] <purplefox> that seems to me just the normal semantics for contexts

[16:33:24] <temporalfox> to you yes

[16:33:31] <temporalfox> :-)

[16:33:36] <purplefox> ok ;)

[16:33:48] <purplefox> you document what you want, i don't really get the issue

[16:33:48] <temporalfox> anyway if you find this odd, I can go on :-)

[16:34:25] <temporalfox> ok good

[16:35:36] <purplefox> :D ;)

[16:38:05] <purplefox> temporalfox: it looks like the hazelcast team may have fixed the clustering issue :) which is good because that means I don't have to rewrite the clustering layer two weeks before the 3.0 code freeze ;)

[16:39:03] <temporalfox> that's very cool

[16:39:19] <temporalfox> I prefer you refactor other part of vertx :-)

[16:39:37] <purplefox> D-Spair: services are still there. but we're not using them really for clients any more. there was discussion about this on the google group before it was implemented

[16:39:47] <purplefox> temporalfox: lol

[16:40:07] <purplefox> temporalfox: the only significant refactoring to do hopefully is the apex session/auth stuff

[16:40:24] <temporalfox> never say never :-)

[16:40:25] <D-Spair> purplefox: OK… I just wanted to make sure that if I update my code for this project I am working on that it will not have to be significantly changed in the future to make use of services again…

[16:44:11] <purplefox> D-Spair: no such guarantees I'm afraid - this is a development branch and we are in the midst of heavy development right now :)

[16:46:07] <D-Spair> purplefox: True… I will roll with the punches and I can always dig the previous code out of GIT if needs be…

[16:47:06] <D-Spair> Here's another question… If we are using Java 8, it includes a significantly improved Date/Time API which is comparable to JodaTime; then why are we using JodaTime? Is there something that JodaTime gives that Java 8's Time/Data API lacks?

[16:52:43] <purplefox> where are we using JodaTime?

[17:00:46] <jtruelove> purplefox: for vertx3 and creating fatjars is there a general pattern with gradle?

[17:01:17] <purplefox> jtruelove: there is an example in the examples repo :)

[17:01:44] <purplefox> gradle-simplest and gradle-verticle

[17:01:59] <purplefox> if you take a look at the main readme it should guide you through

[17:02:57] <jtruelove> great thanks, i didn't see it in the docs i should have checked the samples

[17:10:23] <purplefox> np!

[17:27:50] <jtruelove> ah right it's the shadow jar stuff, i thought i recalled something about shadow jars

[18:48:22] <AlexLehm> purplefox, can I use something like Mockito for the unit tests?

[18:48:30] <AlexLehm> or can we I should say

[18:54:03] <D-Spair> purplefox: Sorry, I was AFK for a while. When I include the sql-common artifact it pulls in JodaTime…

[18:54:52] <D-Spair> purplefox: Perhaps it's pulled in from one of the other deps… Mysql-Async perhaps… Let me check the dependency tree.

[18:55:57] <D-Spair> purplefox: It's pulled in because of com.github.mauricio:db-async-common_2.11:jar:0.2.15:compile

[18:56:32] <D-Spair> purplefox: So, not included by Vert.x then… I spoke too soon..

[19:52:55] -tepper.freenode.net- [freenode-info] help freenode weed out clonebots – please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup

[19:53:04] <mark_> purplefox: You There? We are now live on Facebook! [19:54:23] <mark_> https://apps.facebook.com/hdpokerplay/

[19:54:59] <mark_> That is the link to our Vert.x driven poker app. All Vert.x on the server side. Flash client connecting to Vert.x game-server via sockets. [19:57:18] <AlexLehm> is the expectation of snapshot versions on sonatype to use the wip versions or the master versions? [20:09:20] <mark_> Also note that this is out “beta” so there are still some bugs, but overall it is really nice.

[20:15:53] <purplefox> mark_: looks good :) [20:16:15] <mark_> Just costs 5 Million dollars to create. ;)

[20:16:30] <purplefox> mark_: I'm glad things got sorted in the end [20:16:41] <purplefox> mark_: is this your own company?

[20:16:52] <mark_> Thanks. You definitely helped with that test. [20:17:15] <purplefox> no problem [20:17:16] <mark_> Well, I am going to get 1.2% in options. But not my company directly.

[20:17:54] <purplefox> mark_: do you want to put the company logo on the new website in the “who's using vert.x” section? [20:18:05] <mark_> This company is owned by a Father/Son company that made millions off of suing Microsoft. They also now own a casino in Reno NV.

[20:18:39] <mark_> Definitely would like to do that. Just have to first ask permission. We aren't quite yet advertising the app. We hit the button less than an hour ago, and we have some kinks to fix. ;) [20:18:57] <purplefox> AlexLehm: all snapshots should be from master [20:19:18] <purplefox> mark_: sounds good

[20:19:34] <mark_> Cool. We are excited. It only took us 3 years to write it all. ;) [20:19:36] <purplefox> mark_: i've been chasing hazelcast bugs all day :(

[20:20:00] <mark_> Yeah, sorry about that. Hazelcast or we now call it Hazelnutz! [20:20:07] <purplefox> mark_: well congratulations. i think you can breathe a deep sigh of relief :)

[20:20:16] <purplefox> lol

[20:20:21] <purplefox> yeah i know what you mean

[20:20:42] <mark_> Yeah. But you know even after release, the month after that first release is still a lot of work to find those bugs that users find, that you never thought about. [20:21:01] <purplefox> true [20:22:35] <mark_> Hazelcast is a love/hate thing. It is amazing what it does and can do and potential. But then there are things that you have to do that if it was a db or something else, that it would handle that for you. Like optimistic/pessimistic locking. And having to remember that if you take something out of a Map and change it, you still have to put it back to save it, and be careful that you don't overwrite some other code tha

[20:22:36] <mark_> t might change that entry at the same time, and you lose data. [20:23:31] <purplefox> I agree. I think I usually prefer a more actor style model with no shared state [20:23:47] <purplefox> but ymmv [20:25:26] <mark_> I think Hazelcast just needs to add an api that when you call get() it locks that entry until it is updated, or something. So that we don't have to code that ourselves.

[20:25:51] <mark___> Act more like a database with transactions would. Or be able to work within a transaction.

[20:51:53] <AlexLehm> ok then I think I set the jenkins project up wrong

[20:53:08] <AlexLehm> do you have a naming convention for branches?

[20:53:18] <AlexLehm> somelike vertx3-something-wip?

[21:05:18] <purplefox> AlexLehm: the only convention we have is for initial work, which is usually done on a branch called initial-work but for other work just call it whatever you like :)

[21:09:23] <AlexLehm> no, i mean what should i call the jenkins project that builds a specific branch?

[21:21:36] <purplefox> AlexLehm: we don't have a convention for that either. but perhaps vertx3-projectname-branchname is a good scheme

[21:24:09] <AlexLehm> ok, i have created a new project vert.x3-mail-client-wip that doesn't do mvn deploy, the master project is called vert.x3-mail-client now

[21:25:57] <purplefox> AlexLehm: thanks alex, will take a look soon. sorry, just been so busy on other stuff today (mainly chasing HZ bugs)

[23:49:24] <AlexLehm> i have pushed a new wip version of pool tests, not quite complete but much better than before