Differences

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

Link to this comparison view

irc:1447974000 [2017/05/27 13:44] (current)
Line 1: Line 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