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

[00:36:02] *** ChanServ sets mode: +o temporalfox

[10:41:32] <ppatiern> temporalfox: hi

[10:41:47] <temporalfox> ppatiern hi

[10:42:23] <ppatiern> is there some contraindication to add toString override for debugging porpouse in a @DataObject ?

[10:42:53] <ppatiern> at least using @GenIgnore ?

[10:45:56] <temporalfox> I think it should be ok

[10:46:05] <temporalfox> in data object only get/set/add methods are retained

[10:46:08] <temporalfox> others are ignored

[10:46:19] <ppatiern> so @GenIgnore is not needed

[10:47:39] <ppatiern> btw writing down doc for Kafka client … I think today it should be ready with a good doc and examples ;)

[11:17:46] <temporalfox> cool

[11:17:57] <temporalfox> I'm working on web-site

[11:18:01] <temporalfox> doc page

[11:18:10] <temporalfox> I'll add an IoT section for mqtt-server

[11:18:21] <temporalfox> the other day to fix the mqtt-server bug I used Paho client

[11:18:32] <temporalfox> it was quite hard to use

[11:18:44] <temporalfox> and also it starts many threads

[11:18:50] <temporalfox> which could be a problem

[11:18:58] <temporalfox> if you need to connect to many servers

[11:19:05] <temporalfox> but that's probably not a use case , WDYT ?

[11:20:38] <ppatiern> yes in general an mqtt client connects to only one broker

[11:20:49] <ppatiern> even if you have an mqtt brokers cluster in bridge mode

[11:20:55] <ppatiern> the client still connects to only one of them

[11:21:26] <ppatiern> great idea about the IoT section !

[11:22:22] <ppatiern> I think that the IoT section we could mention even the AMQP bridge and Vert.x Proton, other than the Kafka client

[11:22:40] <ppatiern> of course they are crossed scenario (even not in IoT) but AMQP and Kafka are used in IoT as well

[11:24:30] <temporalfox> yes in brokers mode

[11:24:44] <temporalfox> we do have already a messaging section

[11:24:44] <temporalfox> and amqp / proton are there

[11:24:48] <temporalfox> kafka is not only IoT

[11:24:56] <temporalfox> Iiut would rather go in messaing

[11:25:17] <ppatiern> even amqp is not only IoT anymore

[11:25:36] <ppatiern> so as I said there are crossing scenario … components which are used for messaging and IoT

[11:25:42] <ppatiern> IoT is about messaging :-)

[11:31:04] <temporalfox> so we are rather talking about marketting here

[11:31:14] <temporalfox> how should we present it on web site

[11:32:44] <temporalfox> website :

[11:32:44] <temporalfox> Vert.x MQTT Server is able to handle connections, communication and messages exchange with remote MQTT

[11:32:46] <temporalfox> clients. Its API provides a bunch of events related to protocol messages received by clients and

[11:32:46] <temporalfox> exposes allow to send messages to them.

[11:32:48] <temporalfox> can we do better ?

[11:33:02] <temporalfox> I rewroed a bit what comes from the github repo

[11:34:10] <ppatiern> we can always do better … but these 3 lines explain what it offers

[11:34:32] <ppatiern> btw I don't think that we are talking about marketing because at this point I can say that even MQTT can go under messaging

[11:34:43] <ppatiern> but it's mostly used in IoT

[11:36:07] <ppatiern> and the MQTT v5 spec is trying to fill all the gaps it has related to a full messaging protocol like AMQP

[16:54:22] <temporalfox> ppatiern shall we do the kafka review tomorrow ?

[16:54:27] <temporalfox> I'm seing good progress on the doc

[16:54:33] <ppatiern> I think so

[16:54:42] <ppatiern> just finishing some other stuff

[16:56:44] <temporalfox> we should maybe have an example app sometimes

[16:56:49] <temporalfox> with kafka / mqtt / grpc

[16:56:54] <ppatiern> yep

[16:56:56] <temporalfox> I'm suret there is somehting great to do

[16:56:56] <ppatiern> agree

[16:56:58] <temporalfox> as example app

[16:57:06] <ppatiern> we have to think about it

[16:57:10] <temporalfox> yeah

[16:57:14] <temporalfox> too bad we couln' go to summit

[16:57:24] <temporalfox> crossing fingers for IOT conf you submitted recently

[16:58:15] <ppatiern> yes ! I'm already in cross finger mode :-)

[16:59:09] <temporalfox> maybe we should join proposal to JavaOne :-)

[16:59:16] <temporalfox> like we tried

[16:59:23] <temporalfox> I think we have some good chances

[16:59:34] <ppatiern> when will it be ?

[17:00:17] <ppatiern> ohps sorry … jumping into a call … catch you tomorrow for the review :-)

[17:00:23] <ppatiern> and talking about JavaOne ;)

[17:05:17] <temporalfox> yup

[17:50:58] <temporalfox> ploffay hi

[17:55:38] <ploffay> hey

[18:12:16] <temporalfox> ploffay

[18:12:25] <temporalfox> I would like to discuss tracing a bit if you have some time

