[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_> http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22vertx-jca-adapter%22
[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 SomethingTest2.java
[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: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> https://github.com/wildfly-swarm/wildfly-swarm-vertx
[23:28:40] <BadApe> i was wondering if there might be official elastic search support?