Add java concurrency & oauth, update k8s

Author: Bharathi Ramana Joshi

java-concurrency.md

@@ -0,0 +1,80 @@
+# Chapter 2
+- Re-entrant lock: same thread can acquire same lock any number of times (e.g.
+  subclass first acquires it and calls superclass method which again acquires).
+- Every java reference can be used as a lock via the `synchronized` block.
+
+# Chapter 3
+- The compiler can reorder memory management instructions causing *visibility*
+  issues: changes made to shared memory by one thread are not visible to other
+  threads.
+- Visibility can happen due to objects being stored in cache etc.
+- `volatile` keyword can be used to mark a reference as being used by multiple
+  threads and disable caching, forcing the JVM to load the object each time.
+- The most common use for volatile variables is as a completion, interruption,
+  or status flag.
+- Use volatile variables iff:
+  1. Writes to variable does not depend on current value
+  2. Variable does not participate in invariants with other state variables
+  3. Locking is not required for any other reason while variable is being
+     accessed
+- Semantics of volatile variable are not strong enough to make increment
+  operator ++ atomic.
+- Out-of-thin-air safety: a shared variable read by a thread will have a value
+  written to it by some other thread (and not some garbage value). Only
+  exception is non-volatile 64-bit numbers (long/double).
+- Publishing an object: making it available to code outside of its current
+  scope.
+- Publishing an object should be done in a thread-safe, synchronized manner.
+  Otherwise an incompletely constructed object may get published.
+- Any object reachable from a published object by following some chain of
+  nonprivate field references and method calls has also been published.
+- Alien method of a class C is any method whose behaviour is not fully
+  specified by C. E.g. methods in other class instances of C are passed to and
+  overrideable methods in C.
+- (anonymous) inner classes also capture the reference to containing superclass
+  and can publish the object.
+- Publishing an object from within its constructor can publish an incompletely
+  constructed object.
+
+# Chapter 5
+- Collections like `Map`, `List`, etc would require threads to lock entire
+  collection to ensure correctness with concurrent access.
+- `ConcurrentModificationException`: an unchecked exception thrown when a
+  collection that is being read (via an iterator) is changed concurrently by
+  some other thread.
+- `ConcurrentModificationException` is a good faith exception meaning best
+  effort is made to throw it, but no guarantee that it will thrown upon a
+  concurrent modification.
+- Hidden iterators like `println("Set = " + set)` can also throw
+  `ConcurrentModificationException` since above code gets translated to a call
+  to an iteration of the set.
+- `ConcurrentHashMap`:
+   + arbitrary number of readers
+   + limited number of writers
+   + low performance penality on single core
+   + weakly consistent (approximately correct): iterator may or may not reflect
+     concurrent updates
+   + `size` and `isEmpty` are approximate
+   + only when application needs to lock Map for exclusive access the
+     ConcurrentHashMap is not correct replacement
+- Copy-on-write collection
+- `BlockingQueue`: blocks threads on queue underflow and overflow.
+- Implementations of `BlockingQueue`:
+   + LinkedBlockingQueue
+   + ArrayBlockingQueue
+   + PriorityBlockingQueue
+   + SynchronousQueue: queue of threads, consumer should always be ready to
+     participate in hand-off from producer; otherwise producer will block
+- Work stealing pattern: consumers can consume from other consumer's queue
+- Deque: double eneded queue used for work stealing pattern
+- `CountDownLatch`: `await` and `countDown`
+- `Semaphore`: `acquire` and `release`. Fair if FIFO is followed in granting
+  the permits.
+
+# Chapter 6
+- Executor: separates task submission from task execution.
+- RejectedExecutionException: exception thrown when a task submitted to an
+  executor is not run.
+
+# Chapter 14
+- Use `wait`, `notify`, `notifyAll` on any `Object` for conditional variables.

k8s.md

@@ -15,7 +15,7 @@
   * Fault tolerance
 - Manifest: initial configuration.
 - Cluster -> Node -> Pod -> Container -> Application/microservice.
-- Pod: abstraction over containers to proivde a uniform communication interface
+- Pod: abstraction over containers to provide a uniform communication interface
   irrespective of underlying container (may be docker or something else).
 - Node: physical server/VM on which pods are running.
 - Each pod is assigned an IP address, not each container in the pod.
@@ -25,14 +25,20 @@
 - 1 control plane / master
 - kube-API server: interface to interact with master.
 - etcd: highly available key-value store for shared configuration, service
-  discovey, and scheduler coordination.
+  discovery, and scheduler coordination.
 - kube-scheduler: handles pod creation and management, match/assign any node to
   create and run pods.
 - Controller/manager: responsible for node detection, setting up network
   routes, setting up load balancers, volumne management
 - Components of a node:
   * Kubelet: agent running on each node that communicates with master via API
     server. Runs on port 10255.
-  * Container engine: docker etc. Exposing containers on port specified in
+  * Container engine/runtime: docker etc. Exposing containers on port specified in
     manifest.
   * Kube-proxy: assigns an IP address to each pod.
+- Deployment: manages a set of Pods to run an application workload, usually one
+  that doesn't maintain state. A Deployment provides declarative updates for
+  Pods and ReplicaSets. You describe a desired state in a Deployment, and the
+  Deployment Controller changes the actual state to the desired state at a
+  controlled rate
+- 

oauth.md

@@ -0,0 +1,40 @@
+- OAuth is about authorization, NOT authentication
+- OAuth concepts:
+  * Resource owner
+  * Resource server
+  * Grant type: process used to request and grant authorization
+  * Scope: permission that is being requested (read-write access, profile access, etc)
+  * Auth server: where grant type and scope are sent for authorization
+  * Token: string on successful authorization
+  * Claims: details on authorization granted
+- OAuth core
+  * authorize endpoint: used by end user (resource owner) to grant permission
+    for application to access resource. Returns authorization code or access code
+  * token endpoint: used by application to trade authorization code for an
+    access token
+- Optional endpoints:
+  * userinfo (OpenID core connect)
+  * discovery: gives all URLs and capabilities of OAuth server
+  * introspect: get token status
+  * revoke: used to deactivate a token
+- Grant type decision tree:
+  1. For a user? No => Client Credential Grant Type
+  2. Browser available? No => Device Grant Type
+  3. Server-side only? No => Implicit grant type/Authorization code flow with PKCE
+                      Yes => Authorization code flow
+- OAuth scope: CRUD or more complicted; scopes are the permissions that we
+  request not the endpoints that we use.
+- E.g. GitHub scopes: repo, public_repo, repo_deployment, repo:invite, etc
+- Some other examples: Google scope, okta
+- Some types of tokens :
+  * Access (Core RFC 6749)
+  * Refresh (Core RFC 6749)
+  * ID (OpenID connect). JSON Web Token (JWT).
+- JWTs need validating.
+- Every JWT is made of 3 parts:
+  * Header (algorithm used to sign)
+  * Payload (key-value pairs called claims)
+  * Signature (authentication)
+- Do not store sensitive information in JWTs
+- Authorization Code Flow:
+  *