pavelfomin

Ran into an issue with flyway script executing an alter table statement while Postgres auto-vacuum for the same table was in progress. As tables grow, Postgres runs the auto-vacuum for tables periodically. The flyway script was stuck waiting for the table lock to be released. To avoid this issue, one can disable the auto-vacuum before the flyway migration and re-enable it after migration is finished using beforeMigrate.sql and afterMigrate.sql.

pavelfomin

Occasionally it can be helpful to parameterize a migration depending on an environment. Flyway supports the concept of placeholders to help with that.

Flyway provides default placeholders, whose values are automatically populated:

• ${flyway:defaultSchema} = The default schema for Flyway
• ${flyway:user} = The user Flyway will use to connect to the database
• ${flyway:database} = The name of the database from the connection url
• ${flyway:timestamp} = The time that Flyway parsed the script, formatted as 'yyyy-MM-dd HH:mm:ss'

pavelfomin

For some reason, DataSourceHealthIndicator does not support custom query configuration via a property. DataSourceHealthContributorAutoConfiguration uses poolMetadata.getValidationQuery() to pass the validation query to DataSourceHealthIndicator.

Using spring.datasource.hikari.connection-test-query will customize the Hikari datasource test query and db health check will also it. However, it will also affect the performance of the Hikari connection pool which is not ideal.

Another way of configuring a custom query for DataSourceHealthIndicator is to create this as a @Bean manually and pass a custom query to its constructor. Using the same @Bean name dbHealthIndicator disables the [autoconfiguration of the default DataSourceHealthIndicator](https://github.com/spr

pavelfomin

Troubleshooting application crash looping in GCP

• disable auto scaling and set number of replicas manually

• view events in GCP to get a better idea of why application is getting killed and restarted

• note how long it takes for app to start successfully in your current environment

  • adjust number of tries for liveness and readiness probes to accommodate slower start ups
  • enable debug logging by org.springframework.boot.availability.ApplicationAvailabilityBean

• use GCP metrics to monitor application CPU and RAM usage

pavelfomin

There is some confusion online about whether health indicators contribute to the liveness / readiness probe status. Research below confirms that liveness / readiness probe status does not depend on the health indicators as long as these conditions (causing the health indicators failure) do not prevent application from starting.

https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot

You should carefully consider tying external state to Liveness or Readiness and this is why Spring Boot is not adding any by default. Each application and deployment is different, but we’re committed to providing guidance and adapt defaults with the help of the community - check out the "Checking external state with Kubernetes Probes" section in our reference documentation.

Looking in the code, the usages of LivenessState.CORRECT are listed below:

• EventPublishingRunListener.started(ConfigurableApplicationContext, Duration) (org.springframework.boot.context.event)
• SpringApplicationRu

pavelfomin

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.springframework.stereotype.Component;

@Aspect
@Component
@Slf4j

pavelfomin

Issues with GH Gradle Dependabot

• Dependabot does not honor Gradle's resolutionStrategy. Here is the issue for dependabot not working with gradle's resolutionStrategy. A typical usage of Gradle's resolutionStrategy is for upgrading vulnerable dependencies that are transitive to the application.
• Dependabot does not show which vulnerabilities have been resolved by the PR before PR is merged to main branch
• Dependabot uses public runners and cannot access private artifact repositories (possible workaround using private runners)
• Gradle plugin org.owasp.dependencycheck takes into account proper versions from resolutionStrategy and also lists at least one other vulnerability that is not listed by Dependabot.

pavelfomin

With groovyx.net.http.HTTPBuilder outdated and not ported to latest Groovy version, here is the simple code to do a REST call

        String json = new URL(url).getText(
            requestProperties: ['Authorization': 'Bearer ' + token]
        )

        JsonSlurper jsonSlurper = new JsonSlurper()
        Map content = jsonSlurper.parseText(json)

Better yet, newer java.net.http.HttpClient that comes w/ JRE can now be used:

pavelfomin

Useful resources

• https://jqlang.github.io/jq/manual/
• https://jqplay.org/
• https://www.digitalocean.com/community/tutorials/how-to-transform-json-data-with-jq
• https://unix.stackexchange.com/questions/722684/jq-nested-reduce-grouping-of-json-data
• https://programminghistorian.org/en/lessons/json-and-jq

pavelfomin

    def "fetch file info"() {

        given:
        UUID fileId = UUID.randomUUID()
        FileMetadata response = new FileMetadata(fileId, "/somePath", "someFileName.xls", 100)

        wireMockServer.stubFor(
            get(urlPathTemplate(uri))
                .withPathParam("fileId", equalTo(fileId.toString()))
                .withHeader(AUTHORIZATION_HEADER, expectedAuthorization)