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

[01:10:36] <AlexLehm> is the drainHandler only called once or do I have to disable it to avoid it getting called later?

[08:24:23] <cescoffier> @temporalfox @purplefox I've merged the docker documentation and re-organisation. It covers Java, Groovy, Ruby, JavaScript, Maven image creation, Fabric8, Fat Jar and the different configuration settings. The documentation is integrated into the vertx docs distrib.

[08:25:02] <cescoffier> Here is the doc on Github:

[09:00:03] <temporalfox> cescoffier is it packaged with stack-docs zip and ?

[09:00:16] <cescoffier> yes

[09:00:32] <cescoffier> (well let me check - but it should)

[09:00:34] <temporalfox> is it linked from web-site ?

[09:00:42] <cescoffier> not linked yet

[09:00:45] <temporalfox> ok

[09:01:06] <cescoffier> that's on my Today Todo List

[09:02:06] <cescoffier> temporalfox I confirmed it's in both distrib

[09:03:01] <temporalfox> good :-)

[09:03:07] <cescoffier> pmlopes - I've added a note in the documentation about your comment. You are right it's a convolution, but it's the only way to turn around this Docker limitation.

[09:40:45] <pmlopes> purplefox, temporalfox, cescoffier: never mind any strange comments on vertx-examples github for a while, i am testing the setup of automatic PR builds

[09:44:51] <purplefox> pmlopes: ok, cool :)

[10:00:21] <cescoffier> pmlopes can I push minor changes on the examples ?

[10:00:39] <purplefox> cescoffier: sure

[10:00:53] <purplefox> any small changes/fixes you can push directly to master

[10:00:59] <cescoffier> I just don't want to interfere his work

[10:01:19] <purplefox> ah, ok you mean the stuff paulo is doing? maybe best ask paulo

[10:01:40] <purplefox> doh, sorry thought it was a general question ;)

[10:01:58] <purplefox> temporal_: is is possible to get some feedback from codetrans in the vertx-examples project

[10:02:16] <pmlopes> cescoffier: yes

[10:02:24] <purplefox> temporal_: i want to see why it doesn't generate codetrans for the vertx-web rest example but i can't see anything in the output of the build

[10:02:27] <cescoffier> pmlopes: thanks

[10:04:45] <purplefox> temporal_: i'm guessing the simple rest example doesn't translate because it uses member variables…

[10:05:42] <cescoffier> waht's the polling period on the vert.x3-stack job ?

[10:13:37] <purplefox> cescoffier: i think it runs once per day sometime after midnight

[10:13:42] <purplefox> and then it also runs if a push is made

[10:14:02] <purplefox> and everything depends on vertx-core so if it runs then it triggers everything else to rebuild

[10:14:06] <cescoffier> not sure the 'push' part is working then

[10:14:19] <cescoffier> I've made two pushes on it, and it did not trigger the build

[10:14:40] <purplefox> do you have a cloudbees login? if so i can make you an admin too

[10:14:47] <purplefox> then you can have a play around

[10:15:06] <cescoffier> that's a tricky question - I've tons of cloudbees loing, need to find a suitable one ;-)

[10:15:26] <cescoffier> can you add 'clement.escoffier at gmail dot com'

[10:16:32] <pmlopes> purplefox: for automated PR builds I need to configure the webhooks, however I am not admin of the project… Alternative you can create a access token from your account and i will use that on cloudbees

[10:17:35] <purplefox> cescoffier: done :)

[10:18:03] <cescoffier> works, thanks !

[10:18:19] <cescoffier> hum no…

[10:20:30] <cescoffier> it does….

[10:44:58] <temporal_> purplefox yes we don't support yet member variables or methods

[10:45:11] <temporal_> purplefox we could in the future I think but that measn some work

[10:45:35] <temporal_> purplefox in vertx-examples there is a log file generated with what's going on

[10:46:24] <temporal_> named codetrans.log

[10:47:12] <purplefox> temporal_: great, thanks

[10:47:19] <temporal_> we could transform methods into functions I think

[10:47:25] <temporal_> void foo() {}

[10:47:29] <temporal_> function foo() in js

[10:47:29] <purplefox> temporal_: i think supporting member variables would be a good thing to support

[10:47:37] <temporal_> yes that too could be possible

[10:47:48] <temporal_> but I think it's significant work for the moment :-)

[10:47:49] <purplefox> then we can translate the REST example, for example

[10:47:55] <temporal_> I can give a try though

[10:48:10] <purplefox> maybe i can refactor the example into not using member variables for now

[10:48:21] <temporal_> that would be best if you can

[10:48:24] <purplefox> if it's a lot of work let's wait until after 3.0

[10:48:37] <temporal_> I think it's not trivial

[11:00:55] <temporal_> purplefox I can start a branch with this feature and see how it goes

[11:01:07] <temporal_> if it's possible to do it, it would be done

[11:01:14] <temporal_> otherwise it would be merged later after 3.0

[11:01:23] <temporal_> at the end it's about generating example

[11:01:48] <temporal_> and not a critical feature

[11:22:53] <purplefox> temporal_: agreed

[12:07:26] <cescoffier> purplefox: any reason why 'deployVerticle' does not return the vertx object ?

[12:08:14] <purplefox> no particular reason I am aware of

[12:09:16] <cescoffier> it's probably cosmetic, but we could change it so we don't introduce an API change later, WDYT ?

[12:10:09] <purplefox> i think that's fine :)

[12:10:29] <cescoffier> there is quite some method that do return void, we should delay

[12:10:41] <purplefox> btw.. when submitting PRs against master (e.g. your latest vertx-examples one) can you ask someone to review it before merging? That's the normal development process unless the change is small

[12:10:43] <cescoffier> right, let's keep it like that, and see if people ask

[12:11:10] <cescoffier> ok no problem will ask, here it was small

[12:21:23] <purplefox> cescoffier: np

[12:21:45] <cescoffier> I'm reading your comment, you are right, would be better without the inner class

[12:22:27] <cescoffier> I need a way to identify which server is responding (to illustrate the round robin)

[12:23:56] <purplefox> you could pass the id into the config when deploying, or you could just use the System.identityHashcode(this).

