anchor.diff:      </pre>
   
       You can determine whether or not the path was specified for a previously
  -    pushed application by looking at the application deployment manifest,
  +    pushed application by examining the application deployment manifest,
       `manifest.yml`.
  -    If the `path` attribute specifies the current directory, the manifest will
  -    include a line like this:
  +    If the `path` attribute specifies the current directory, the manifest
  +    includes a line like the following:
   
       ```
       path: .
       ```
  -    To re-push just the WAR, either:
  -
  -    * Delete `manifest.yml` and push again, specifying the location of the WAR
  -    using the `-p` flag, or
  +    To re-push just the WAR, do one of the following:
  +
  +    * Delete `manifest.yml` and run `cf push` again, specifying the location of 
  +    the WAR using the `-p` flag.
       * Edit the `path` argument in `manifest.yml` to point to the WAR, and
       re-push the application.
   
  
positive.code:         JBP_CONFIG_OPEN_JDK_JRE: '[memory_calculator: {stack_threads: 800, memory_sizes: {stack: 512k}}]'
      ```
  
      In the example above, the overall memory amount reserved by the JVM for representing the stacks of Java threads is `800 * 512k = 400m`.
      <br><br>
      The correct settings for `stack` and `stack_threads` depend on your app code, including the libraries it uses. Your app may technically have no upper limit, such as in the case of [cavalier usage](http://dev.bizo.com/2014/06/cached-thread-pool-considered-harmlful.html) of `CachedThreadPool` [executors](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool--).
      However, you still must calculate the depth of the thread stacks and how much space the JVM should reserve for each of them.
  
  ### <a id='upload'></a>Troubleshoot Failed Upload ###
  
  If your application fails to upload when you push it to Cloud Foundry, it may be
  for one of the following reasons:
  
  * WAR is too large: An upload may fail due to the size of the WAR file.
  Cloud Foundry testing indicates WAR files as large as 250 MB upload
  successfully.
  If a WAR file larger than that fails to upload, it may be a result of the file
  size.
  
  * Connection issues: Application uploads can fail if you have a slow Internet
  connection, or if you upload from a location that is very remote from the target
  Cloud Foundry instance.
  If an application upload takes a long time, your authorization token can expire
  before the upload completes.
  A workaround is to copy the WAR to a server that is closer to the Cloud Foundry
  instance, and push it from there.
  
  * Out-of-date cf CLI client: Upload of a large WAR is faster and hence less
  likely to fail if you are using a recent version of the cf CLI.
  If you are using an older version of the cf CLI client to upload a large WAR, and having
  problems, try updating to the latest version of the cf CLI.
  
  * Incorrect WAR targeting: By default, `cf push` uploads everything in the
  current directory.
  For a Java application, a plain `cf push` push will upload source code and other
  unnecessary files, in addition to the WAR.
  When you push a Java application, specify the path to the WAR:
  
      <pre class="terminal">
  
negative.code:         JBP_CONFIG_OPEN_JDK_JRE: '[memory_calculator: {memory_sizes: {native: 150m}}]'
      ```
  
      This example shows that `150m` of the overall available `1G` is reserved for anything that is not `heap`, `metaspace`, or `permgen`. In less common cases, this may come from companion processes started by the JVM, such as the [Process API](https://docs.oracle.com/javase/8/docs/api/java/lang/Process.html).
  
  * **Cause 2 - High thread count**: Java threads in the JVM can cause memory errors at the Garden level. When an app is under heavy load, it uses a high number of threads and consumes a significant amount of memory.
  
  * **Solution 2**: Set the reserved memory for stack traces to the correct value for your app.
  <br>
  <br>You can use the `stack` [setting](https://github.com/cloudfoundry/java-buildpack/blob/master/docs/jre-open_jdk_jre.md#memory-sizes) of the memory calculator to configure the amount of space the JVM reserves for each Java thread. You must multiply this value by the number of threads your app requires. Specify the number of threads in the `stack_threads` [setting](https://github.com/jdeoliveira/mule-cf-java-buildpack/blob/master/docs/jre-open_jdk_jre.md#memory) of the memory calculator.
      For example, if you estimate the max thread count for an app at `800` and the amount of memory needed to represent the deepest stacktrace of a Java thread is `512KB`, configure the memory calculator as follows:
  
      ```
      ---
  