Uploaded image for project: 'Kogito'
  1. Kogito
  2. KOGITO-5775

PSQL table doesn't exist upon deployment in Helm

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 1.15.0.Final
    • None
    • Image
    • None
    • False
    • False
    • undefined
    • Workaround Exists
    • Hide

      Delete the pod such that it gets recreated while the PSQL instance is already up and running. Then, the table exists and the POST request succeeds.

      Show
      Delete the pod such that it gets recreated while the PSQL instance is already up and running. Then, the table exists and the POST request succeeds.
    • Hide

      When deploying the PSQL Helm chart, the Kogito application will initially fail to connect the PSQL instance since they are deployed at the same time. Eventually, it connects, but when submitting a POST request to the process-postgresql-persistence-quarkus example, you get the following error:

      ➜ curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{"name" : "my fancy deal", "traveller" : { "firstName" : "John", "lastName" : "Doe", "email" : "jon.doe@example.com", "nationality" : "American","address" : { "street" : "main street", "city" : "Boston", "zipCode" : "10005", "country" : "US" }}}' (kubectl get routes --namespace kmok -o jsonpath="{.items[?(@.metadata.name=='psql-helm-kogito-postgresql')].spec.host}")/deals
{"details":"java.lang.RuntimeException: Error inserting process instance b06a761d-5b0e-4334-adda-57a790daf844Error id baaf7012-5653-4b3c-bb6f-e43e767dedf0-2","stack":""}
      Show
      When deploying the PSQL Helm chart, the Kogito application will initially fail to connect the PSQL instance since they are deployed at the same time. Eventually, it connects, but when submitting a POST request to the process-postgresql-persistence-quarkus example , you get the following error: ➜ curl -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{ "name" : "my fancy deal" , "traveller" : { "firstName" : "John" , "lastName" : "Doe" , "email" : "jon.doe@example.com" , "nationality" : "American" , "address" : { "street" : "main street" , "city" : "Boston" , "zipCode" : "10005" , "country" : "US" }}}' (kubectl get routes --namespace kmok -o jsonpath= "{.items[?(@.metadata.name== 'psql-helm-kogito-postgresql' )].spec.host}" )/deals { "details" : "java.lang.RuntimeException: Error inserting process instance b06a761d-5b0e-4334-adda-57a790daf844Error id baaf7012-5653-4b3c-bb6f-e43e767dedf0-2" , "stack" :""}

    Description

      Taking a look at the pod logs reveals this is caused by the process_instances table not existing:

      Caused by: org.postgresql.util.PSQLException: ERROR: relation "process_instances" does not exist
  Position: 13
	at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2552)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2284)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:322)
	at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:481)
	at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:401)
	at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:164)
	at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:130)
	at io.agroal.pool.wrapper.PreparedStatementWrapper.executeUpdate(PreparedStatementWrapper.java:88)
	at org.kie.kogito.persistence.jdbc.JDBCProcessInstances.insertInternal(JDBCProcessInstances.java:159)
	... 71 more

      I believe this is because the table is created by the application at the start of its code but fails to create it when the PSQL instance isn't ready yet. Once it is able to connect, the table is no longer attempted to be created again. As such, a solution would be to initialize this table in the init.sql script for the PSQL chart.

      Attachments

        Issue Links

          relates to

          Feature Request - Feature requests from customers and/or users KOGITO-5768 Support PostgreSQL persistence in Helm

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              amgao@redhat.com Amy Gao (Inactive)
              kevin-mok Kevin Mok (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: