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

[00:23:32] <AlexLehm> temporal_: do you mean there is new fix in Netty?

[01:06:50] <AlexLehm> its fixed in the vertx code, ok

[14:18:31] <LostCoder> Hello

[14:19:02] <cescoffier> Hello

[14:19:18] <LostCoder> I either found a bug, or the naming is very confusing

[14:19:53] <LostCoder> vertx.eventBus().publish(…) and vertx.eventBus().publisher(…)

[14:20:23] <LostCoder> should do similar things right (the first publishes to all consumers) the second returns a publisher that can publish to all consumers?

[14:21:04] <cescoffier> nope

[14:21:12] <cescoffier> yes the naming is a bit confusing

[14:21:15] <LostCoder> thats why the naming confused me

[14:21:30] <cescoffier> vertx.eventbus().publisher() only send

[14:22:13] <LostCoder> what is a vertx.eventbus().sender() then?

[14:22:44] <cescoffier> wait a sec, I'm checking

[14:23:34] <cescoffier> sorry

[14:23:51] <cescoffier> so publisher.send sends, publisher.write publishes

[14:24:41] <LostCoder> yes, I saw that (right now).

[14:25:02] <cescoffier> I confirm it's a bit confusing to not have the `publish` method there

[14:25:18] <cescoffier> I think you can open a usability issue

[14:26:20] <LostCoder> will do thanks

[14:26:22] <cescoffier> (and even a PR that just call `write`)

[14:36:14] <LostCoder> would it not be better to change the send method to call “write” instead of “doSend”?

[14:36:51] <LostCoder> then the publisher.send(…) and a sender.send() will do there respective tasks.

[14:37:51] <cescoffier> a message publisher should be able to publish (send to all), send (send to 1), and send and reply (send to 1, expect a reply)

[14:38:39] <LostCoder> okay.

[15:09:29] <LostCoder> The discovery service stuff you are working on for 3.3.0. Do you guys eventually want the service to be bi-directional. For example, consul. When I register my endpoint, it will publish too consul to be used by other systems. Currently it only “reads” from consul.

[15:25:34] <cescoffier> LostCoder : yes it should be bidirectional, however we didn't have time to develop the export so far

[15:43:09] <tsegismont> temporal_, hi in io.vertx.core.http.impl.ConnectionManager.QueueManager#getConnQueue

[15:43:18] <temporal_> hi

[15:43:32] <tsegismont> temporal_, is there a reason to not do : return queueMap.computeIfAbsent(address, k → new ConnQueue(version, this, address));

[15:44:12] <temporal_> no, not really it would't change much

[15:44:23] <tsegismont> the form above has a big advantage: the ConnQueue is created just once

[15:44:32] <tsegismont> And so the SPI callback is called just once

[15:44:33] <temporal_> right

[15:44:38] <tsegismont> With the other form

[15:44:50] <tsegismont> It's possible to have createEndpoint called multiple times

[15:44:54] <temporal_> yes good catch

[15:44:56] <tsegismont> without closeEndpoint being called

[15:45:00] <tsegismont> issue and PR ?

[15:45:01] <temporal_> that's important

[15:45:02] <temporal_> race

[15:45:04] <temporal_> yes

[15:45:06] <tsegismont> k

[15:45:39] <temporal_> good catch

[15:46:08] <tsegismont> thanks :)

[15:47:34] <temporal_> in reality

[15:47:41] <temporal_> well that's fine

[15:48:42] <tsegismont> in the dropwizard impl you mean?

[15:48:47] <tsegismont> in this case, yes

[15:48:53] <temporal_> no I mean that if we would not use your patch

[15:49:11] <temporal_> then the metric creation would have to happen outside of the constructor

[15:50:53] <tsegismont> I have a preference for the version which is 1 LOC and keeps the metrics reference in the constructor

[16:00:26] <temporal_> ah yes yours is better

[16:00:42] <temporal_> need a note about the fact that there is the metrics creation in the constructor

[16:00:44] <temporal_> comment

[16:01:03] <temporal_> / Make sure we build it once - since metrics creation is done in the constructor of the queue

[20:59:11] <gastaldi> temporal_, cescoffier is 3.3.0.CR2 out?

[21:00:42] <cescoffier> gastaldi : YES !

[21:00:49] <gastaldi> AWESOME! :D

[21:00:58] <gastaldi> can you guys release the vertx-jca adapter too?

[21:02:32] <temporal_> gastaldi it is released

[21:02:36] <gastaldi> sweet

[21:02:38] <gastaldi> thank you so much!

[21:02:41] <temporal_>

[22:07:52] <AlexLehm> temporal_: I think I made a general mistake in the unit tests for the mail project

[22:07:59] <temporal_> hi AlexLehm

[22:08:01] <temporal_> what is it ?

[22:08:03] <AlexLehm> I have test classes called

[22:08:09] <AlexLehm> and these are not run by surefire I think

[22:08:38] <AlexLehm> not really a bug though, but the mvn builds are missing some tests

[22:08:43] <Sticky> if you annotate them with @Test it will

[22:08:58] <AlexLehm> i think that doesn't work

[22:09:09] <AlexLehm> it seems it doesn't work

[22:09:17] <AlexLehm> works when I run the tests in Eclipse though

[22:09:34] <Sticky> hmmm

[22:09:40] <gastaldi> afaik surefire ignores every class that does not have the Test suffix

[22:09:48] <AlexLehm> it looks like that

[22:10:15] <AlexLehm> when I run a single test classes with -Dtest=SomeTest2 it works

[22:10:46] <temporal_> it comes from the surefire plugin configuration

[22:10:55] <temporal_> that uses the pattern *Test

[22:11:02] <temporal_> well just rename it

[22:11:12] <AlexLehm> this is not a big problem, but I have tried to build the project against CR2 and i have one unit test that fails

[22:11:33] <AlexLehm> i will check why the test fails

[22:12:02] <temporal_> ok

[22:12:10] <temporal_> CR are here for that !

[22:12:31] <AlexLehm> i guess the test probably failed before, but I didn't run all tests in Eclipse regularly

[22:12:32] <AlexLehm> grrr

[22:15:06] <gastaldi> blame surefire for that ;)

[22:15:32] <AlexLehm> the main reasn w

[22:15:52] <AlexLehm> the main reason why i didn't notice that is that the CI uses maven obviously and it looks ok there

[22:24:31] <temporal_> yeap

[22:24:43] <temporal_> software development these days is full of traps!

[22:24:54] <temporal_> finally I'm glad we got CR2 out :-)

[22:27:07] <gastaldi> temporal_, fixed, it was a module issue

[22:27:29] <gastaldi> but I agree that we should be using CDI instead of JCA

[22:27:38] <gastaldi> JCA sucks

[22:27:44] <temporal_> :-)

[22:28:12] <gastaldi> also, I think it's worth removing that unused file from the jca adapter project

[22:28:25] <temporal_> have you been able to make it work with CR2 ?

[22:28:38] <gastaldi> yes

[22:28:41] <gastaldi> just pushed

[22:28:56] <gastaldi>

[23:28:40] <BadApe> i was wondering if there might be official elastic search support?