[12:24:19] <purplefox> config might be nicer

[12:25:19] <purplefox> vertx.deployVerticle(verticleClassName, new DeploymentOptions().getConfig().put(“id”, “server1”));

[12:27:16] <cescoffier> does context.getDeploymentId would be different ?

[12:28:46] <purplefox> deploymentID is unique per deployment not per verticle, so if you deploy 10 instances in a single call to deployVerticle then they will share the deploymentID

[12:29:13] <purplefox> right so config won't work either in that case

[12:29:26] <purplefox> so probably just use hashcode or something i guess

[12:34:18] <cescoffier> hashcode would be fine I think, it's just to illustrate.

[12:35:17] <purplefox> +1

[12:46:09] <purplefox> cescoffier: pmlopes temporal_ : folks, I am going to spend some time today doing a gap analysis of vert.x 3 to determine what remains to be done (gaps in docs, examples, functionality etc), so we can put a list together

[12:46:24] <purplefox> if you can also think of anything, please add to list too

[12:46:33] <purplefox> then tomorrow we can discuss what's left to do

[12:46:38] <purplefox> for the final push

[12:48:41] <cescoffier> ok, I've opened in issue on vertx core this morning

[12:48:56] <cescoffier> about OSGi metadata, not sure you want it for the release or not

[12:49:12] <purplefox> ah yes OSGI, that would be good to have :)

[12:49:21] <purplefox> so people can drop the jars in Karaf or something to deploy

[12:49:40] <purplefox> now it is good that you are an OSGI expert because none of us are ;)

[12:50:06] <pmlopes> OS what? :P

[12:50:22] <cescoffier> ok, as soon as I'm done with what I'm doing right now (the sharing example and associated doc) I would move to that, should be ready for tonight

[12:50:26] <purplefox> pmlopes: lol

[12:50:33] <purplefox> cescoffier: awesome

[12:51:22] <cescoffier> we go with a cheap integration for now, I've aideas for later about this (exposing the event bus and the vert.x object as service … as I do in wisdom)

[12:58:53] <purplefox> yeah, i think just simple metadata is ok for now (?)

[14:02:18] <pmlopes> purplefox: i will start with the “missing” web examples

[14:02:42] <cescoffier> The docker manual is now online:

[14:11:00] <aesteve> Hello everyone :)

[14:23:11] <purplefox> aesteve: hi

[14:39:46] <aesteve> I'm trying to add implementations of TemplateEngines for Groovy users and there's stuff I just can't deal with

[14:41:03] <aesteve> basically, I'd like my class to 'implement' io.vertx.groovy.ext.web.templ.TemplateEngine so that users can just use it naturally in their groovy code

[14:41:16] <aesteve> but I can't, since TemplateEngine is a class in Groovy

[14:41:45] <purplefox> not sure i follow - you want to write a new template engine class?

[14:41:54] <aesteve> yep, but Groovy only

[14:42:00] <purplefox> why groovy only?

[14:42:05] <aesteve> (relying on Groovy's TemplateEngine interface)

[14:43:21] <purplefox> not sure I fully understand.. could you add some more detail?

[14:44:20] <aesteve> not sure what to add… Groovy has a TemplatEngine interface :

[14:44:29] <purplefox> yes

[14:44:42] <purplefox> and you want to wrap this in a Vert.x template engine?

[14:44:54] <aesteve> exactly

[14:45:41] <purplefox> should be pretty easy, just implement io.vertx.ext.web.templ.TemplateEngine

[14:46:02] <purplefox> and create an impl that uses the groovy templ engine. of course the groovy one is blocking :(

[14:46:13] <purplefox> so you'll need to do executeblocking i guess

[14:46:42] <purplefox> if you take a look how it's done for the other templ engines that might help

[14:46:47] <purplefox> (e.g. jade, mvel etc)

[14:46:49] <aesteve> I don't understand (not the blocking part)

[14:46:58] <aesteve> where I'm stuck is the Java vs. Groovy stuff

[14:47:21] <purplefox> ok, i suggest looking at one of our existing implementations

[14:47:26] <purplefox> e.g. the jade

[14:47:31] <purplefox> and copy that

[14:48:04] <aesteve> if I implement that in pure Java I'll have to deal with executing Groovy code inside Java

[14:48:24] <aesteve> if I implement it in Groovy I'm stuck with io.vertx.groovy.ext.web.templ.TemplateEngine which is not an interface

[14:48:46] <purplefox> what is the problem with executing groovy code from java?

[14:49:23] <purplefox> this should just work

[14:50:17] <purplefox> plus if you do it this way then not only is your new template engine usable in groovy, it's also usable in JS, Ruby etc

[14:50:35] <aesteve> I'll try it, but I never got it working in IntelliJ

[14:50:50] <aesteve> I'll try a raw “text” project and see if I can get it working

[14:51:26] <purplefox> i don't really see the issue. iirc compiled groovy class is just a java class so this should be trivial

[14:51:45] <purplefox> lots of projects have a mixture of groovy and java classes

[14:51:51] <aesteve> I know Tim

[14:52:04] <aesteve> I know it _should_ work

[14:52:19] <aesteve> thanks for your help, I'll stick to Java

[14:52:27] <purplefox> ok, np

[14:54:21] <aesteve> oh god… that's _exactly_ what I needed

[14:54:40] <aesteve> a simple jar without all the groovy language

[14:54:57] <purplefox> cool

[14:55:50] <purplefox> I actually think it will be a nice feature in vertx-web to have the groovy template (which is pretty rich) accessible from other langs too :)

[14:56:23] <aesteve> I'll restart from scratch this evening, I should have something by tomorrow

[14:57:06] <aesteve> on a completely different topic, do you know if OAuth2 will make it for the final release ?

[15:22:17] <purplefox> aesteve: i doubt it, as i'm not sure anyone is working on an implementation

[15:29:11] <cescoffier> purplefox are you around ?

[15:29:17] <aesteve> ok thx purplefox I'll just integrate a “hand-made” authentication in the example

[15:29:27] <purplefox> cescoffier: yep

[15:30:02] <cescoffier> I need to know what are the mandatory deps ov vert.x core. For instance it relies on jackson, is it absolutely mandatory ?

[15:30:38] <cescoffier> in other words does it make sense to force to have the jackson “bundle” when deploying the vert.x core bundle

[15:30:48] <cescoffier> or could we still use vert.x without

[15:32:47] <purplefox> cescoffier: yes its mandatory as we use it in jsonobject/jsonarray which is used in several places in core

[15:32:56] <cescoffier> ok, thanks.

[15:32:59] <purplefox> and pretty much all vert.x apps will use this

[15:35:43] <cescoffier> So, I will have to write a bit of documentation to list the required bundles, so people don't get completely lost

[15:44:28] <purplefox> rajith: hi rajith

[15:44:44] <purplefox> rajith: do you have a few minutes?

[15:46:22] <purplefox> rajith: well maybe half an hour ;) ( to answer some questions on the amqp-service)

