You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed, that composeUp sometimes takes 4-5 seconds, even when the containers are running from previous execution.
At other times, it is very fast, less than half a second.
On slow runs, the following is logged: "Current and cached states are different, cannot use the cached service infos.", after which some slow steps, including slow tcp checks, are done.
I realised, that the check here is a bit naive, not considering, that the arrays can have a different order.
are semantically the same, however have a order difference of "Mounts:ac8a97f7ce79f3…,7111d5ab0ca1f2…,1fd0fecccf9c54…" vs "Mounts:1fd0fecccf9c54…,ac8a97f7ce79f3…,7111d5ab0ca1f2...".
Expected behaviours:
Use cached state, when semantically nothing changes between the runs.
When order of mounts is different, still consider the cached state equal to current state.
In any case, this is a minor thing. Thanks for the great library.
Dec 13 10:30:54
Dec 13 10:30:54 > Task :composeUp
Dec 13 10:30:54 Cached services infos loaded while 'stopContainers' is set to 'false'.
Dec 13 10:30:54 +----------------------------+----------------+-----------------+
Dec 13 10:30:54 | Name | Container Port | Mapping |
Dec 13 10:30:54 +----------------------------+----------------+-----------------+
Dec 13 10:30:54 | wise_kafka_processor_kafka | 9092 | localhost:49178 |
Dec 13 10:30:54 +----------------------------+----------------+-----------------+
Dec 13 10:30:54 | mariadb-1 | 3306 | localhost:44359 |
Dec 13 10:30:54 +----------------------------+----------------+-----------------+
Dec 13 10:30:54 | postgres-1 | 5432 | localhost:62682 |
Dec 13 10:30:54 +----------------------------+----------------+-----------------+
Dec 13 10:30:54 | zookeeper-1 | 2181 | localhost:59782 |
Dec 13 10:30:54 +----------------------------+----------------+-----------------+
Dec 13 10:30:54
Dec 13 10:30:54 > Task :composeDownForcedOnFailure SKIPPED
Dec 13 10:30:54
Dec 13 10:30:54 Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
Dec 13 10:30:54
Dec 13 10:30:54 You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
Dec 13 10:30:54
Dec 13 10:30:54 For more on this, please refer to https://docs.gradle.org/8.5/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
Dec 13 10:30:54
Dec 13 10:30:54 BUILD SUCCESSFUL in 662ms
Dec 13 10:30:54 1 actionable task: 1 executed
Dec 13 10:31:55
Dec 13 10:31:55 > Task :composeUp
Dec 13 10:31:55 Current and cached states are different, cannot use the cached service infos.
Dec 13 10:31:55 Will use localhost as host of kafka
Dec 13 10:31:55 Will use localhost as host of mariadb
Dec 13 10:31:55 Will use localhost as host of postgres
Dec 13 10:31:55 Will use localhost as host of zookeeper
Dec 13 10:31:55 Probing TCP socket on localhost:49178 of 'wise_kafka_processor_kafka'
Dec 13 10:31:55 TCP socket on localhost:49178 of 'wise_kafka_processor_kafka' is ready
Dec 13 10:31:55 Probing TCP socket on localhost:44359 of 'mariadb-1'
Dec 13 10:31:55 TCP socket on localhost:44359 of 'mariadb-1' is ready
Dec 13 10:31:55 Probing TCP socket on localhost:62682 of 'postgres-1'
Dec 13 10:31:56 TCP socket on localhost:62682 of 'postgres-1' is ready
Dec 13 10:31:56 Probing TCP socket on localhost:59782 of 'zookeeper-1'
Dec 13 10:31:57 TCP socket on localhost:59782 of 'zookeeper-1' is ready
Dec 13 10:31:57 +----------------------------+----------------+-----------------+
Dec 13 10:31:57 | Name | Container Port | Mapping |
Dec 13 10:31:57 +----------------------------+----------------+-----------------+
Dec 13 10:31:57 | wise_kafka_processor_kafka | 9092 | localhost:49178 |
Dec 13 10:31:57 +----------------------------+----------------+-----------------+
Dec 13 10:31:57 | mariadb-1 | 3306 | localhost:44359 |
Dec 13 10:31:57 +----------------------------+----------------+-----------------+
Dec 13 10:31:57 | postgres-1 | 5432 | localhost:62682 |
Dec 13 10:31:57 +----------------------------+----------------+-----------------+
Dec 13 10:31:57 | zookeeper-1 | 2181 | localhost:59782 |
Dec 13 10:31:57 +----------------------------+----------------+-----------------+
Dec 13 10:31:57
Dec 13 10:31:57 > Task :composeDownForcedOnFailure SKIPPED
Dec 13 10:31:57
Dec 13 10:31:57 Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
Dec 13 10:31:57
Dec 13 10:31:57 You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
Dec 13 10:31:57
Dec 13 10:31:57 For more on this, please refer to https://docs.gradle.org/8.5/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
Dec 13 10:31:57
Dec 13 10:31:57 BUILD SUCCESSFUL in 4s
Dec 13 10:31:57 1 actionable task: 1 executed
The text was updated successfully, but these errors were encountered:
Hello, thank you very much for reporting this! 👍 Agree that the current implementation is naïve, just please refer to getStateforCache method - this is where the state is computed, and there is already some kind of normalization.
So feel free to prepare a PR that would improve this behavior 🙏
Also, please note that there is already removal of the Labels field, but it is not so important for the container. I would prefer a more sophisticates solution for the Mounts field, for example just order the array.
I noticed, that composeUp sometimes takes 4-5 seconds, even when the containers are running from previous execution.
At other times, it is very fast, less than half a second.
On slow runs, the following is logged: "Current and cached states are different, cannot use the cached service infos.", after which some slow steps, including slow tcp checks, are done.
I realised, that the check here is a bit naive, not considering, that the arrays can have a different order.
For example, first cache state:
and second cache state:
are semantically the same, however have a order difference of "Mounts:ac8a97f7ce79f3…,7111d5ab0ca1f2…,1fd0fecccf9c54…" vs "Mounts:1fd0fecccf9c54…,ac8a97f7ce79f3…,7111d5ab0ca1f2...".
Expected behaviours:
In any case, this is a minor thing. Thanks for the great library.
Appendix #1: fast run logs:
Appendix #2: slow run logs:
The text was updated successfully, but these errors were encountered: