The lock is used to prevent dual writing of the same output file, and to
prevent us from generating the same data twice (if RdeStaging was run twice).
However, at times when we're creating both RDE and BRDA reports - we use the
same lock for both even though they write to different files and create
different reports.
This causes one of the two to almost always fail (when both are created, which
is once a week I think) delaying that report by several hours.
Note that the "prefix" part of the filenames has the mode in it, so different
modes will not have the same files.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168882007
Sometimes requests "die" suddenly, without going through catch/finally blocks.
If this happens, any lock they own will remain locked until it times out (which
can take hours in some cases).
This cl implicitly unlocks any lock if the owner of the lock isn't running
anymore.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168880938
Also adds a "resave all epp" cron job that's needed for the delete to work correctly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168879965
This is needed for the Lock.java enhancement where a lock will be implicitly
released if the request owning it dies.
No matter which solution we want for refactoring the Lock itself, we will need this class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167600314
This is to fix Kokoro, given the directory added in [] Also, added forgotten keyring/api directory.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167598465
We create an injectable LockHandler that just calls the static
Lock.executeWithLocks function.
I'm not sure what's the correct place to put the LockHandler. I think
model/server is only appropriate for the actual datastore lock. This is a "per request" lock, so maybe request/lock?
-----------------------------
This is the initial step in adding the "lock implicitly released on request death" feature, but it's also useful on its own - easier to test Actions when we can use a fake lock.
To keep this CL simple, we keep using the old Lock as is in most places. We just choose a single example to convert to LockHandler to showcase it. Converting all other uses will be in a subsequent CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167357564
Lessons from the first full run of the mapreduce.
Fixed the "old manifests still referenced" counter, since some of these
manifests could be new.
Added a debug "manifests incorrectly mapped multiple times" that is expected to never happen, but who knows? (this is a sort of sanity check for the mapreduce)
Added an "Epp resource revisions handled" that counts the total references, allowing for the possibility of the same manifest being referenced from multiple resources - this is expected to be equal to the map's "Epp resource revisions found" counter.
Added a "commit log manifests referenced multiple times" to see how often the same manifest is linked to from different epp resources.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166846879
It appears that there are some possible flows where the reducer runs twice on
the same key. Either because of some error in a subsequent key that makes the
entire shard become ignored and retried, or possible some obscure error outside
of the transaction on that key.
The result however is that sometimes the reducer runs on a key that has already
been deleted. We need to check for that to prevent a null pointer exception.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166112173
Sometimes rdeStaging reduce shards die after the lock is acquired. When that happens - the (automatic) rerun of the shard fails because the lock is in place causing that specific TLD to not stage and await the next call to rdeStaging.
rdeStaging runs every 4 hours, but the current lock lives for 5 hours.
This means that on the next rerun of rdeStaging, the lock still hasn't timed out so it fails again, and we have to wait for the subsequent run - a total delay of 8 hours.
Shortening the lock timeout to be less than the 4 hours rdeStaging rerun time solves this issue.
NOTE: This is just a "quick patch" solution. To really fix the rdeStaging failure we need to fix the lock itself.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166102387
The current code fails if there's no X-* header even if there is a X-GFE-*
header, although just having one of them should be enough.
Bug was introduced in []
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166091723
Right now - if there's an error during DnsWriter.publish*, all the publish from
before that error will be committed, while all the publish after that error
will not.
More than that - in some writers partial publishes can be committed, depending
on implementation.
This defines a new contract that publish* are only committed when .commit is
called. That way any error will simply mean no publish is committed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165708063
When trying to run the MapReduce for DeleteOldCommitLogsAction, we run into a
lot of DatastoreTimeoutException during CommitLogManifestReader.next.
This causes the entire shard to fail. Since we have a lot of keys (tens of
millions), this is almost guaranteed to happen, dooming the entire MapReduce.
Here is an attempt to recover from the Timeout Exception by saving the state
before the read, then on failure restoring that state and trying again.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165172222
Added to make it clear that the order of the keys in the map is important. A
better solution would be, of course, to make the order unimportant.
This can be done by using ImmutableSortedMap either as input or with copyOf
the input. But the create function is only used once, so it doesn't seem worth the effort - as long as we make sure to throw an error if the order is wrong.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164515959
Attempting to run DeleteOldCommitLogs in prod resulted in a lot of DatastoreTimeoutException errors. The assumption is that attempting to load so many CommitLogManifests (over 200 million of them), when each one has a slight possibility of failure, has a very high probability of error.
The shard aborts after 20 of these errors, and by eliminating as many loads as possible and retrying the remaining loads inside a transaction we are effectively eliminating any exceptions "leaking" out to the mapreduce framework, which will hopefully keep us bellow 20. At least, that's our best guess currently as to why the mapreduce fails.
EppResources are loaded in the map stage to get the revisions, and CommitLogManifests are only loaded in the reduce stage for sanity check so we don't accidentally delete resources we need in prod. Both of these are wrapped in transactNew to make sure they retry individually.
The only "load" not done inside a transaction is the EppResourceIndex, but there's no getting around that without rewriting the EppResourceInputs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164176764
It was buggy (didn't work) and was never actually used.
Why never actually used: for it to be used executeWithLock has to be called
with different requesters on the same lockId. That never happend in the code.
How it was buggy: Logically, the queue is deleted on release of the lock (meaning it was
meaningless the only time it mattered - when the lock isn't taken). In
addition, a different bug meant that having items in the queue prevented the
lock from being released forcing all other tasks to have to wait for lock
timeout even if the task that acquired the lock is long done.
Alternative: fix the queue. This would mean we don't want to delete the lock on release (since we want to keep the queue). Instead, we resave the same lock with expiration date being START_OF_TIME. In addition - we need to fix the .equals used to determine if the lock the same as the acquired lock - instead use some isSame function that ignores the queue.
Note: the queue is dangerous! An item (calling class / action) in the first place of a queue means no other calling class can get that lock. Everything is waiting for the first calling class to be re-run - but that might take a long time (depending on that action's rerun policy) and even might never happen (if for some reason that action decided it was no longer needed without acquiring the lock) - causing all other actions to stall forever!
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163705463
This is a quick fix we can hopefully get out fast before fixing the underlying problem.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163485468
"The passage of time" caused the test to start failing because the test data
given by ICANN includes certificates that expire on 2017.
Using a fake clock to make sure the "now" date is always in the valid
certificate range solves this issue.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162987171
The dry run does all the steps except the deletion. All the counters will
return the same values they would have returned on an actual run.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162379609
This change is motivated by the sandbox run where we saw the backend instances overwhelmed by the 100 default shards to the point where they couldn't even answer a simple status request.
Production has 50 backend instances, so 20 will leave a lot of spare for other tasks.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162357857
We want to be safer and more explicit about the authentication needed by the many actions that exist.
As such, we make the 'auth' parameter required in @Action (so it's always clear who can run a specific action) and we replace the @Auth with an enum so that only pre-approved configurations that are aptly named and documented can be used.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162210306
Now instead of deleting "all logs older than X", we delete "all logs older than
X that don't have any EppResource.getRevision()" pointing to them.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161455827
Changed [] to use v1 instead of v1beta1, and replaced v1beta1 with v1 in all the java files.
If there is special build rules for open-source etc. that also need to be updated, or non "TAP-able" tests that need to be run, please check and see if they are OK.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157895888
Moving to KmsKeyring, any command that uses the Keyring must be a
RemoteApiCommand to work.
TESTED: successfully encrypted a file with no logged errors.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155673003
Replace KeystoreKeyring with ComparatorKeyring between KeystoreKeyring and
KmsKeystore. In the opensource version, will replace DummyKeyring with
KmsKeyring directly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152893767
Cloned from CL 149476124 by 'g4 patch'.
Original change by shikhman@shikhman:registry-secrets-2:897:citc on 2017/03/07 15:37:09.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151950797
There will now be "resultToString" and "resultEquals" to stringify / compare
the method results.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150135475
guybenandjianglai