[15:53:30] <rajith> purplefox: yes sir

[15:53:55] <purplefox> rajith: ok great

[15:53:59] <purplefox> is now ok?

[15:54:34] <rajith> purplefox: sure

[15:54:40] <rajith> purplefox: irc or phone?

[15:54:52] <purplefox> irc

[15:55:02] <rajith> purplefox: cool

[15:55:48] <purplefox> ok

[15:56:08] <purplefox> ok first thing: AmqpService

[15:56:42] <purplefox> i understand incoming and outgoing links

[15:56:55] <rajith> purplefox: yes

[15:57:04] <purplefox> but what are inbound and outbound routes?

[15:57:30] <rajith> purplefox: ah you read the docs :) … nice!

[15:58:10] <purplefox> yeah, i read the docs :)

[15:58:11] <rajith> purplefox: the routes are a mapping btw and AMQP link (a logical connection btw two AMQP endpoints) and a vert.x address (event-bus)

[15:58:38] <purplefox> i thought the link was a mapping between an amqp address and an event bus address?

[15:59:14] <rajith> purplefox: sorry I thought you asked by AMQP link (as in what the spec defines)

[15:59:15] <purplefox> for example:

[15:59:16] <purplefox> establishIncomingLink(String amqpAddress, String eventbusAddress, String notificationAddress,

[15:59:26] <purplefox> ok lets rewind

[15:59:49] <purplefox> aiui you have a method establishIncomingLink which maps an amqp address to an event bus address

[16:00:12] <purplefox> buy you also have other method called

[16:00:17] <rajith> purplefox: yes incoming and outgoing links as explained in the docs is a mapping btw an AMQP address and a vert.x address

[16:00:23] <purplefox> yes

[16:00:26] <purplefox> so what are the routes?

[16:00:52] <purplefox> there are methods to add and remove routes too

[16:01:02] <rajith> purplefox: yes .. let me explain

[16:01:02] <purplefox> but i don't understand what these are for

[16:01:57] <rajith> 1. So applications can directly add incoming and outgoing links and these links are directly associated with a single vert.x event-bus address

[16:02:59] <rajith> 2. The routes on the other hand can be thought of message based routing (the above is link-based routing). There are no owners for a particular AMQP link (the bridge owns and manages them on demand)

[16:03:32] <rajith> The latter is very useful when you want Verticles that have no knowledge of AMQP to send and receive messages from AMQP apps

[16:04:24] <purplefox> not sure i follow.. can you give an example?

[16:04:26] <rajith> purplefox: inbound routes –> mapping btw an AMQP message property and a vert.x address

[16:04:44] <purplefox> message property?

[16:04:51] <rajith> purplefox: outbound routes –> mapping btw a Vert.x message property and an AMQP address

[16:05:11] <purplefox> not sure what you mean by “Message property”

[16:05:13] <rajith> purplefox: as in address, subject or some application defined property

[16:05:37] <purplefox> you lost me

[16:05:50] <rajith> purplefox: one sec

[16:06:45] <rajith> purplefox: pls have a look at ?

[16:07:16] <purplefox> ok

[16:07:58] <rajith> purplefox: in this case msg1.put(“vertx.routing-key”, “”); … and “vertx.routing-key” is a message property that the bridge (or service) understands

[16:07:59] <purplefox> so basically you're embedding an amqp broker here, and the routing table is just the broker routing table?

[16:08:42] <rajith> purplefox: it could also use something like msg.put(“my-prop”, my-val);

[16:09:06] <purplefox> ok

[16:09:07] <rajith> and then have a route that says “my-val” : “my-amqp-address” in the outbound routing table

[16:09:35] <purplefox> where is the mapping between jsonobject and amqp message defined?

[16:10:10] <rajith> purplefox:

[16:10:29] <purplefox> i mean, where in the api/docs?

[16:11:15] <purplefox> in order to use this i think a user is going to need to know this information

[16:11:24] <rajith> purplefox:

[16:11:36] <rajith> purplefox:

[16:11:45] <rajith> purplefox: it mentions how the message properties are mapped

[16:12:18] <rajith> purplefox: see the headings “Retrieving AMQP message properties when receiving.” and “Setting AMQP message properties when sending.”

[16:13:07] <purplefox> is msgRef mandatory?

[16:13:09] <rajith> purplefox: I also explain in detail how routing works and how it can be configured at deploy time and runtime

[16:13:33] <rajith> purplefox: only if you want to send reliably

[16:13:58] <rajith> purplefox: as in want to get a confirmation when it's accepted/settled by the AMQP peer.

[16:14:12] <purplefox> ok

[16:14:33] <purplefox> maybe should use vert.x message properties for properties?

[16:14:35] <rajith> purplefox: it's an arbitary application defined “ref” , so when the confirmation comes, it can correlate the confirmation to a message

[16:14:45] <purplefox> i mean headers

[16:15:27] <rajith> purplefox: u mean when setting the standard headers?

[16:15:31] <purplefox> when you send a message in vert.x, you can always provide headers

[16:15:49] <purplefox> so i'm not sure you need to define your own special envelope with body, properties etc

[16:16:34] <rajith> purplefox: I want to stick to the vert.x convention as much as possible. I can make the necessary changes

[16:16:54] <purplefox> just a suggestion, it would also make it easier to send

[16:17:20] <purplefox> how is the message body mapped to the amqp message body?

[16:18:20] <rajith> purplefox: look at the convert method on line 64

[16:18:45] <rajith> purplefox: I think there's some room for improvement …. especially in the docs for this part

[16:19:11] <purplefox> ok cool. is this documented?

[16:19:13] <rajith> purplefox: it allows to send maps, lists in the proper AMQP encoded format

[16:19:51] <rajith> purplefox: all the examples talk about sending “strings” … I don't have a section yet, talking about the other supported “content-types”

[16:22:08] <rajith> purplefox: u still there ?

[16:22:15] <purplefox> yes

[16:22:45] <rajith> purplefox: so far we identified 3 things.

[16:23:05] <rajith> 1. Use vert.x message headers instead of using special envelope

[16:23:20] <rajith> 2. No documentation for different body types

[16:23:41] <rajith> 3. Explain clearly about the difference btw links and routes ..

[16:23:52] <rajith> purplefox: anything else you are concerned about ?

[16:24:12] <purplefox> i'm just going to raise more general questions here, there are a bunch more things that i can mention on the PR

[16:24:19] <purplefox> yeah, just looking through now

[16:24:49] <rajith> purplefox: that pull request is old. Do you mind if I generate a new one with the latest code ?

[16:25:01] <purplefox> hmm it's old?

[16:25:19] <rajith> purplefox: the last one is at least 2 months old ? :)

