Differences

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

Link to this comparison view

irc:1465855200 [2017/05/27 13:44] (current)
Line 1: Line 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_>​ 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: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>​ https://​github.com/​wildfly-swarm/​wildfly-swarm-vertx
 +
 +[23:28:40] <​BadApe>​ i was wondering if there might be official elastic search support?