Update 1 - Cask - a Scala HTTP micro-framework.md

docs/pages/1 - Cask - a Scala HTTP micro-framework.md

@@ -130,27 +130,6 @@ $$$minimalApplication2
 You can split up your routes into separate `cask.Routes` objects as makes sense
 and pass them all into `cask.Main`.
 
-$$minimalApplicationWithLoom
-
-Cask can support using Virtual Threads to handle the request out of the box, you can enable it with the next steps:
-
-1. Running cask with Java 21 or later
-2. add `--add-opens java.base/java.lang=ALL-UNNAMED` to your JVM options, which is needed to name the virtual threads.
-3. add `-Dcask.virtual-thread.enabled=true` to your JVM options, which is needed to enable the virtual threads.
-4. tweak the underlying carrier threads with `-Djdk.virtualThreadScheduler.parallelism`, `jdk.virtualThreadScheduler.maxPoolSize` and `jdk.unparker.maxPoolSize`.
-
-**Advanced Features**:
-1. You can change the default scheduler of the carrier threads with `cask.internal.Util.createVirtualThreadExecutor` method, but keep in mind, that's not officially supported by JDK for now.
-2. You can supply your own `Executor` by override the `handlerExecutor()` method in your `cask.Main` object, which will be called only once when the server starts.
-3. You can use `jdk.internal.misc.Blocker`'s `begin` and `end` methods to help the `ForkJoinPool` when needed.
-
-**NOTE**: 
-1. If your code is CPU-bound, you should not use virtual threads, because it will not improve the performance, but will increase the overhead.
-2. OOM is a common issue when you have many virtual threads, you should limit the max in-flight requests to avoid it.
-3. There are some known issues which can leads to a deadlock, you should be careful when using it in production, at least after long time stress test.
-3. [JEP 491: Synchronize Virtual Threads without Pinning](https://openjdk.org/jeps/491) will be shipped in Java 24.
-4. Some info from early adaptor [faire](https://craft.faire.com/java-virtual-threads-increasing-search-performance-while-avoiding-deadlocks-f12fa296d521)
-
 ## Variable Routes
 
 $$$variableRoutes
@@ -480,3 +459,28 @@ can build upon to create your own Cask web application architected however you
 would like.
 
 $$$todo
+
+## Running Cask with Virtual Threads
+
+
+$$minimalApplicationWithLoom
+
+Cask can support using Virtual Threads to handle the request out of the box, you can enable it with the next steps:
+
+1. Running cask with Java 21 or later
+2. add `--add-opens java.base/java.lang=ALL-UNNAMED` to your JVM options, which is needed to name the virtual threads.
+3. add `-Dcask.virtual-thread.enabled=true` to your JVM options, which is needed to enable the virtual threads.
+4. tweak the underlying carrier threads with `-Djdk.virtualThreadScheduler.parallelism`, `jdk.virtualThreadScheduler.maxPoolSize` and `jdk.unparker.maxPoolSize`.
+
+**Advanced Features**:
+1. You can change the default scheduler of the carrier threads with `cask.internal.Util.createVirtualThreadExecutor` method, but keep in mind, that's not officially supported by JDK for now.
+2. You can supply your own `Executor` by override the `handlerExecutor()` method in your `cask.Main` object, which will be called only once when the server starts.
+3. You can use `jdk.internal.misc.Blocker`'s `begin` and `end` methods to help the `ForkJoinPool` when needed.
+
+**NOTE**: 
+1. If your code is CPU-bound, you should not use virtual threads, because it will not improve the performance, but will increase the overhead.
+2. OOM is a common issue when you have many virtual threads, you should limit the max in-flight requests to avoid it.
+3. There are some known issues which can leads to a deadlock, you should be careful when using it in production, at least after long time stress test.
+3. [JEP 491: Synchronize Virtual Threads without Pinning](https://openjdk.org/jeps/491) will be shipped in Java 24.
+4. Some info from early adaptor [faire](https://craft.faire.com/java-virtual-threads-increasing-search-performance-while-avoiding-deadlocks-f12fa296d521)
+