[16:25:24] <purplefox> if it's in the correct branch there is no need to recreate the PR

[16:25:40] <rajith> purplefox: ah yes … the latest code is in initial-branch!

[16:25:52] <purplefox> i'm looking at

[16:26:04] <purplefox> is that right?

[16:26:09] <rajith> purplefox: I'm fixing a big on message credits, apart from that everything else including the docs posted on my web page are in that branch

[16:26:14] <rajith> purplefox: correct!

[16:26:18] <purplefox> ok

[16:26:34] <rajith> purplefox: I thought you were looking at the pull request I created ages ago :D

[16:26:48] <purplefox> pull requests don't need to be resubmitted

[16:27:09] <rajith> purplefox: ah I didn't know that :(

[16:27:10] <purplefox> they just show a diff of the branch

[16:27:20] <rajith> gotcha

[16:27:22] <purplefox> so if its in the right branch its ok

[16:27:50] <purplefox> yeah a PR is just a diff with a fancy user interface ;)

[16:27:59] <rajith> purplefox: lol

[16:28:39] <purplefox> so.. the methods accept, reject, release - an amqp expert will understand what these mean but they won't mean much to someone who is not expert on amqp

[16:28:49] <purplefox> so maybe some explanation of those would be good

[16:30:05] <rajith> purplefox: I have the java docs on them .. perhaps I need something on the docs

[16:30:11] <rajith> purplefox: I agree with you

[16:30:35] <purplefox> the javadoc just says “Allows an application to reject a message it has received.”

[16:30:36] <rajith> purplefox: I also mention that some basic knowledge on messaging, amqp and vert.x is useful ;)

[16:30:41] <purplefox> which doesn't really help much

[16:30:50] <purplefox> as it doesn't define what “reject” means

[16:30:53] <rajith> purplefox: I agree with you

[16:31:46] <rajith> purplefox: maybe I will provide more explanation in the java docs as well as in the docs … the bloody doc is getting bigger and bigger by the min.. looks more like a book now

[16:32:16] <rajith> purplefox: after I'm done with the customer site … I plan to create a video tutorial where I hope to cover more gaps like that.

[16:32:40] <rajith> purplefox: nowadays people have no patience to read docs ;) … and perhaps link that right on the top of the doc

[16:32:51] <purplefox> i need to think more about the api for reliable messaging, the notificationhelper stuff seems a bit clunky

[16:33:29] <rajith> purplefox: I struggled a bit with that as well …. I want to make it as pain free as possible.

[16:34:25] <rajith> purplefox: the notification system is a good way to use message passing to “give” the application as much information as possible without having to use anything AMQP specific

[16:35:18] <rajith> purplefox: the notification-helper is more of convenient message parser … perhaps this is where some improvement can be made …always looking for suggestions ;)

[16:36:37] <rajith> purplefox: most people who would use the AMQP service will be interested in reliable messaging … some those banks you mentioned have existing AMQP apps they might want to interface with ;)

[16:37:00] <rajith> I meant interact with .. same meaning I guess :p

[16:37:44] <purplefox> yeah, but the api needs to be easy to use too :)

[16:38:38] <purplefox> i notice you use eventBus.publish, not eventBus.send in the examples, is this deliberate?

[16:39:00] <rajith> yes

[16:39:46] <purplefox> i assume the bridge only has one eventbus consumer on that address?

[16:39:58] <rajith> purplefox: I'm worried that there could be a vert.x consumer that might be using the same address and get that message … with publish both the Vert.x-AMQP-Service and that consumer will get the message.

[16:40:12] <rajith> purplefox: yes only one event bus consumer per message

[16:40:25] <purplefox> i wouldn't worry about that

[16:40:35] <rajith> purplefox: so in this case, I'm errering on the side of caution

[16:40:41] <rajith> purplefox: u mean just use send?

[16:40:45] <rajith> and not publish?

[16:40:48] <purplefox> now if you always use send() then you have a nicer way of notifying reliable delivery

[16:40:54] <purplefox> yes just send

[16:41:13] <purplefox> publish means “send two all recipients” but in this case there is always just one, so it seems odd to use publish

[16:41:35] <rajith> purplefox: what is the nicer way of notifying reliable delivery?

[16:41:42] <rajith> purplefox: agreed

[16:42:31] <purplefox> if you use send, then you can supply a reply handler in the call to send

[16:42:47] <purplefox> and you could use that to provide the information on whether the message was accepted or not

[16:43:01] <purplefox> then you wouldn't need all the notificationhelper stuff

[16:43:33] <rajith> purplefox: I thought about this …. but then how would handle the real request-reply stuff ? :p

[16:43:48] <purplefox> does the bridge support request reply?

