Vertx timers vs Quartz

[Oren Shvalb]

Hi,

I'm implementing a server side application using the latest Vert.X 3.1.0.

as a part of my code I need to schedule future tasks that run some code in the background; I currently using Quartz

which internally, I believe, manages thread pool. 

I believe that this approach might cause me troubles in case  Quartz thread and Vertx's main loop try to access same data.

so I wonder what is a better approach, ofcourse I can lock things, but it would be bad for Vertx.

I know Vertx supportsa timers functionality, Can it replace Quartz? assuming I have very simple needs...

Does Vertx timers do not spawn new threads?

Hope my question makes sense...

Thank you.

[jordan.h...@gmail.com]

Vert.x timers do not spawn new threads, they effectively use the existing thread context. So, if you schedule a timer in a verticle thread, the timer callback will be called in that thread. 

If thread safety is a concern, you can also use the Vert.x Context to execute a callback on the correct context from a Quartz thread to ensure both aren't accessing the same resources concurrently.

--
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 http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/57575673-fbb5-4d43-8f8c-0a66f15b6d78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Oren Shvalb]

Hi,

If I understand correctly, there shouldn't be a problem using Vertx timers instead of Quartz and that also ensures thread safety, correct?

By the way, Do you happen to have code example how to use Quartz along with Vertx Context callback?

Thanks :-)

[jordan.h...@gmail.com]

On Oct 9, 2015, at 1:19 PM, Oren Shvalb <oren....@gmail.com> wrote:

Hi,

If I understand correctly, there shouldn't be a problem using Vertx timers instead of Quartz and that also ensures thread safety, correct?

Right. This should be perfectly fine. Thread safety issues are only introduced when you use Vert.x with some other library that triggers callbacks on its own internal threads, in which case you must take care to use the Vert.x Context to access data structures on Vert.x threads.

By the way, Do you happen to have code example how to use Quartz along with Vertx Context callback?

I wish I did. I really should stop answering questions on my phone so I can write code in responses more often :-)

Thanks :-)

On Friday, October 9, 2015 at 12:53:50 PM UTC-4, Oren Shvalb wrote:

Hi,

I'm implementing a server side application using the latest Vert.X 3.1.0.

as a part of my code I need to schedule future tasks that run some code in the background; I currently using Quartz

which internally, I believe, manages thread pool. 

I believe that this approach might cause me troubles in case  Quartz thread and Vertx's main loop try to access same data.

so I wonder what is a better approach, ofcourse I can lock things, but it would be bad for Vertx.

I know Vertx supportsa timers functionality, Can it replace Quartz? assuming I have very simple needs...

Does Vertx timers do not spawn new threads?

Hope my question makes sense...

Thank you.

--

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 http://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/9305b279-c9c2-49b2-84b1-a98803a91405%40googlegroups.com.

[Oren Shvalb]

Thank you very much - I think I'll dump Quartz on behalf of Vertx!

On Friday, October 9, 2015 at 12:53:50 PM UTC-4, Oren Shvalb wrote:

[Oren Shvalb]

Hi again,

I'm trying to switch from Quartz and some basic functionality is missing for me.

In Quartz you create a scheduler with a "JobKey" and you are responsible to give the key as input.

This is very good because in case you would like to cancel the job you know what is the key.

as opposed, in Vertx, when you call a timer then Vertx is responsible to create an ID and YOU are supposed to manage this ID, meaning store it and retrieve it when needed.

This overhead of managing the IDs put a damper for me...

Am I missing something??

[jordan.h...@gmail.com]

Indeed, you're right. You are essentially responsible for associating a timer ID with a some logical representation of a timer. Depending on the implementation, that can become somewhat of a hassle. Maybe some improvements can be made to the timer API in the future, but for now you have to store the timer ID in some meaningful way if you need to later cancel the timer.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/12253487-1f74-4fb9-b1da-11832e395cfc%40googlegroups.com.

[bytor99999]

Yes, you have to take control of that. Vert.x will make no assumptions or take an opinionated view on if or when you need to store that information. Vert.x has the basic Timer implementation to allow you to run timers. If you need more control over cancelling, and also if you plan on doing distributed timers, meaning a timer is created on one Vert.x instance that you need to cancel that timer on a different Vert.x instance in the cluster, than you have to do a little but more. Like not only saving the id of that timer, but also which instance it was started on. Because each instance will start their own set of timerIDs and they can easily overlap across Vert.x instances in a cluster.

Mark

[Oren Shvalb]

Thanks for the comment Mark, 

I really needs those timers distributed among my nodes and using Halzelcast I will do it.

Good luck to you !