4/13/2017 4:25:24 PM
used timezone-2010-to-2020 js file, which wis working. However, its name got changed when moment timezone upgraded to 0.5.13. In this change, we replace the file by the full-time-range timezone js, which will permanently stay and should not be changed in future. Also, we add some moment js tests to guarantee moment js working.
|
|
|
4/10/2017 5:36:04 PM
3.19.0
#975 reported a bug that the name of moment-timezone js is not
right, and gradle can not fetch it to distribution package.
Tried ligradle build, and figured out that the latest moment-timezone js 0.5.13 is not compatible iwht 0.5.5, since the js file built's name doesn't keep the same.
We use `^` to specify compatible js libraries (see details in https://docs.npmjs.com/misc/semver). In this change, we disable it to in order to secure repo.
|
4/10/2017 1:49:15 PM
are log files tracked by Git
e.g. under azkaban.test.executions.logtest
|
|
|
4/10/2017 1:04:28 PM
process.
|
4/10/2017 12:39:03 PM
using the Apache DBCP library has the following
Properties set: setValidationQuery("/* ping */ select 1"); setTestOnBorrow(true);
The library will do the validation of the connection every time
a connection is borrowed from the pool.
See
https://arviarya.wordpress.com/2013/02/15/apache-dbcp-connection-pool-revisited/
The DB monitoring thread is not necessary and adds overhead and
complexity.
|
|
|
4/4/2017 7:59:23 PM
3.18.0
(#955)
If a flow run for longer than 10 days (configurable), kill it.
|
4/4/2017 5:04:45 PM
for execution. (#959)
It consists of following changes:
1. Old code will execute two same flows if they are being submitted at the same time even though concurrent running option is disabled. We use combination of project name, flow name and a fixed suffix to synchronize on making sure submitting flow method is mutual exclusive to same flows' different submissions.
2. Add log before a scheduled flow starts.
3. Checks the running candidate as well in submitExecutableFlow. There're two threads: producer thread which puts flow to be executed into the waiting queue, and consumer thread which polls from the queue and dispatch for execution. There's a short period between consumer polls an flow(runningCandidate in the code) from the waiting queue and dispatching it, during which the flow is neither in waiting state and running state. At that time, producer checks the flow is not in waiting queue and running queue, then puts it in the waiting queue. Then two same flow are going to be dispatched together. The fix is making the runningCandidate as shared variable so that it can be checked by producer as well. This won't fix the race condition 100% since there always could be mis-synchronization in between, but it reduces the chance a lot.
|