[18:12:43] <temporalfox> I'm starting to investigate a bit

[18:13:09] <temporalfox> it seems you are doing stuff related to that, aren't you ?

[19:52:00] <laudatio> hi there

[19:53:23] <laudatio> why my sender is lacking of some metrics?

[19:54:17] <laudatio> for example bei verticle sender have the verticles.<VerticleName>-metrics but not my verticle receiver

[19:54:20] <laudatio> is that normal?

[22:33:29] <ploffay> temporalfox, sorry I had to go, yes I'm doing I would like ask some questions too :)

[22:33:42] <temporalfox> a-hi again

[22:34:42] <temporalfox> what is your questions ?

[22:34:53] <ploffay> did you see the issue?

[22:36:58] <ploffay> I have working tracing for web server.. I wanted to somehow propagate tracing context across handlers, and I'm struggling with that

[22:37:44] <ploffay> (I'm quite new to vertx)

[22:38:23] <ploffay> What is your question?

[22:39:11] <temporalfox> yes I know your problem

[22:39:15] <temporalfox> taht's what I'm investigating

[22:39:22] <temporalfox> I think we cannot have this working

[22:39:26] <temporalfox> taht's my opinion today

[22:39:36] <temporalfox> we cannot propagate seriously a context

[22:39:45] <temporalfox> without rewriting some parts of Vert.x

[22:40:00] <temporalfox> and I believe it should not be at vertx level but at Netty level instead

[22:40:42] <temporalfox> you would like to propagate the tracing to event bus or http client

[22:40:58] <temporalfox> my opinion is that we should do differently and not rely on something magic

[22:41:09] <temporalfox> something explit

[22:41:10] <temporalfox> like

[22:41:28] <temporalfox> Trace trace = tracer.get(request);

[22:41:53] <temporalfox> and then reuse to configure an HttpRequest or an EventBus message

[22:42:25] <temporalfox> trace.set(clientRequest)

[22:42:42] <ploffay> yes basically I would like to propagate context across the whole stack: request goes in in http handler, start trace or continue one and then propagate it across all handler, but the granularity should be also considered, you don't want to create spans for every handler…

[22:43:35] <temporalfox> I don't know about that :-)

[22:43:41] <ploffay> Other thing is that tracing context (span context) should be accessible to the user, they might want to create spans to represent their business logic etc.

[22:43:45] <temporalfox> but my opinion is that we cannot propagate magically

[22:44:18] <temporalfox> perhaps you might want to contribute something for vertx

[22:44:24] <temporalfox> an api for using tracing in vertx

[22:44:29] <temporalfox> I don't know :-)

[22:44:45] <temporalfox> but I'm definitely strong on having this automagic context propagation

[22:44:57] <ploffay> well vertx is amazing :)

[22:45:02] <temporalfox> strong against

[22:45:04] <temporalfox> at the moment

[22:45:43] <temporalfox> I think we'll merge the event bus interceptor PR because it has other usages

[22:45:53] <temporalfox> but the current PR for context propagation is useless

[22:46:02] <temporalfox> it does not propagate things :-)

[22:46:07] <ploffay> this?

[22:46:09] <temporalfox> or in a limited fashion

[22:46:20] <temporalfox> yes see my last comment

[22:48:34] <ploffay> you are right context propagation should be as explicit as possible to avoid weird things..

[22:48:49] <ploffay> I will definitely spend more time on vertx

[22:48:52] <temporalfox> ok

[22:49:05] <temporalfox> let me know if there is something you want to contribute

[22:49:16] <temporalfox> (in the future)

[22:49:36] <temporalfox> my opinion is that if ppl do stuff like this

[22:49:52] <temporalfox> server less kind of style would be good

[22:49:57] <temporalfox> because you just provide a function

[22:50:12] <temporalfox> and the server can manage the request and the clients

[22:50:19] <temporalfox> but that's another topic

[22:51:11] <ploffay> thanks, about that Router tracing what I have right now, would you like to have it in vertx repo?

[22:53:13] <temporalfox> not yet, we need to discuss

[22:53:21] <temporalfox> perhaps we would have rather a tracing project

[22:53:32] <temporalfox> and in this project there would be a vertx-web router

[22:53:35] <temporalfox> as module

[22:53:43] <temporalfox> can you point out the code though ?

[22:53:54] <temporalfox> it could be also a vertx web module

[22:53:55] <temporalfox> I don't know

[22:54:11] <temporalfox> we haven't yet started to discuss all of that

[22:54:16] <temporalfox> at the moemnt I would say the best

[22:54:26] <temporalfox> is that you release it somehow as you want for the community

[22:54:31] <temporalfox> and you add it to vertx-awesome page

[22:54:33] <temporalfox> if you can do that

[22:54:42] <temporalfox>

[22:55:26] <ploffay> that would be great for start

[22:55:44] <ploffay> let see how it develops

[22:56:59] <temporalfox> +1

[22:57:13] <temporalfox> don't hesitate to go on vertx-dev google group

[23:00:53] <ploffay> +1, mi impression is that distributed tracing in vertx would find its place