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

[11:53:54] <bcd> say i have 100 instances of a worker verticle, and i'd like to stop some blocking operation on one of those instances, is that possible? if so, how would I do that?

[11:56:28] <Sticky_> afaik vertx does not explicitly interrupt blocking operations, you would have to code the ability to do that yourself

[11:57:06] <Sticky_> may be wrong here though, not used worker verticles/blocking all that much

[12:07:11] <bcd> it does appear that way yeah Sticky_, can't find anything about it :)

[12:07:16] <bcd> does anyone know for sure?

[12:53:28] <qsys_> about the metrics spi: for example, in the EventBusMetrics, what is exactly the difference between messageSent en messageWritten?

[12:59:31] <qsys> Sticky_: you have to implement it yourself. I suppose you use 'executeBlocking()'? The code there is executed in some thread from a thread pool. It's generally not a good idea to kill threads, but you might implement some logic in you code which can stop executing whenever you send some atomic(?) boolean to false?

[13:09:26] <Sticky_> yeah, whatever it is that is blocking needs to either support being interrupted or implement a service that can be stopped via some signal like an isRunning flag

[13:15:40] <qsys_> the latter is pretty easy to implement: if you have an atomic boolean, in your 'service' (blocking code), you have to watch that value. In your other code, you can set it to true/false whenever you want. Just wondering, what's the use case?

[14:43:02] <bcd> qsys_: i'm trying to create something that sends values to a worker verticle that has several instances. an instance will then compute something using those values, but this may take an arbitrary amount of time. so i'd also like to be able to stop that computation when I feel the need to.

[14:58:08] <Sticky_> I did mention before that vertx could do with an “executeBlockingWithTimeout” method

[14:58:44] <Sticky_> that would return with an exception if it didnt exit in time

[15:09:12] <bcd> Sticky_: i'll look into that, thanks :)

[15:11:10] <Sticky_> bcd: well I think what you should do is use CompletableFuture

[15:11:23] <Sticky_> and a call to

[15:11:28] <Sticky_> so get with a timeout

[15:12:39] <Sticky_> so have your processing return its result as a CompletableFuture, and the blocking process can just call the get to wait for the result, that will timeout if its not back in time

[15:14:10] <bcd> ah, and I can call cancel on that as well, maybe this is what i need :)

[15:23:08] <Sticky_> bcd: oh yeah, one issue is that CompletableFuture does use its own executor, or you can optionally provide one, so as this will not be running on a vertx thread pool the normal vertx concurrency guarentees will go out the window