Knowledge

Knowledge Aquired:

Authentication/Authorization

• https://auth0.com/blog/2014/12/02/using-json-web-tokens-as-api-keys/
• https://scotch.io/tutorials/the-anatomy-of-a-json-web-token/
• http://jwt.io/

Back to Quartz internals and benchmarking:

Job Groups and Trigger Groups: there is not locking or parallelisation based on groups. They are used only for logical separation of jobs and their identifiers (more details on: http://forums.terracotta.org/forums/posts/list/6010.page)

Misfire Handlers: Each job has specific time when it should be executed. If this time is exceeded by some threshold (lets say 1 minute) then jobs get updated and Misfire Handlers take over. This operation requires couple roundtrips to database and causes 30-40% performance drop.

Multiple logical Schedulers: Quartz has DB lock per Scheduler. Since 2.x we can use single database and have multiple logical Schedulers on same database in clustering mode. IMPORTANT FACT: each Scheduler is uniquely identified by its name. That means that even if we have multiple schedulers on different JVM with same name all of them will share the same LOCK. Right now in production we have only 1 Scheduler with name "schedulerFactoryBean". With multiple Schedulers we can fully parallelise job executions even on same JVM.

Job Batching: In situations when we have multiple jobs scheduled to be executed at almost the same time we can leverage fetching multiple jobs at same time which would significantly reduce number of DB calls.

So, in order to resolve PlayerSessionSaga issues following things have been improved:

1. New Scheduler created for ItemExpirationListener
2. Batch communication with DB added
3. Misfire threshold updated from 1 minute to 10 minutes