/// note

The LLM will probably translate this wrong. Interesting is only if it keeps the fixed translation when retranslating.

///

////

//// tab | Info

     * even entire message) that simultaneously:
     *
     * - _shouldn't_ be null, so we don't annotate it with @Nullable
     *
     * - _can_ be null without causing a runtime failure (because we don't want the interesting
     *   details of precondition failure to be hidden by an exception we throw about an unexpectedly
     *   null _failure message_)
     *

     * even entire message) that simultaneously:
     *
     * - _shouldn't_ be null, so we don't annotate it with @Nullable
     *
     * - _can_ be null without causing a runtime failure (because we don't want the interesting
     *   details of precondition failure to be hidden by an exception we throw about an unexpectedly
     *   null _failure message_)
     *

   * We always do timeouts in the HTTP server role. For clients, we only do timeouts after the
   * request is transmitted. This is only interesting for duplex calls where the request and
   * response may be interleaved.
   *
   * Read this value only once for each enter/exit pair because its value can change.
   */

automatically on GitHub.

If you want to contribute, start working through the TensorFlow codebase,
navigate to the
[GitHub "issues" tab](https://github.com/tensorflow/tensorflow/issues) and start
looking through interesting issues. If you are not sure of where to start, then
start by trying one of the smaller/easier issues here i.e.
[issues with the "good first issue" label](https://github.com/tensorflow/tensorflow/labels/good%20first%20issue)

<img src="/img/deployment/concepts/process-ram.drawio.svg">

And of course, the same machine would probably have **other processes** running as well, apart from your application.

An interesting detail is that the percentage of the **CPU used** by each process can **vary** a lot over time, but the **memory (RAM)** normally stays more or less **stable**.

It was not based on a standard like OpenAPI and JSON Schema. So it wouldn't be straightforward to integrate it with other tools, like Swagger UI. But again, it was a very innovative idea.

It has an interesting, uncommon feature: using the same framework, it's possible to create APIs and also CLIs.

* Tests that form a cluster made up of multiple versions of Elasticsearch like
full cluster restart, rolling restarts, and mixed version tests
* Tests that test the Elasticsearch clients in "interesting" places like the
`wildfly` project.
* Tests that test Elasticsearch in funny configurations like with ingest
disabled
* Tests that need to do strange things like install plugins that thrown

 *
 * @author Chris Nokleberg
 */
@NullUnmarked
@GwtIncompatible
@J2ktIncompatible
public class WrappingExecutorServiceTest extends TestCase {
  private static final String RESULT_VALUE = "ran";

  // Uninteresting delegations
  public void testDelegations() throws InterruptedException {
    MockExecutor mock = new MockExecutor();
    TestExecutor testExecutor = new TestExecutor(mock);

 *
 * @author Chris Nokleberg
 */
@NullUnmarked
@GwtIncompatible
@J2ktIncompatible
public class WrappingExecutorServiceTest extends TestCase {
  private static final String RESULT_VALUE = "ran";

  // Uninteresting delegations
  public void testDelegations() throws InterruptedException {
    MockExecutor mock = new MockExecutor();
    TestExecutor testExecutor = new TestExecutor(mock);