title: KStreams application - state.dir - No .checkpoint file
body: <p>I have a KStreams application running inside a Docker container which uses a persistent key-value store. My runtime environment is Docker 1.13.1 on RHEL 7.</p>
  <p>I have configured <code>state.dir</code> with a value of <code>/tmp/kafka-streams</code> (which is the default).</p>
  <p>When I start this container using &quot;docker run&quot;, I mount <code>/tmp/kafka-streams</code> to a directory on my host machine which is, say for example, <code>/mnt/storage/kafka-streams</code>.</p>
  <p>My <code>application.id</code> is &quot;myapp&quot;. I have 288 partitions in my input topic which means my state store / changelog topic will also have that many partitions. Accordingly, when start my Docker container, I see that there a folder with the number of the partition such as 0_1, 0_2....0_288 under <code>/mnt/storage/kafka-streams/myapp/</code></p>
  <p>When I shutdown my application, I do not see any <code>.checkpoint</code> file in any of the partition directories.</p>
  <p>And when I restart my application, it starts fetching the records from the changelog topic rather than reading from local disk. I suspect this is because there is no <code>.checkpoint</code> file in any of the partition directories. (Note : I can see the <code>.lock</code> and <code>rocksdb</code> sub-directory inside the partition directories)</p>
  <p>This is what I see in the startup log. It seems to be bootstrapping the entire state store from the changelog topic i.e. performing network I/O rather than reading from what is on disk :</p>
  <pre><code>2022-05-31T12:08:02.791 [mtx-caf-f6900c0a-50ca-43a0-8a4b-95eaad9e5093-StreamThread-122] WARN  o.a.k.s.p.i.ProcessorStateManager - MSG=stream-thread [myapp-f6900c0a-50ca-43a0-8a4b-95eaa
  d9e5093-StreamThread-122] task [0_170] State store MyAppRecordStore did not find checkpoint offsets while stores are not empty, since under EOS it has the risk of getting uncommitte
  d data in stores we have to treat it as a task corruption error and wipe out the local state of task 0_170 before re-bootstrapping
  2022-05-31T12:08:02.791 [myapp-f6900c0a-50ca-43a0-8a4b-95eaad9e5093-StreamThread-122] WARN  o.a.k.s.p.internals.StreamThread - MSG=stream-thread [mtx-caf-f6900c0a-50ca-43a0-8a4b-95eaad
  9e5093-StreamThread-122] Detected the states of tasks [0_170] are corrupted. Will close the task as dirty and re-create and bootstrap from scratch.
  org.apache.kafka.streams.errors.TaskCorruptedException: Tasks [0_170] are corrupted and hence needs to be re-initialized
          at org.apache.kafka.streams.processor.internals.ProcessorStateManager.initializeStoreOffsetsFromCheckpoint(ProcessorStateManager.java:254)
          at org.apache.kafka.streams.processor.internals.StateManagerUtil.registerStateStores(StateManagerUtil.java:109)
          at org.apache.kafka.streams.processor.internals.StreamTask.initializeIfNeeded(StreamTask.java:216)
          at org.apache.kafka.streams.processor.internals.TaskManager.tryToCompleteRestoration(TaskManager.java:433)
          at org.apache.kafka.streams.processor.internals.StreamThread.initializeAndRestorePhase(StreamThread.java:849)
          at org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:731)
          at org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:583)
          at org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:556)
  </code></pre>
  <ol>
  <li><p>Should I expect to see a <code>.checkpoint</code> file in each of the partition directories under /mnt/storage/kafka-streams/myapp/ when I shutdown my application ?</p>
  </li>
  <li><p>Is this an issue because I am running my KStreams app inside a docker container ? If there were permissions issues, then I would have expected to see issues in creating the other files such as .lock or rocksdb folder (and it's contents).</p>
  </li>
  <li><p>If I run this application as a standalone/runnable Springboot JAR on my Windows laptop i.e. not in a Docker container, I can see that it creates the .checkpoint file as expected.</p>
  </li>
  </ol>