[16:43:53] <rajith> purplefox: yes sir!

[16:44:06] <rajith> purplefox: in both directions .. both reliable and unreliable

[16:44:27] <purplefox> is there an example of this somewhere?

[16:44:28] <rajith> purplefox: the simple example and the more advanced fortune-cookie example shows it

[16:44:58] <rajith> purplefox: hmmmm …. this is why I think video tutorials are better … people don't read the docs :D

[16:45:21] <rajith> purplefox: the bridge can handle both request-reply and pub-sub in both directions.

[16:45:53] <rajith> purplefox: is my doc that bad??? :) … I mean if u didn't notice that then surely I've failed with the docs :)

[16:46:02] <purplefox> ha lol

[16:47:08] <purplefox> brb

[16:47:51] <rajith> purplefox: sure .. give me 5 too. Washroom break :)

[16:50:20] <purplefox> no, you're docs are not bad :)

[16:50:23] <purplefox> your

[16:50:43] <rajith> purplefox: back :D

[16:53:40] <purplefox> ok, maybe

[16:54:10] <purplefox> for non reliable messages you can just use eventBus.send directly

[16:54:30] <purplefox> but for reliable (if you want a delivery confirmation), then you could provide a little API for sending

[16:55:02] <purplefox> ReliableHelper.sendReliableMessage(message, replyHandler, notificationHandler)

[16:55:18] <purplefox> the second handler being the notification handler that will be called when a message is accepted etc

[16:56:29] <rajith> purplefox: .that sounds reasonable to me

[16:56:49] <rajith> purplefox: what about getting notified of errors, message credits etc ?

[16:57:32] <purplefox> what kinds of errors?

[16:58:30] <rajith> purplefox: lets say the link btw Vert.x-AMQP-Service (bridge) and the AMQP peer was disconnected … or it was closed by the peer due to an error or a security or resource violation

[16:58:55] <rajith> purplefox: and the Verticle (or vertx app) will be interested in knowing that

[16:59:17] <purplefox> in that case I'd expect the replyHandler to be called with a failure just like we do in the normal event bus api

[17:00:33] <purplefox> e.g.

[17:00:35] <rajith> purplefox: what about message credits? (when sending messages)

[17:00:59] <purplefox> why does the user care about message credits? isn't flow control an implementation detail of the bridge?

[17:01:56] <rajith> purplefox: for anonymous links (links that are created by the bridge on demand, based on a route match) the bridge manages them transparently

[17:02:44] <rajith> purplefox: but if you create a a link explicitly and if you want to get notified about credit then yes

[17:03:00] <purplefox> but why would you care?

[17:03:08] <purplefox> what's the use case here?

[17:03:49] <rajith> purplefox: So you know when to send and how much to send? Yes you can make the case where the bridge can try to buffer and handle that transparently.

[17:04:13] <purplefox> i don't follow

[17:04:24] <rajith> purplefox: but if you can get the application to behave more intelligently by providing more info, then some applications would like that

[17:04:42] <purplefox> in most messaging applications you just send stuff or receive stuff. flow control is an internal process

[17:04:46] <rajith> purplefox: for example look at the FortuneCookieClientVerticle

[17:04:50] <purplefox> not something explicitly done by the user

[17:05:41] <rajith> purplefox: I agree that in most cases applications wouldn't care … but in high volume situations they will definitely want more control over the process

[17:05:47] <purplefox> why?

[17:06:12] <purplefox> sure, i expect credit buffers sizes to be configurable

[17:06:16] <rajith> purplefox: so the clients don't end up flooding the service app (on either side - AMQP or vert.x)

[17:06:23] <purplefox> but that doesn't mean you need to manuallt reqyuest credits

[17:06:31] <purplefox> that doesn't follow

[17:07:01] <rajith> purplefox: The application doesn't manually request credits … instead it receives notificaiton when the other side has “issued” credits

[17:07:34] <rajith> purplefox: more like a hint to say … hey I can receive 100 more messages from you …

[17:08:18] <purplefox> ok and what i am saying is that this should be automatic. i.e. the bridge should automatically issue the credits for oyu

[17:09:02] <rajith> purplefox: there's two sides to this .. want to make sure which one you are talking about

[17:09:09] <rajith> purplefox: so use case #1

[17:09:52] <rajith> 1. If you write a “service” as a Vert.x application. You might want to explicitly control the flow. So you can service all clients fairly and also maintain some QoS

[17:10:25] <rajith> in such a situation you might want to explicitly dish out credits to each client, as an when the service deems appropriate.

[17:10:42] <rajith> Use case #2

[17:11:46] <rajith> 2. If a vert.x client is using an AMQP Service and wants to respect the flow control requirements imposed by the service, then it should wait for credits to be issue by that service so it knows it can now send “requests” without overwhelming the service

[17:12:00] <rajith> The FortuneCookie example is to illustrate that

[17:12:13] <rajith> but that is only if applications want explicit control

[17:12:30] <rajith> … Otherwise the bridge will do it underneath you don't need to worry —

[17:12:35] <purplefox> ok, but the vertx event bus doesn't support flow control yet anyway, so I wouldn't worry about that

[17:12:36] <rajith> Does that make sense?

[17:12:47] <purplefox> when it does then it would make sense to plug in to that

[17:13:01] <rajith> yes the fact that event-bus doesn't was the reason I had to come up with this strategy

[17:13:35] <purplefox> the trouble with that is when we implement event bus flow control it will look different to what you have implemented

[17:13:54] <rajith> to be honest, if the event-bus can do flow-control and reliability … it would be pretty cool as I don't have to build that additional layer!

[17:13:58] <purplefox> so i think it's better just to wait until the event bus suports it instead of having to change it further down the road

[17:14:06] <purplefox> yes exactly

[17:14:19] <rajith> purplefox: how soon is that going to happen? :)

[17:14:25] <rajith> vertx 3.1 ?

[17:14:29] <purplefox> event bus flow control - hopefully 3.1

[17:14:57] <rajith> purplefox: so how about we do this … we do bridge managed flow control for 3.0 and unreliable communication for 3.0

[17:15:21] <purplefox> sounds good

