[vertx-2] Where do setTimer() and setPeriodic() callbacks run?

[Kaj Magnus Lindberg]

Hi,

This is for Vert.x 2 (we haven't upgraded to 3 yet). If I have a verticle, and do this:

public class WannaWork extends Verticle {

    public void start(final Future<Void> startedResult) {

        vertx.setTimer(initialDelay, oneShotTimerHandler -> {

            workWorkWork();

            vertx.setPeriodic(refreshInterval, periodicTimerHandler -> workWorkWork());

        });

then will workWorkWork() run in the Vert.x event loop in a single threaded thread safe manner, like other requests to the verticle via the event loop?

Or will it run in a parallel multi threaded manner so that there will be concurrency problems if workWorkWork() modifies member fields?

Can I for example inside workWorkWork() safely do, say, this:

    Map newMap = ...

    this.someMap.retainAll(newMap);

    this.someMap.put(...);

    this.whatever = "something else";

(nothing here is thread safe)

?

Or would this result in concurrency bugs & undefined behavior?

I had a look at the docs:

http://vertx.io/vertx2/core_manual_java.html#delayed-and-periodic-tasks

http://vertx.io/vertx2/api/java/org/vertx/java/core/Vertx.html#setTimer(long, org.vertx.java.core.Handler)

-- but they don't say anything about where the timer callback runs (inside Vert.x loop or in "any" "random" thread). Didn't find anything in this forum either.

We actually have a verticle that calls setPeriodic, which triggers a computation that takes fairly long — but whilst this computation is running, the verticle is still able to reply to requests on the event loop (!) which makes me think the setTimer & setPeriodic callbacks don't run in the same verticle in a single threaded manner.

Best regards,

KajMagnus

[Tim Fox]

On 15/03/16 12:41, Kaj Magnus Lindberg wrote:

Hi,

This is for Vert.x 2 (we haven't upgraded to 3 yet). If I have a verticle, and do this:

public class WannaWork extends Verticle {

    public void start(final Future<Void> startedResult) {

        vertx.setTimer(initialDelay, oneShotTimerHandler -> {

            workWorkWork();

            vertx.setPeriodic(refreshInterval, periodicTimerHandler -> workWorkWork());

        });

then will workWorkWork() run in the Vert.x event loop in a single threaded thread safe manner,

Yes, Vert.x guarantees that a standard verticle instance is only ever executed using the same thread (the event loop).

See:

http://vertx.io/vertx2/manual.html#concurrency

Also

http://vertx.io/vertx2/manual.html#event-loops

"...
When a standard verticle instance is deployed, the server chooses an event loop which will be assigned to that instance. Any subsequent work to be done for that instance will always be dispatched using that exact thread.
..."

like other requests to the verticle via the event loop?

Or will it run in a parallel multi threaded manner so that there will be concurrency problems if workWorkWork() modifies member fields?

Can I for example inside workWorkWork() safely do, say, this:

    Map newMap = ...

    this.someMap.retainAll(newMap);

    this.someMap.put(...);

    this.whatever = "something else";

(nothing here is thread safe)

?

Or would this result in concurrency bugs & undefined behavior?

I had a look at the docs:

http://vertx.io/vertx2/core_manual_java.html#delayed-and-periodic-tasks

http://vertx.io/vertx2/api/java/org/vertx/java/core/Vertx.html#setTimer(long, org.vertx.java.core.Handler)

-- but they don't say anything about where the timer callback runs (inside Vert.x loop or in "any" "random" thread). Didn't find anything in this forum either.

We actually have a verticle that calls setPeriodic, which triggers a computation that takes fairly long — but whilst this computation is running, the verticle is still able to reply to requests on the event loop (!) which makes me think the setTimer & setPeriodic callbacks don't run in the same verticle in a single threaded manner.

Best regards,

KajMagnus

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/02892e83-f00b-4a23-ac7c-6b4ed5c9c1c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kaj Magnus Lindberg]

Hi Tim,

Thanks for the quick reply. It helped us narrow down the possible sources of the not-desired behavior we were seeing,

and the problem was this:   when.all(promises).then(stuff -> {

That is, the vertx-when module ( https://github.com/englishtown/vertx-when ) —

    — we were using it in the wrong way, so it turned out it switched to another thread, rather than staying in the Vert.x event loop.

Best regards,

KajMagnus