adding some context and comments, still exploring locally the best ap…

…proach

Signed-off-by: Atanas Atanasov <[email protected]>

.github/workflows/smoke-test.yaml

@@ -76,14 +76,20 @@ jobs:
           restore-keys: |
             ${{ runner.os }}-gradle-
 
-      - name: Build application
-        run: ${{ env.GRADLE_EXEC }} build
+#      - name: Build application
+#        run: ${{ env.GRADLE_EXEC }} build
 
-      - name: Run application in background, capture logs in app.log
-        run: |
-          ${{ env.GRADLE_EXEC }} run -x :suites:run 2> server/src/test/resources/app.log < /dev/null &
-          echo "Application started with PID $APP_PID"
-          sleep 10
+#      - name: Run application in background, capture logs in app.log
+#        run: |
+#          ${{ env.GRADLE_EXEC }} run -x :suites:run 2> server/src/test/resources/app.log < /dev/null &
+#          echo "Application started with PID $APP_PID"
+#          sleep 10
+
+# We need to here have a gradle task that will build the jar of the server but to change the
+# app.properties with the test ones before running it. This is the best approach currently, since
+# setting an env var for example: mediator.ringBufferSize=1024 will not be seen when the swirlds
+# config dependency tries to read the env with System.getenv() since the JVM looks for
+# case-sensitive keys...
 
       - name: Print App Logs
         run: cat server/src/test/resources/app.log

server/src/main/java/com/hedera/block/server/mediator/MediatorConfig.java

@@ -28,9 +28,8 @@
  *
  * @param ringBufferSize the size of the ring buffer used by the mediator
  */
-// TODO: defaultValue here should be 67108864
 @ConfigData("mediator")
-public record MediatorConfig(@ConfigProperty(defaultValue = "1024") int ringBufferSize) {
+public record MediatorConfig(@ConfigProperty(defaultValue = "67108864") int ringBufferSize) {
     private static final System.Logger LOGGER = System.getLogger(MediatorConfig.class.getName());
 
     /**

server/src/main/java/com/hedera/block/server/notifier/NotifierConfig.java

@@ -28,9 +28,8 @@
  *
  * @param ringBufferSize the size of the ring buffer used by the notifier
  */
-// TODO: defaultValue here should be 2048
 @ConfigData("notifier")
-public record NotifierConfig(@ConfigProperty(defaultValue = "1024") int ringBufferSize) {
+public record NotifierConfig(@ConfigProperty(defaultValue = "2048") int ringBufferSize) {
     private static final System.Logger LOGGER = System.getLogger(NotifierConfig.class.getName());
 
     /**

server/src/main/resources/app.properties

@@ -1,8 +1,8 @@
 prometheus.endpointPortNumber=9999
 
 # Ring buffer sizes for the mediator and notifier
-mediator.ringBufferSize=67108864
-notifier.ringBufferSize=2048
+#mediator.ringBufferSize=67108864
+#notifier.ringBufferSize=2048
 
 # Timeout for consumers to wait for block item before timing out. Default is 1500 milliseconds.
 #consumer.timeoutThresholdMillis=1500

suites/build.gradle.kts

@@ -35,6 +35,21 @@ mainModuleInfo {
     runtimeOnly("org.junit.jupiter.engine")
 }
 
+// Let's discuss: we have two repeating task names with the suites and server - 'updateDockerEnv'
+// and 'createDockerImage'. When running any of these tasks from repo root w/o any specific qualifiers
+// like ':suites:updateDockerEnv', both will run. While the overhead is only once since this gets
+// cached, it might be a good idea to change the task names so they are different, and we can be sure
+// what will be run from repo root w/o having qualifiers. For these building tasks are probably not
+// going to mess up some common files between them, it is a concern for the future, since not clearly
+// knowing what is being run could lead to silent bugs that are hard to come by. Not to mention, if
+// we have a task that will run a project, and then a task with the same name that will also run a
+// project, now when executing from root we will run two projects which might be problematic.
+// Having qualifiers is a 'need-to-know' solution which is not preferable. But there is also the case
+// that it would be a good idea to have tasks with the same name that we know for sure run isolated,
+// and we need them to run on all projects easily, so running the task from repo root will execute
+// everywhere it is present. So the question is should these remain with the same name and what
+// should be our approach for the future?
+
 val updateDockerEnv =
     tasks.register<Exec>("updateDockerEnv") {
         description =