[17:15:22] <rajith> purplefox: and then add flow control and reliability when vert.x event-bus natively supports it

[17:15:40] <rajith> purplefox: more reasonable right?

[17:15:53] <purplefox> well… the event bus will never support reliability

[17:16:02] <purplefox> but it will support flow control

[17:16:25] <rajith> purplefox: ok so then I will leave reliability as it is … and I think we discussed a possible way of doing it

[17:16:31] <purplefox> yes

[17:16:49] <rajith> purplefox: sounds like a plan

[17:17:24] <rajith> purplefox: anything else you think is a concern?

[17:17:25] <purplefox> ok, thanks rajith i think i have a much better understanding of this now :) the general approach looks sound. there are a few more things that i can comment on the PR (mainly cosmetic stuff)

[17:18:12] <rajith> purplefox: I will implement the details we spoke about and ammend the docs the week after. Next week I'm in for some fun at a customer site :p

[17:19:18] <purplefox> ok cool. so realistic this is not going to make it in 3.0. we can put it in 3.1 though :)

[17:19:50] <rajith> purplefox: that sounds reasonable given that it will give me a chance to do flow control properly

[17:20:40] <purplefox> yeah, but don't think we have to get everything in, in the first version :)

[17:21:07] <rajith> purplefox: If you can push what I have into master, then anybody is willing to try it out on an experimental basis is free to use it with 3.0 :)

[17:21:17] <purplefox> and since you are a messaging guy, you should get involved in the more general discussion of design the Vert.x core interfaces for event bus flow control :)

[17:21:40] <rajith> purplefox: I'm happy to even target 3.0 - flow control and say it's coming in 3,1 :)

[17:21:55] <rajith> purplefox: sure, I'd love to help on that

[17:22:10] <purplefox> rajith: i can push it if the cosmetics are addressed (e.g. missing javadoc, indentation etc)

[17:22:34] <purplefox> anyway let me comment on the pr for those. but they should be easy fixes

[17:22:34] <rajith> purplefox: if you can make a note, then I will make sure I have them ready in a week!

[17:22:59] <purplefox> i can probably do the cosmetic stuff myself if you like.

[17:23:05] <purplefox> would you object to that?

[17:23:16] <purplefox> (mainly just changing code style)

[17:23:19] <rajith> purplefox: to be honest, I'd be very very happy to include this in 3.0 .. and we can adjust the expectations by saying flow control is going to come in 3.1

[17:23:29] <rajith> purplefox: not at all!!!!!!!

[17:23:42] <rajith> purplefox: much appreciated given I have to spend time at the customer next week

[17:23:57] <purplefox> ok let me take a look later

[17:24:01] <rajith> purplefox: thank you!

[17:24:12] <purplefox> np, thank you for doing the work :)

[17:24:25] <rajith> purplefox: happy to help .. vert.x is a cool project

[17:24:54] <millrossjez> any vert.xers going to devoxx uk?

[17:25:20] <purplefox> i don't think so

[17:25:30] <purplefox> june is a very busy time for us, bcoz of the release

[17:26:38] <millrossjez> almost got the happy path of oauth2 authentication working, but I need to do quite a bit of code tidyup and a bunch of failure path tests

[17:26:47] <millrossjez> so I'm not going to make the 3.0 release

[17:28:40] <purplefox> millrossjez: np, it can wait til 3.1 :)

[17:29:31] <millrossjez> I'm going to want someone to look over it once I've kicked it into shape a bit (and once I've tested with a couple of real oauth2 providers instead of a simulator I knocked up for testing)

[17:30:09] <millrossjez> but that can wait till after the 3.0 release, no point in reviewing it till I'm reasonably happy with the codebase (and at the moment it's very clunky)

[17:30:17] <purplefox> cool. i think there are plenty of vert.x users who will be interested in trying it out and kicking the tyres :)

[17:30:45] <purplefox> are you implementing from scratch or using a 3rd party dep (e.g. pac4j) ?

[17:31:35] <millrossjez> from scratch because it wasn't quite clear how to hook pac4j into the vertx auth setup, but with what I've learned along the way once we have an oauth2 authenticator in place, hopefully one which can be extended by anyone who wants to go beyond authentication, I'm keen to join the pac4j-vertx effort

[17:31:44] <millrossjez> I saw the post on the group about that

[17:32:04] <purplefox> i suppose one advantage of doing it from scratch is you get to really understand the protocol

[17:32:28] <millrossjez> I'd like to help the pac4j dudes integrate with the vertx auth manager, if possible, i'm not sure how easy what they've built is to do (and I didn't want to make my life harder by adding extra moving parts which might not quite fit easily)

[17:32:41] <purplefox> agreed

[17:32:47] <millrossjez> I understand the bit that does all the redirects :)

[17:32:48] <purplefox> also i think pac4j is blocking (?)

[17:32:58] <purplefox> but i could be wrong

[17:33:27] <rajith> purplefox: temporal_ is there an MQTT client/service in vertx ?

[17:33:43] <millrossjez> it might well be, whereas my approach isn't, what I'm doing is providing a trivial implementation that stores the token in the user session, but also hook points so that someone could consume/authorize with the token differently if they wanted

[17:34:37] <millrossjez> so a coder could make a new auth service/user class implementing an oauth2 service interface which uses the same handler to actually obtain a token (or fail) but uses the token differently once obtained

[17:35:35] <millrossjez> but it would be good to get all of pac4j available if possible, because there's so much there, but I suspect I'd still be struggling if I'd gone down that route

[17:50:59] <temporal_> rajith not yet, it's planned somehow for 3.1 informally

[17:51:27] <rajith> temporal_: gotcha ..tim said the same

[18:05:11] <purplefox> rajith: the current state of the amqp initial-work branch doesn't build for me:

[18:05:21] <purplefox> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project vertx-amqp-service: Compilation failure

[18:05:21] <purplefox> [ERROR] /home/tim/projects/vert-x3/vertx-amqp-service/src/main/java/io/vertx/ext/amqp/[46,8] Could not generate element for io.vertx.ext.amqp.AmqpService: null

[18:05:45] <rajith> purplefox: one sec

