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

[00:48:28] <paulecoyote> Hi do any of you have an advice for cancelling a verticle that has triggered off a long running task? E.g. request for image processing that posts increasingly better interim results over time

[00:52:03] <paulecoyote> If I go offline and any of you have insight in to anything like that, please tweet @paulecoyote

[01:42:56] <Guest8325> 00

[09:47:45] <cescoffier> pmlopes : are you around ?

[09:49:29] <pmlopes> yes

[09:56:26] <cescoffier> pmlopes : did you see the phoenix issue ?

[09:56:50] <pmlopes> yes, in order to fix it we need to do an api change

[09:56:51] <cescoffier> the main issue there is the JDBC implementation of Phoenix. It's definitely not complete.

[09:56:55] <cescoffier> exactly

[09:57:04] <cescoffier> while at the same time, the issue is more on the phoenix side

[09:57:25] <cescoffier> unfortunately, columns do not make sense for them (HBase)

[09:57:43] <pmlopes> yeap

[09:57:50] <cescoffier> so, I was thinking trying to ask them what they think about it

[09:58:03] <cescoffier> if they have plans to support it, or if it's a “no way”

[09:58:25] <pmlopes> yes that would be a good idea

[09:59:04] <cescoffier> ok, let me do that, will tell you what they say

[10:01:29] <cescoffier> _purplefox : is 3.2 still planed for X-Mas ?

[10:19:01] <_purplefox> cescoffier: yeah, i don't see why not. looks like we are on schedule

[10:19:23] <cescoffier> _purplefox : yes, we are. There is a big update of hazelcast coming

[10:19:40] <cescoffier> _purplefox : with a new discovery API we should use to support DNS based discovery

[10:19:49] <_purplefox> cool

[10:20:00] <cescoffier> _purplefox : the RC1 is available, so hopefully, the final release will be there soon and I can work on that

[10:20:05] <_purplefox> is this the “dns based discovery (cloud/kubernetes) - James Strachan / Clement” task from the roadmap?

[10:20:15] <cescoffier> _purplefox : yes

[10:20:16] <_purplefox> i moved it too 3.3 for now, but we can move it back if you think it will be ready in time

[10:20:48] <cescoffier> _purplefox : ok, perfect. It really depends on the availability of the new HZ.

[10:21:19] <cescoffier> _purplefox : this discovery API is going to be pretty cool for us, as we can change the discovery mechanism and keep the distributed data structure.

[10:21:48] <cescoffier> _purplefox : for instance it would be very easy to plug etcd or something based on DNS, and keep the rest of Hazelcast in place

[10:28:16] <_purplefox> sounds good

[14:59:04] <cescoffier> pmlopes : did you try keycloak for the oauth stuff ?

[14:59:38] <pmlopes> no, i noticed that it is a huge package and needs lots of stuff configured and did not have enough time to go over its documentation

[15:00:33] <pmlopes> i'll try to use the docker image and see if i can test it

[15:11:30] <cescoffier> yes it's not that easy to set up

[15:11:45] <cescoffier> (I looked at it as it's used in hawkular)

[15:14:03] <cescoffier> pmlopes : jpkroehling may be able to help you.

[15:14:15] <cescoffier> (in the #hawkular room)

[19:07:47] <AlexLehm> is there a way I can select which certificate is used for upgrading a netsocket to ssl? Assume I have more than one private key in the store and I know only when the connection is already accepted which name I want to present

[23:43:57] <AlexLehm> paul_e_coyote: getting back to your question from yesterday, I assume you have to implement some kind of messaging event that is caught in the verticle that shutdown the processes at the next possible or kills the programs or whatever

[23:48:00] <paul_e_coyote> I think so? The vertx future doesn't seem to have an interrupt or cancel I can glom on too

[23:48:17] <paul_e_coyote> and I'm trying to play nice with the single thread verticle thing

[23:48:52] <paul_e_coyote> Currently experimenting with Java's “CompletableFuture” with it all

[23:49:28] <paul_e_coyote> but I've come back to Java after about a decade away from it to use vertx, so I'm ramping back up on the language itself too

[23:52:18] <paul_e_coyote> My main concern about making something iterruptable cleanly is to not mess up vertx's own expectations about what is going on by using Java's own threadpool

[23:53:05] <paul_e_coyote> e.g. I don't want the eventbus to be aborted accidently or anything like that. I guess workers don't matter so much? But yeah I feel like I'm going a little off the grid. None of the examples seem to cover anything like this