Differences

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

Link to this comparison view

irc:1444773600 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[01:49:35] *** ChanServ sets mode: +o purplefox
 +
 +[02:50:07] *** ChanServ sets mode: +o purplefox
 +
 +[09:28:20] *** ChanServ sets mode: +o purplefox
 +
 +[09:40:57] <​temporalfox>​ jtruelove hi
 +
 +[09:41:17] <​temporalfox>​ pmlopes hi I have a couple of questions for you
 +
 +[09:41:34] <​pmlopes>​ hi
 +
 +[09:42:45] <​temporalfox>​ in vertx.x web or redis/jdbc do we have use case with List/Set containing null ?
 +
 +[09:43:40] <​pmlopes>​ as argument or as reply?
 +
 +[09:43:54] <​temporalfox>​ both :-)
 +
 +[09:43:54] <​pmlopes>​ or it doesn'​t matter?
 +
 +[09:44:08] <​temporalfox>​ I'm figuring out the current javascript support for nullable
 +
 +[09:44:38] <​temporalfox>​ and the reality of the current apis
 +
 +[09:44:44] <​temporalfox>​ if we really need/use this feature
 +
 +[09:45:00] <​temporalfox>​ I believe it makes sense for data stuff that can have null return or null insert
 +
 +[09:45:37] <​temporalfox>​ as you worked a bit on database stuff (redis / jdbc) I wnated to check with your the use cases
 +
 +[09:45:40] <​pmlopes>​ i am looking at redis code and a list might contain null values since it is a perfect valid for redis
 +
 +[09:45:53] <​temporalfox>​ if we need it and then we need to properly support it in the codegen TCK
 +
 +[09:45:54] <​pmlopes>​ i even need to encode them in a special way
 +
 +[09:46:13] <​temporalfox>​ ok
 +
 +[09:46:21] <​temporalfox>​ so that would be an argument
 +
 +[09:46:33] <​pmlopes>​ oh and i know that we also need it for the jdbc client
 +
 +[09:46:46] <​temporalfox>​ what type is it ?
 +
 +[09:46:55] <​temporalfox>​ List<​String>​ ?
 +
 +[09:47:21] <​pmlopes>​ oh no, for jdbc it is a json array
 +
 +[09:47:34] <​temporalfox>​ json is different
 +
 +[09:47:43] <​pmlopes>​ when you have query placeholders ? they can be null
 +
 +[09:47:57] <​temporalfox>​ so what do we have for List/​Set/​Map ?
 +
 +[09:48:43] <​pmlopes>​ humm in that case we could deprecate the redis API and propose a new one using JsonArray
 +
 +[09:49:17] <​temporalfox>​ jdbc seems to use JsonArray
 +
 +[09:49:20] <​pmlopes>​ for a quick find and count it seems that we would need to deprecate 34 method :|
 +
 +[09:49:20] <​temporalfox>​ in SQLConnection
 +
 +[09:49:40] <​temporalfox>​ pmlopes what do you mean ?
 +
 +[09:49:56] <​pmlopes>​ no, sorry in redis, in redis
 +
 +[09:50:40] <​pmlopes>​ in redis there are 34 methods that take List<​String>​ and they can have both null or not null values, however i think we could propose a API update to replace that with JsonArray
 +
 +[09:51:02] <​temporalfox>​ like
 +
 +[09:51:03] <​temporalfox>​ RedisClient evalsha(String sha1, List<​String>​ keys, List<​String>​ values, Handler<​AsyncResult<​JsonArray>>​ handler);
 +
 +[09:51:10] <​pmlopes>​ yes
 +
 +[09:51:12] <​temporalfox>​ I think it's fine to have nullable
 +
 +[09:51:28] <​temporalfox>​ if it's string I think List<​String>​ is better
 +
 +[09:51:32] <​temporalfox>​ and we should keep it
 +
 +[09:51:44] <​temporalfox>​ my point isthat I'm not sure JavaScripr properly supports null in lists
 +
 +[09:52:01] <​pmlopes>​ ['​a',​ null] is perfectly valid
 +
 +[09:52:27] <​temporalfox>​ ok
 +
 +[09:52:41] <​temporalfox>​ I think we miss at least TCK use cases
 +
 +[09:52:50] <​temporalfox>​ for testing such behavior cross languages
 +
 +[09:53:06] <​pmlopes>​ even more weird stuff like ['​a',​ null, undefined] is allowed ;) don't you love it now :)
 +
 +[09:53:27] <​temporalfox>​ but that would not make sense for vertx
 +
 +[09:53:40] <​temporalfox>​ and that would result in some kind of errors thrown by vertx-lang-js
 +
 +[09:53:45] <​temporalfox>​ wouldn'​t it ,
 +
 +[09:54:40] <​pmlopes>​ it depends if someone is checking for nulls with == then null or undefined are considered null, however if one checks with === then only null is null
 +
 +[09:55:07] <​temporalfox>​ that's why we need a TCK :-)
 +
 +[09:55:08] <​pmlopes>​ the bad side is that if one uses == then 0, '',​ false are also null :)
 +
 +[09:55:17] <​temporalfox>​ at the moemnt we use typeof on arguments
 +
 +[09:55:29] <​temporalfox>​ and I know that type null is "​object"​
 +
 +[09:55:32] <​temporalfox>​ in JS
 +
 +[09:55:39] <​temporalfox>​ and the shim is ok with that
 +
 +[09:55:45] <​temporalfox>​ then there is a null check in the conversion
 +
 +[09:55:55] <​temporalfox>​ that means today we don't accept null functions
 +
 +[09:56:10] <​temporalfox>​ for instance vertx.close(null) is acceptable by Vert.x core
 +
 +[09:56:20] <​temporalfox>​ in JS vertx.close(null) throws a TypeError
 +
 +[09:56:21] <​pmlopes>​ where can i add javascript TCK tests?
 +
 +[09:56:33] <​temporalfox>​ that would rather be custom JS cases I think
 +
 +[09:56:36] <​temporalfox>​ as they would contain null
 +
 +[09:56:45] <​temporalfox>​ like you do a Vert.x API in JS
 +
 +[09:56:49] <​temporalfox>​ codegen
 +
 +[09:56:55] <​temporalfox>​ like
 +
 +[09:57:02] <​temporalfox>​ checkList(List<​String>​)
 +
 +[09:57:06] <​temporalfox>​ and you call it with undfined
 +
 +[09:57:10] <​temporalfox>​ and see what happens :-)
 +
 +[09:57:15] <​temporalfox>​ (tdd style)
 +
 +[09:57:29] <​temporalfox>​ TCK would be more for Nullable collections
 +
 +[09:58:21] <​pmlopes>​ the best way to test for null in js would be (if value === null || value === undefined)
 +
 +[09:58:46] <​pmlopes>​ then we have a behavior like java for instance
 +
 +[10:00:49] <​temporalfox>​ ah you mean that undefined would be considered as null ?
 +
 +[10:01:20] <​pmlopes>​ yes
 +
 +[10:02:03] <​pmlopes>​ and i think that for most use cases in js that is fine specially it what matters to call vert.x code
 +
 +[10:04:49] <​temporalfox>​ yes we should rather be permissive if we pass undefined explictely
 +
 +[10:05:01] <​temporalfox>​ as long as it does not have impacts on overloading :-)
 +
 +[10:07:01] <​pmlopes>​ how do you run the TCK?
 +
 +[10:08:51] *** ChanServ sets mode: +o purplefox
 +
 +[10:09:37] <​temporalfox>​ mvn clean test
 +
 +[10:09:42] <​temporalfox>​ TCK is ApiTest
 +
 +[10:09:49] <​temporalfox>​ then you have extra tests around
 +
 +[10:09:53] <​temporalfox>​ to test special cases in JS
 +
 +[10:09:58] <​temporalfox>​ and that what you would do
 +
 +[10:10:13] <​temporalfox>​ but before working on that we should first agree on the global nullable behavior :-)
 +
 +[10:10:24] <​temporalfox>​ cf my point about nullable function/​handler
 +
 +[10:12:58] <​pmlopes>​ currently in core handlers are not optional, they do not take nulls so we can do the same for JS if handler === null or handler ===undefied then it is a type error i think
 +
 +[10:14:08] <​pmlopes>​ the undefined is important for cases like: redis.get('​key'​) since i did not pass a second arg js will interpret the second arg as undefined
 +
 +[10:22:33] <​purplefox>​ pmlopes: temporalfox cescoffier: morning guys
 +
 +[10:22:42] <​temporalfox>​ hi
 +
 +[10:22:43] <​pmlopes>​ good morning
 +
 +[10:22:43] <​cescoffier>​ morning
 +
 +[10:23:00] <​temporalfox>​ pmlopes null handler has impact on overloading check
 +
 +[10:23:22] <​temporalfox>​ pmlopes and yes some handlers are optional
 +
 +[10:23:28] <​temporalfox>​ for instance : vertx.close(null) is valid
 +
 +[10:23:42] <​temporalfox>​ if you look at Pump implemnetation
 +
 +[10:23:48] <​temporalfox>​ it calles an handler with null value
 +
 +[10:27:01] <​pmlopes>​ can you share an example where you're having trouble with js maybe it would be easier for me to fully understand the problem
 +
 +[10:27:02] <​cescoffier>​ purplefox, pmlopes, temporalfox : if you all agree with the tags proposal, I will update the wiki
 +
 +[10:27:18] <​pmlopes>​ @cescoffier +1 for the tags
 +
 +[10:27:26] <​temporalfox>​ pmlopes I sent an example on vertx-dev in reply to myself :-)
 +
 +[10:27:37] <​pmlopes>​ ok
 +
 +[11:44:31] <​purplefox>​ temporalfox:​ hi julien
 +
 +[11:44:41] <​purplefox>​ temporalfox:​ quick question on EventBusMetrics:​
 +
 +[11:44:45] <​purplefox>​ void messageSent(String address, boolean publish, boolean local, boolean remote);
 +
 +[11:45:05] <​purplefox>​ can "​local"​ and "​remote"​ ever be the same?
 +
 +[11:45:15] <​purplefox>​ if so, why are there two params?
 +
 +[11:55:07] <​temporalfox>​ purplefox it can be true/true in case of publish that publish both locally and remote on cluster
 +
 +[11:56:05] <​temporalfox>​ we should update javadoc to be more precise for implementors
 +
 +[12:01:29] <​purplefox>​ ok, i see thanks
 +
 +[12:01:57] <​cescoffier>​ pmlopes: did you change the configuration of the vertx-examples build ?
 +
 +[12:02:24] <​pmlopes>​ i don't think so, why?
 +
 +[12:02:34] <​cescoffier>​ the build became parameterized
 +
 +[12:02:40] <​cescoffier>​ by the branch to build
 +
 +[12:03:12] <​cescoffier>​ well... removing it :-)
 +
 +[12:03:24] <​pmlopes>​ no i did not do anything on jenkins lately specially about parameterized builds
 +
 +[12:03:27] <​pmlopes>​ ok
 +
 +[12:04:26] <​cescoffier>​ the build is failing with "no workspace for vert.x3-examples #640"
 +
 +[12:10:15] <​pmlopes>​ we also get timeout building web on jenkins it takes more than 30 minutes...
 +
 +[12:10:18] <​cescoffier>​ ok found the culprit ... the github pull request plugin failed
 +
 +[12:10:27] <​cescoffier>​ 30 minutes !
 +
 +[12:10:34] <​cescoffier>​ wow, I already increase the timeout
 +
 +[12:10:40] <​cescoffier>​ 30 min is regally huge
 +
 +[12:10:47] <​pmlopes>​ yes that is quite stange since it builds in less than 5 on my local machine
 +
 +[12:10:55] <​pmlopes>​ doing everything including docs
 +
 +[12:13:13] <​pmlopes>​ there was something wrong with sockjs tests and they blocked for 30 minutes
 +
 +[12:13:31] <​pmlopes>​ Starting test: SockJSHandlerTest#​testNotFound
 +
 +[12:13:33] <​pmlopes>​ io.vertx.core.VertxException:​ Connection was closed
 +
 +[12:13:36] <​pmlopes>​ Thread Thread[vert.x-eventloop-thread-8,​5,​main] has been blocked for 2990 ms, time limit is 2000
 +
 +[12:13:38] <​pmlopes>​ Thread Thread[vert.x-eventloop-thread-6,​5,​main] has been blocked for 2989 ms, time limit is 2000
 +
 +[12:13:40] <​pmlopes>​ Thread Thread[vert.x-eventloop-thread-8,​5,​main] has been blocked for 3990 ms, time limit is 2000
 +
 +[12:13:42] <​pmlopes>​ Thread Thread[vert.x-eventloop-thread-6,​5,​main] has been blocked for 3990 ms, time limit is 2000
 +
 +[12:13:44] <​pmlopes>​ Thread Thread[vert.x-eventloop-thread-8,​5,​main] has been blocked for 4991 ms, time limit is 2000
 +
 +[12:13:45] <​pmlopes>​ Thread Thread[vert.x-eventloop-thread-6,​5,​main] has been blocked for 4991 ms, time limit is 2000
 +
 +[12:13:48] <​pmlopes>​ Thread Thread[vert.x-eventloop-thread-8,​5,​main] has been blocked for 5990 ms, time limit is 2000
 +
 +[12:13:50] <​pmlopes>​ io.vertx.core.VertxException:​ Thread blocked
 +
 +[12:13:52] <​pmlopes>​ at io.vertx.core.http.impl.ClientConnection.endRequest(ClientConnection.java:​339)
 +
 +[12:13:54] <​pmlopes>​ at io.vertx.core.http.impl.HttpClientRequestImpl.connected(HttpClientRequestImpl.java:​552)
 +
 +[12:13:56] <​pmlopes>​ at io.vertx.core.http.impl.HttpClientRequestImpl.lambda$connect$72(HttpClientRequestImpl.java:​515)
 +
 +[12:13:58] <​pmlopes>​ at io.vertx.core.http.impl.HttpClientRequestImpl$$Lambda$15/​1101184763.handle(Unknown Source)
 +
 +[12:14:00] <​pmlopes>​ at io.vertx.core.http.impl.ConnectionManager$ConnQueue.lambda$getConnection$55(ConnectionManager.java:​92)
 +
 +[12:14:02] <​pmlopes>​ at io.vertx.core.http.impl.ConnectionManager$ConnQueue$$Lambda$128/​234250762.handle(Unknown Source)
 +
 +[12:14:04] <​pmlopes>​ at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:​335)
 +
 +[12:14:06] <​pmlopes>​ at io.vertx.core.impl.ContextImpl$$Lambda$12/​1908698042.run(Unknown Source)
 +
 +[12:14:08] <​pmlopes>​ at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:​358)
 +
 +[12:14:10] <​pmlopes>​ at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:​357)
 +
 +[12:14:12] <​pmlopes>​ at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:​112)
 +
 +[12:14:14] <​pmlopes>​ at java.lang.Thread.run(Thread.java:​745)
 +
 +[12:14:18] <​pmlopes>​ Thread Thread[vert.x-eventloop-thread-6,​5,​main] has been blocked for 5990 ms, time limit is 2000
 +
 +[12:14:20] <​pmlopes>​ io.vertx.core.VertxException:​ Thread blocked
 +
 +[12:14:22] <​pmlopes>​ at io.vertx.core.http.impl.HttpClientRequestImpl.handleException(HttpClientRequestImpl.java:​326)
 +
 +[12:14:24] <​pmlopes>​ at io.vertx.core.http.impl.ClientConnection.handleClosed(ClientConnection.java:​307)
 +
 +[12:14:26] <​pmlopes>​ at io.vertx.core.net.impl.VertxHandler$$Lambda$28/​1528776789.run(Unknown Source)
 +
 +[12:14:27] <​pmlopes>​ at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:​333)
 +
 +[12:14:30] <​pmlopes>​ at io.vertx.core.impl.ContextImpl$$Lambda$12/​1908698042.run(Unknown Source)
 +
 +[12:14:32] <​pmlopes>​ at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:​225)
 +
 +[12:14:33] <​pmlopes>​ at io.vertx.core.net.impl.VertxHandler.channelInactive(VertxHandler.java:​99)
 +
 +[12:14:36] <​pmlopes>​ at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:​208)
 +
 +[12:14:38] <​pmlopes>​ at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:​194)
 +
 +[12:14:40] <​pmlopes>​ at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:​306)
 +
 +[12:14:42] <​pmlopes>​ at io.netty.handler.codec.http.HttpClientCodec$Decoder.channelInactive(HttpClientCodec.java:​212)
 +
 +[12:14:44] <​pmlopes>​ at io.netty.channel.CombinedChannelDuplexHandler.channelInactive(CombinedChannelDuplexHandler.java:​132)
 +
 +[12:14:45] <​pmlopes>​ at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:​208)
 +
 +[12:14:48] <​pmlopes>​ at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:​194)
 +
 +[12:14:49] <​pmlopes>​ at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:​828)
 +
 +[12:14:52] <​pmlopes>​ at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:​621)
 +
 +[12:14:54] <​pmlopes>​ at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:​358)
 +
 +[12:14:56] <​pmlopes>​ at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:​357)
 +
 +[12:14:57] <​pmlopes>​ at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:​112)
 +
 +[12:15:00] <​pmlopes>​ at java.lang.Thread.run(Thread.java:​745)
 +
 +[12:15:02] <​pmlopes>​ and the it stays there for 30 minutes printing the same exception
 +
 +[12:17:02] <​purplefox>​ get a stack dump
 +
 +[12:17:07] <​purplefox>​ it might be a deadlock
 +
 +[13:06:43] <​purplefox>​ temporalfox:​ another EventBusMetrics question:
 +
 +[13:06:44] <​purplefox>​ void handlerUnregistered(H handler);
 +
 +[13:07:19] <​purplefox>​ What is the argument passed in here? It appears to be untyped
 +
 +[13:09:52] <​temporalfox>​ the argument is the object returned by handlerRegistered,​ which is a callback object of the implementation
 +
 +[13:14:05] <​purplefox>​ why does the metrics need to know that?
 +
 +[13:31:29] <​temporalfox>​ because it makes the SPI implementation typed and avoid casts
 +
 +[13:31:59] <​temporalfox>​ for instance
 +
 +[13:32:00] <​temporalfox>​ https://​github.com/​vert-x3/​vertx-dropwizard-metrics/​blob/​master/​src/​main/​java/​io/​vertx/​ext/​dropwizard/​impl/​EventBusMetricsImpl.java
 +
 +[13:32:17] <​temporalfox>​ public void handlerUnregistered(HandlerMetric handler) {
 +
 +[15:26:48] <​melvinross>​ is there anyway to use npm modules with js vertx in conjunction with maven?
 +
 +[15:42:19] <​melvinross>​ or just through regular vertx run?
 +
 +[15:43:32] <​pmlopes> ​  ​@melvinross you can use npm modules with maven at least like this: https://​mrhanlon.com/​posts/​using-npm-bower-and-grunt-with-maven/​
 +
 +[15:43:56] <​pmlopes>​ or if your code is just javascript you can just use npm
 +
 +[15:45:21] <​pmlopes>​ http://​vertx.io/​blog/​vert-x3-says-hello-to-npm-users/​
 +
 +[15:49:43] <​melvinross>​ yeah, i was just trying to avoid it since it means adding nodejs as a deployment dependency
 +
 +[15:50:38] <​melvinross>​ i wonder how that maven solution will work with creating fat jars
 +
 +[15:51:46] <​cescoffier>​ melvinross: what kind of npm modules do you want to use ?
 +
 +[15:52:16] <​cescoffier>​ melvinross: if you just want to resolve them and embed them in a fat jat, you can use the frontend-maven-plugin
 +
 +[15:52:35] <​cescoffier>​ melvinross: this plugin installs node locally, and is able to resolve npm modules
 +
 +[15:52:47] <​cescoffier>​ (it can also call grunt, bower or gulp)
 +
 +[15:53:05] <​melvinross>​ at the moment, the elastic search module. i may just write an async http client
 +
 +[15:53:53] <​cescoffier>​ you can do it using the front-maven-plugin then.
 +
 +[15:54:04] <​cescoffier>​ sorry: frontend-maven-plugin
 +
 +[15:54:15] <​cescoffier>​ https://​github.com/​eirslett/​frontend-maven-plugin
 +
 +[15:55:13] <​cescoffier>​ you configure it to retrieve node and npm, and then a second execution to resolve your npm
 +
 +[15:55:30] <​cescoffier>​ if you place them in the right directory, it should work smoothly
 +
 +[15:56:06] <​melvinross>​ thanks for the suggestions
 +
 +[15:56:11] <​alvaro_sanchez>​ purplefox: I will be pushing code for my talk [unknown:​ldquo]Vert.x vs Ratpack[unknown:​rdquo] in this repo: https://​github.com/​alvarosanchez/​vertx-vs-ratpack
 +
 +[15:56:28] <​alvaro_sanchez>​ any feedback will be appreciated :)
 +
 +[16:03:22] <​cescoffier>​ alvaro_sanchez:​ how are you starting the vert.x app ?
 +
 +[16:04:15] <​alvaro_sanchez>​ at the moment I just have a hello world. I will create proper gradle-based applications in the following days
 +
 +[16:08:04] <​cescoffier>​ if you use a fat jar, you don't need the @Grab
 +
 +[16:12:35] <​alvaro_sanchez>​ yeah I know, I just wanted to have that running directly
 +
 +[16:13:13] <​alvaro_sanchez>​ making a JAR doesn'​t prove the point for a hello world (ie: it's an additional step)
 +
 +[16:15:39] <​alvaro_sanchez>​ I just created that repo, and the hello worlds are just the first step
 +
 +[16:15:57] <​alvaro_sanchez>​ but my goal is to write a simple REST API in both techs
 +
 +[16:16:38] <​alvaro_sanchez>​ and they'​ll be proper gradle-based projects, thus no more Grab's
 +
 +[16:17:30] <​cescoffier>​ cool
 +
 +[16:17:35] <​cescoffier>​ will follow ti
 +
 +[16:18:26] <​alvaro_sanchez>​ thanks!
 +
 +[16:54:56] <​melvinross__>​ cescoffier: thanks for the help. it ended up being a bit of a bust, it can load the module, but fails on relative loads from the module itself, but it was a good exercise
 +
 +[16:55:47] <​cescoffier>​ you embed all the modules in the fat jar ?
 +
 +[16:55:57] <​melvinross__>​ yeah
 +
 +[16:56:29] <​melvinross__>​ the files definitely in there. can see it in file-roller
 +
 +[16:57:26] <​cescoffier>​ oh I see, one of the NPM modules is calling '​requires'​
 +
 +[16:57:34] <​melvinross__>​ yep
 +
 +[16:57:39] <​cescoffier>​ we may not support this case yet
 +
 +[16:57:47] <​cescoffier>​ as it's our own '​requires'​
 +
 +[16:59:01] <​melvinross__>​ in case you were wondering, the easiest way i found to get the node modules into the fat jar via shader was to change the workingDirectory to being inside of src/js
 +
 +[16:59:20] <​cescoffier>​ pmlopes: are you around ?
 +
 +[16:59:40] <​cescoffier>​ Paulo knows much more things about node, so he may see the issue
 +
 +[17:04:30] <​jtruelove>​ temporalfox,​ big takeaways on hawkular?
 +
 +[17:04:40] <​temporalfox>​ jtruelove hi
 +
 +[17:04:51] <​temporalfox>​ actually we drawed a path toward inclusion in stack for 3.2
 +
 +[17:05:04] <​temporalfox>​ and we also discussed possiblity to have a single metrics project
 +
 +[17:05:14] <​temporalfox>​ containing dropwizard, hawkular in the future
 +
 +[17:05:20] <​jtruelove>​ interesting
 +
 +[17:05:23] <​temporalfox>​ and perhaps your work
 +
 +[17:05:26] <​temporalfox>​ to share  things
 +
 +[17:05:31] <​temporalfox>​ like configuration option
 +
 +[17:05:53] <​jtruelove>​ yeah i put together vertx-bosun as well which is still pretty immature
 +
 +[17:05:54] <​temporalfox>​ for instance, in dropwizard it's possible to define which server URI are reported
 +
 +[17:06:06] <​temporalfox>​ so there is a Match Data Object
 +
 +[17:06:14] <​temporalfox>​ and hawkular plans to have something similar
 +
 +[17:06:23] <​temporalfox>​ would make sense to have something common with unified configuration
 +
 +[17:06:45] <​jtruelove>​ gotcha yeah opentsdb is very generic it's just a time series db that allows for tagging data points
 +
 +[17:06:47] <​temporalfox>​ in your case, I see hawkular reporting and opentsdb reporting having similar design with timer
 +
 +[17:06:59] <​temporalfox>​ would be possible to have somethign common
 +
 +[17:07:11] <​temporalfox>​ and just change the actual reporting
 +
 +[17:07:20] <​jtruelove>​ yeah i think i'll keep the verticle for listening right now and then everyone publishing to it
 +
 +[17:07:28] <​temporalfox>​ jtruelove ok
 +
 +[17:07:42] <​jtruelove>​ otherwise i'd have to elect one instance as '​the'​ consumer
 +
 +[17:08:07] <​temporalfox>​ I think in this case the actual reporter could be a straight client (using httpclient for instance)
 +
 +[17:08:08] <​jtruelove>​ which isn't the worst but it kinda of overloads one thread with all the reporting work + whatever else it's doing
 +
 +[17:08:10] <​temporalfox>​ or the event bus
 +
 +[17:08:18] <​temporalfox>​ it would not matter
 +
 +[17:08:26] <​temporalfox>​ the common stuff would just filter and collect metrics
 +
 +[17:08:40] <​temporalfox>​ and timely flush this to the actual TSDB
 +
 +[17:08:51] <​temporalfox>​ (for TSDB I mean hawkular or opentsdb or influx or...)
 +
 +[17:08:59] <​jtruelove>​ yeah and that works as long as you generically collect
 +
 +[17:09:04] <​temporalfox>​ there are many these days :-)
 +
 +[17:09:08] <​jtruelove>​ it's true
 +
 +[17:09:20] <​jtruelove>​ so that all the info you need is there when it hits the reporter
 +
 +[17:09:28] <​temporalfox>​ yes
 +
 +[17:09:40] <​temporalfox>​ I don't think we have time for this in 3.2
 +
 +[17:09:48] <​temporalfox>​ as thomas needs first to finish his stuff
 +
 +[17:09:56] <​temporalfox>​ and 3.2 is for end of novebmer
 +
 +[17:10:15] <​temporalfox>​ but after, I think consolidation is definitely interesting
 +
 +[17:10:29] <​temporalfox>​ (pretty much like vertx-auth consolidates Shiro, Mongo or Jdbc auth)
 +
 +[17:25:46] <​jtruelove>​ yeah and i'm more than happy to help out
 +
 +[17:26:05] <​jtruelove>​ first step is just wrapping up vertx-opentsdb so it can be used by SPI
 +
 +[17:26:15] <​jtruelove>​ as writing timing metrics in your code is a pain in the ass
 +
 +[17:59:13] <​jtruelove>​ temporalfox once you get the docs on how to integrate with vertx gen i can incorporate that stuff as right now i see the annotations but don't know where to start
 +
 +[18:01:03] <​jtruelove>​ have you seen the stuff we are doing with exovert at all? https://​github.com/​cyngn/​exovert
 +
 +[18:06:52] <​temporalfox>​ jtruelove what do you expect from these docs exactly ?
 +
 +[18:15:36] <​jtruelove>​ just a walk through / tutorial on how to use and support the code generation features
 +
 +[18:47:17] <​temporalfox>​ so you mean for writing a polyglot API ?
 +
 +[18:47:24] <​temporalfox>​ jtruelove so you mean for writing a polyglot API ?
 +
 +[18:48:21] <​jtruelove>​ yeah more less
 +
 +[18:48:27] <​jtruelove>​ err or less
 +
 +[18:48:49] <​temporalfox>​ what is your goal ?
 +
 +[18:48:56] <​jtruelove>​ although as long as your library uses the event bus you can sorta get that anyway
 +
 +[18:48:56] <​temporalfox>​ I mean what would you do better with that ?
 +
 +[18:49:19] <​jtruelove>​ i guess if you want your library usable from any of the vertx languages you'd need that right?
 +
 +[18:49:35] <​temporalfox>​ what it buys is to have a polyglot API
 +
 +[18:49:40] <​temporalfox>​ so you have typed client
 +
 +[18:49:48] <​temporalfox>​ it can also use event bus with service proxies
 +
 +[18:50:22] <​temporalfox>​ so you have polyglot service proxies that invoke via event bus the underlying service
 +
 +[18:50:50] <​jtruelove>​ yeah that is what i was alluding to more or less with the event bus comment above
 +
 +[18:50:59] <​temporalfox>​ ok
 +
 +[18:50:59] <​temporalfox>​ the current guide talks more about the concept of codegen which are targetted from shim implementors
 +
 +[18:51:06] <​temporalfox>​ but it should / could be read by api designers
 +
 +[18:51:17] <​temporalfox>​ there should be a complementary guide for api authoring
 +
 +[18:51:26] <​temporalfox>​ that explains the setup
 +
 +[18:51:36] <​jtruelove>​ like so you want a niced typed metric publisher for any lang even though you deploy the consumer in java etc..
 +
 +[18:52:01] <​jtruelove>​ how you would get that is with the gen stuff it seems
 +
 +[18:52:21] <​jtruelove>​ granted they could look at the docs and see oh i can write my own i send to this topic with this message structure
 +
 +[18:52:28] <​jtruelove>​ it just lowers the barriers to use etc..
 +
 +[21:13:10] *** ChanServ sets mode: +o purplefox