[18:15:13] <rajith> purplefox: I'm cleaning up and building again to make sure

[18:18:12] <rajith> temporal_: ping

[18:18:31] <temporal_> rajith yes ,

[18:18:48] <rajith> purplefox: I'm seeing this error now as well… I didn't see this before. Investigating

[18:20:33] <temporal_> docgen error

[18:20:37] <temporal_> I will investigate asap

[18:20:47] <temporal_> recently I added tokenization of javadoc

[18:20:57] <temporal_> and I think it's an edge case of this tokenization

[18:21:09] <temporal_> in clear now we parse the @param and @return for {@link}

[18:21:31] <temporal_> so probably you are referencing something in @param or @return that triggers an error

[18:21:41] <rajith> purplefox: Julien is helping me to find it … will let you know

[18:21:55] <rajith> temporal_: I see what you mean

[18:22:07] <temporal_> that helps to produce better polyglot documentation

[18:23:49] <temporal_> for instance I see in red in my IDE

[18:23:50] <temporal_> * @param options

[18:23:51] <temporal_> * Options to configure the link behavior (Ex prefetch,

[18:23:51] <temporal_> * reliability). {@link IncommingLinkOptions}

[18:23:55] <temporal_> IncommingLinkOptions

[18:24:01] <temporal_> I suspect this makes the NPE

[18:24:06] <temporal_> because this type is not resolved

[18:24:10] <temporal_> and the current code assumes it will be

[18:24:21] <temporal_> so I'm going to change the current code so it does not produces the NPE

[18:24:39] <temporal_> somehow it should make the build fail cleanly

[18:24:43] <temporal_> WDYT ?

[18:24:57] <rajith> IncomingLinkOptions is an interface in the same package

[18:24:58] <temporal_> not sure though

[18:25:09] <temporal_> it's because you have a Typo

[18:25:10] <temporal_> IncommingLinkOptions

[18:25:13] <temporal_> IncomingLinkOptions

[18:25:16] <temporal_> so your doc is not correct

[18:25:21] <rajith> ah damn it !!!!!!

[18:25:29] <temporal_> and so we can detect that

[18:25:52] <rajith> I think the change you made is great!!! … perhaps telling where the error is helpful

[18:25:54] <rajith> :)

[18:26:16] <rajith> bcos otherwise I wouldn't have caught this error unless I went through the javadoc and clicked all the links

[18:26:57] <temporal_> I will for now make a system out println :-)

[18:27:08] <temporal_> because it's nested in a lambda

[18:27:25] <temporal_> now it does print stuff like

[18:27:25] <temporal_> INFO: Generated model io.vertx.ext.amqp.AmqpService:

[18:27:26] <temporal_> Unresolved type in doc io.vertx.ext.amqp.NotificationType

[18:27:26] <temporal_> Unresolved type in doc io.vertx.ext.amqp.NotificationType

[18:27:26] <temporal_> Unresolved type in doc io.vertx.ext.amqp.NotificationType

[18:27:54] <rajith> maybe I need to pay more attention to build warnings ;)

[18:27:57] <temporal_> but I think there are some bugs :-)

[18:28:02] <temporal_> I mean with my current patch locally :-)

[18:29:08] <rajith> I don't see those warnings on my local copy … maybe new docgen version?

[18:30:33] <rajith> temporal_: btw I'm not sure why it's saying NotificationType is unresolved

[18:30:43] <rajith> temporal_: bcos it's in the same package

[18:31:00] <rajith> temporal_: am I missing something ?

[18:33:11] <rajith> temporalfox: maybe u missed my last set of message – replaying

[18:33:17] <temporalfox> rebooted

[18:33:18] <rajith> 12:30:32 PM) rajith: temporal_: btw I'm not sure why it's saying NotificationType is unresolved

[18:33:18] <rajith> (12:30:43 PM) rajith: temporal_: bcos it's in the same package

[18:33:18] <rajith> (12:30:59 PM) rajith: temporal_: am I missing something ?

[18:33:21] <temporalfox> computer froze

[18:33:25] <temporalfox> ever heard of bugs :-) ?

[18:33:29] <rajith> temporal I figured

[18:33:35] <rajith> temporalfox: lol

[18:34:25] <temporalfox> ah I know why it fails

[18:34:32] <temporalfox> I mean for notif type

[18:34:33] <temporalfox> easy

[18:34:52] <temporalfox> if (elt.getKind() == ElementKind.CLASS || elt.getKind() == ElementKind.INTERFACE) {

[18:34:54] <temporalfox> it's an enum

[18:35:15] <rajith> yes notification type is an enum :)

[18:38:25] <rajith> temporalfox: give me a shout when it's fixed. I'm glad you found the issue

[18:38:29] <temporalfox> soon

[18:38:35] <temporalfox> I'm writing a quick unit test

[18:38:39] <temporalfox> I mean quickly a unit test

[18:40:58] <rajith> temporalfox: sure .. I'm going to get some lunch. If it works, pls ping purplefox so he can continue

[18:41:08] <temporalfox> ok

[18:41:09] <rajith> temporalfox: me very hungry :D .

[18:41:22] <rajith> temporalfox: thank you!

[18:41:34] <temporalfox> almost there

[18:43:51] <temporalfox> rajith, purplefox it is fixed an pushed in codegen, the CI is going to rebuild it soon

[18:45:35] <rajith> temporalfox: thanks!

[18:48:09] <purplefox> rajith: where did the python examples in the repo come from?

[18:48:32] <rajith> purplefox: I wrote them using the python API from proton

[18:48:51] <rajith> purplefox: the doc links to proton docs and how to etc..

[18:49:31] <purplefox> ok but how is this related to the amqp service?

[18:49:53] <purplefox> i guess i don't quite understand their purpose

[18:50:22] <rajith> purplefox: these are to run against the vert.x examples

[18:50:49] <rajith> purplefox: so users have a quick way of experiencing the whole vert.x ←→ AMQP integration

[18:51:38] <rajith> purplefox: ex FortuneCookieClientVerticle ←→ Vert.x-AMQP-Service ←–>

[18:52:02] <purplefox> i see

[18:52:15] <purplefox> tbh i don't think my vert.x users will have python as one of their main languages

[18:52:20] <purplefox> s/my/most

[18:52:43] <rajith> purplefox: the java API is not ready .. otherwise I would have used that

[18:53:01] <rajith> purplefox: java would have been my first choice

[18:53:33] <rajith> purplefox: hey .. do you mind if I got and get some lunch …. I'm sooo hungry I can eat you and Julien for lunch :D

[18:53:44] <purplefox> sure

[18:53:50] <rajith> purplefox: see u in a bit

[19:09:48] <aesteve> purplefox: here we go :

[19:11:01] <aesteve> Once I have some time, I'll try to think of different “create” methods in GroovyTemplateEngine, so that the underlying groovy template engine is created automatically (not by the user)

[19:11:19] <purplefox> aesteve: cool, wanna push it to vertx-web?

[19:11:48] <aesteve> I was thinking to wait for 3.0 release (for that and the SSE stuff)

[19:12:12] <purplefox> ok fine, up to you :)

[19:12:42] <aesteve> in fact I need some time to set up a proper IntelliJ setup (working with eclipse) so that codegen processor works, docgen too

[19:13:05] <aesteve> then I can submit the whole thing without messing up

[19:13:13] <purplefox> if you push it to vertx-web you'll have all that setup already ;)

[19:13:48] <purplefox> i think you'll just need to add dep to the groovy template jar and that's it

[19:14:27] <aesteve> indeed, what I'm referring to is : setting up IntelliJ, fork vertx-web, add my stuff in it, run the tests, see if I get errors with codegen, etc.

[19:15:00] <aesteve> I don't want to do all that stuff while the release is imminent :)

[19:16:19] <purplefox> there is zero setup with intellij required :)

[19:16:23] <purplefox> just git clone vertx-web

[19:16:32] <purplefox> the import maven project, that's it :)

[19:16:47] <aesteve> I'll try to do it this weekend, you won

[19:17:16] <purplefox> and if you push a PR it's not going to affect the release as we probably won't process it until after the release ;0

[19:18:15] <aesteve> this is a very good point. I'll do it as soon as I get some free time :)

[19:19:47] <AlexLehm> I had an odd bug yesterday where I think the drainHandler is called twice sometimes

[19:21:33] <AlexLehm> I'm not sure if calls to drain handler should match 1 to 1 to the times writeQueueIsFull is true

[19:25:30] <purplefox> aesteve: no rush :)

[19:26:21] <purplefox> rajith: i have merged initial-work and added some github issues for the stuff we discussed (and others)

[19:28:58] <purplefox> AlexLehm: i'm not sure off the top of my head. if you can put together a reproducer demonstrating the bug i can take a look

[19:29:39] <AlexLehm> ok, give me minute

[19:34:35] <rajith> purplefox: hey I'm bac

[19:34:46] <rajith> purplefox: oh thats nice! thanks a lot!

[19:36:05] <purplefox> rajith: one thing i wanted to check.. i can't see many tests at all. is that to be expected at this stage?

[19:37:38] <AlexLehm> purplefox,

[19:38:15] <rajith> purplefox: if there is one weakness .. it's the lack of unit tests. I'm going to rectify this soon. Most of the testing was integration testing done manually.

[19:38:18] <purplefox> drain handler will be called whenever the write buffer is free

[19:38:35] <purplefox> rajith: i am not a fan of unit tests

[19:38:49] <purplefox> rajith: but everything in the AMQPService API should be tested

[19:39:32] <rajith> purplefox: I need to come up with some sort of mockup for this, so I could get the tests running in a CI

[19:40:16] <rajith> purplefox: allow me a week to come up with something. I will use any downtime I have next week to think about this and will implement it the next week

[19:40:35] <purplefox> rajith: mockup of what?

[19:40:55] <purplefox> not sure i follow…

[19:41:50] <rajith> purplefox: mockup is the wrong word…. I meant having an AMQP peer so that any testing of the AMQPService methods will go through the complete code path

[19:42:15] <rajith> purplefox: kind of like automated integration tests

[19:42:17] <purplefox> can't you use proton for that?

[19:42:25] <rajith> purplefox: yep

[19:44:08] <rajith> purplefox: could you point me to a test that uses vert.x running an integration test like that? as in how do I get vert.x up and running inside a test that can be automated

[19:45:50] <aesteve> Vertx vertx = Vertx.vertx()

[19:45:54] <aesteve> and you're good to go ?

[19:46:57] <rajith> aesteve: me not sure .. purplefox ?

[19:48:38] <AlexLehm> ok, then i understood the way this works wrong, so its not really an isseu

[19:49:38] <aesteve> rajith: is this the kind of stuff you're looking for ? :

[19:49:53] <aesteve> and

[19:51:06] <rajith> aesteve: I think that should do … I will experiment with a test case and see

[19:51:13] <rajith> aesteve: thanks

[19:51:36] <aesteve> look at the vertx-unit documentation, iirc there are useful examples

[19:52:47] <rajith> aesteve: having a closer look, I think this should do. Will try this and see. Thx again

[20:31:11] <purplefox> rajith: take a look at the tests in say, mongo client

[20:55:56] <rajith> purplefox: thx!

[22:02:18] <purplefox> temporalfox: do you know where vert.x docker documentation comes from? trying to build the website but its failing because it can't find this…

[22:02:31] <temporalfox> ah I know

[22:02:39] <temporalfox> it's because it's build with a profile

[22:02:54] <temporalfox> and we skip this profile in jenkins

[22:03:16] <temporalfox> I should reorg the vertx-stack

[22:03:25] <temporalfox> and actually put the docker plugin in this profile

[22:03:31] <temporalfox> instead of the entire poms

[22:03:33] <purplefox> can i build this locally for now? i need to update the website

[22:03:43] <temporalfox> do you have docker installed ?

[22:03:45] <purplefox> no

[22:03:54] <temporalfox> I can deploy the snapshot

[22:03:56] <temporalfox> for you

[22:04:07] <purplefox> ok, yes please

[22:04:07] <temporalfox> and then update the vertx-stack to build it for later