Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-59524

Some users are unable to publish a page due to "ContentUpdatedEvent" Error when connected to the database via datasource configuration

      Note

      This issue is caused by a missing property in our previously provided configuration documents. We have updated our documentation to correct this oversight. Please review Configuring a datasource connection to ensure your configuration is up to date.

      If you would like additional details, please take a moment to review this comment.

      Issue Summary

      While Confluence is connected to the database via DataSource, we will see the following error in the atlassian-confluence.log despite the page publish successfully:

      2020-02-25 16:31:18,884 ERROR [http-nio-6731-exec-6] [atlassian.confluence.event.ConfluenceEventDispatcher] run There was an exception thrown trying to dispatch event [com.atlassian.confluence.event.events.content.page.synchrony.ContentUpdatedEvent@f2a4df3d] from the invoker [SingleParameterMethodListenerInvoker{method=public void com.atlassian.confluence.plugins.synchrony.service.SynchronyContentService.syncContentOnUpdate(com.atlassian.confluence.event.events.content.page.synchrony.ContentUpdatedEvent), listener=com.atlassian.confluence.plugins.synchrony.service.SynchronyContentService@6691a1d9} (timed)]
       -- referer: http://localhost:6731/c731/pages/resumedraft.action?draftId=327693&draftShareId=2667a813-0d56-46b0-a249-45a6ecd709b4& | url: /c731/rest/api/content/327693 | traceId: 32b4e11053495fb0 | userName: admin
      java.lang.RuntimeException: com.atlassian.sal.spi.HostConnectionAccessor returned connection with autocommit set. Listener: com.atlassian.confluence.plugins.synchrony.service.SynchronyContentService event: com.atlassian.confluence.event.events.content.page.synchrony.ContentUpdatedEvent
      	at com.atlassian.event.internal.SingleParameterMethodListenerInvoker.invoke(SingleParameterMethodListenerInvoker.java:57)
      	at com.atlassian.confluence.event.ConfluenceListenerHandlersConfiguration$TimedListenerInvoker.invoke(ConfluenceListenerHandlersConfiguration.java:96)
      	at com.atlassian.confluence.event.ConfluenceEventDispatcher$VCacheRequestContextRunnableFactory$1.lambda$run$0(ConfluenceEventDispatcher.java:93)
      	at com.atlassian.confluence.vcache.VCacheRequestContextOperations.lambda$doInRequestContext$0(VCacheRequestContextOperations.java:50)
      	at com.atlassian.confluence.impl.vcache.VCacheRequestContextManager.doInRequestContextInternal(VCacheRequestContextManager.java:84)
      	at com.atlassian.confluence.impl.vcache.VCacheRequestContextManager.doInRequestContext(VCacheRequestContextManager.java:68)
      	at com.atlassian.confluence.vcache.VCacheRequestContextOperations.doInRequestContext(VCacheRequestContextOperations.java:49)
      	at com.atlassian.confluence.event.ConfluenceEventDispatcher$VCacheRequestContextRunnableFactory$1.run(ConfluenceEventDispatcher.java:93)
      .....
      ....
      ....
      ....
      Caused by: java.lang.IllegalStateException: com.atlassian.sal.spi.HostConnectionAccessor returned connection with autocommit set
      	at com.atlassian.sal.core.rdbms.DefaultTransactionalExecutor.assertAutoCommitFalse(DefaultTransactionalExecutor.java:94)
      	at com.atlassian.sal.core.rdbms.DefaultTransactionalExecutor.executeInternal(DefaultTransactionalExecutor.java:82)
      	at com.atlassian.sal.core.rdbms.DefaultTransactionalExecutor.lambda$execute$0(DefaultTransactionalExecutor.java:43)
      	at com.atlassian.sal.spring.connection.SpringHostConnectionAccessor.lambda$execute$0(SpringHostConnectionAccessor.java:55)
      	at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140)
      	at com.atlassian.sal.spring.connection.SpringHostConnectionAccessor.execute(SpringHostConnectionAccessor.java:49)
      

      Steps to Reproduce

      1. Install Confluence and connect any supported database via datasource
      2. Create a new page
      3. Publish the page
      4. Check the atlassian-confluence.log

      Expected Results

      The page publishes successfully with no errors in the log.

      Actual Results

      The page publishes successfully but with errors in the log.

      Notes

      If 2 users are editing the same page this error is thrown when the first user publishes (or saves) the page and later when the second user tried to publish or save he will get a pop-up with the error "Can't sync with the server. Refresh the page to try to re-establish the connection.". Refreshing the page allows to proceed.

      Workaround

      Configure the following attribute to your Tomcat datasource:

      defaultAutoCommit="false"
      

      Just as an example, here's a sample datasource configuration for PostgreSQL with this attribute:

      <Resource name="jdbc/confluence" auth="Container" type="javax.sql.DataSource"
                            username="conf744dc"
                            password="conf744dc"
                            driverClassName="org.postgresql.Driver"
                            url="jdbc:postgresql://127.0.0.1:5432/conf744dc"
                            maxTotal="60"
                            maxIdle="20"
                            defaultAutoCommit="false"
                            validationQuery="select 1" />  
      

      Confluence needs to be restarted so the modifications in server.xml are captured.
      Also, if running on Data Center you must configure it on all nodes of the cluster.

      Check the Tomcat documentation for additional information on attributes to configure the Tomcat JDBC datasource.

            [CONFSERVER-59524] Some users are unable to publish a page due to "ContentUpdatedEvent" Error when connected to the database via datasource configuration

            Hi All,

            I'm going to close this ticket and wanted to take a moment to explain why.

            By default, Confluence runs with <property name="hibernate.connection.autocommit">false</property> when using the integrated database connection handler. The actual log message that is being written to the log file is a failed Java Assert expecting autocommit to be set to false. The workaround proposed by 1871051e9eec is correct and is actually the way the product should configured by default. This makes this issue primary a documentation issue.

            We also investigated and confirmed the findings provided by 1871051e9eec with regards to the installation process failing when defaultAutoCommit=false is configured in Tomcat during the database setup phase. Confluence correctly creates the tables, but then fails when validating the setup. This setup proceeds as expected when defaultAutoCommit=false is not present. So we can confirm 1871051e9eec's findings.

            To address both parts of this issue, we're updating our documentation to reflect the requirement for the defaultAutoCommit=false configuration, but to be added after the installation is complete. We'll be linking back to this issue and the associated answer as part of the documentation to make the requirement clear. I'm taking this approach in part due to the below.

            We're also looking at removing support for Datasources as a method of Confluence database access moving forward. As a number of people have expressed strong interest in this feature, I'd like to capture some feedback about their use cases so we can understand their perspective when considering this issue. If you would like to submit feedback, please check out this community post and leave your thoughts on the page.

            With this in mind, I'm going to go ahead and close the ticket.

            Thanks,
            James Ponting
            Engineering Manager - Confluence Data Center

            James Ponting added a comment - Hi All, I'm going to close this ticket and wanted to take a moment to explain why. By default, Confluence runs with <property name="hibernate.connection.autocommit">false</property> when using the integrated database connection handler. The actual log message that is being written to the log file is a failed Java Assert expecting autocommit to be set to false . The workaround proposed by 1871051e9eec is correct and is actually the way the product should configured by default. This makes this issue primary a documentation issue. We also investigated and confirmed the findings provided by 1871051e9eec with regards to the installation process failing when defaultAutoCommit=false is configured in Tomcat during the database setup phase. Confluence correctly creates the tables, but then fails when validating the setup. This setup proceeds as expected when defaultAutoCommit=false is not present. So we can confirm 1871051e9eec 's findings. To address both parts of this issue, we're updating our documentation to reflect the requirement for the defaultAutoCommit=false configuration, but to be added after the installation is complete. We'll be linking back to this issue and the associated answer as part of the documentation to make the requirement clear. I'm taking this approach in part due to the below. We're also looking at removing support for Datasources as a method of Confluence database access moving forward. As a number of people have expressed strong interest in this feature, I'd like to capture some feedback about their use cases so we can understand their perspective when considering this issue. If you would like to submit feedback, please check out this community post and leave your thoughts on the page. With this in mind, I'm going to go ahead and close the ticket. Thanks, James Ponting Engineering Manager - Confluence Data Center

            I have run Confluence with defaultAutoCommit="false" for the last year with no problems. However I have discovered that defaultAutoCommit="false" reliably breaks the Confluence setup wizard, when Confluence is set up pointing to an empty database via a datasource. The error in the browser is:

            Setup Datasource Database Failed

            The following error(s) occurred:

            • Configuring database failed
            • Schema creation complete, but tables could not be found

             

            The log file does not have much more detail:

            {{ – url: /setup/setupdatasourcedb.action | traceId: 007999f138d7c06d | userName: anonymous | referer: http://wiki.example.com/setup/setupdatasourcedb-start.action | action: setupdatasourcedb}}
            com.atlassian.config.bootstrap.BootstrapException: Schema creation complete, but tables could not be found.
            {{ at com.atlassian.config.bootstrap.DefaultAtlassianBootstrapManager.bootstrapDatasource(DefaultAtlassianBootstrapManager.java:318)}}
            {{ at com.atlassian.confluence.setup.actions.SetupDatasourceAction.setupDatabase(SetupDatasourceAction.java:83)}}
            {{ at com.atlassian.confluence.setup.actions.AbstractDatabaseCreationAction.execute(AbstractDatabaseCreationAction.java:33)}}
            {{ at com.atlassian.confluence.setup.actions.SetupDatasourceAction.execute(SetupDatasourceAction.java:63)}}
            ...

            I will keep using datasources, and temporarily unset defaultAutoCommit="false" for setups.

            Jeff Turner added a comment - I have run Confluence with defaultAutoCommit="false" for the last year with no problems. However I have discovered that defaultAutoCommit="false" reliably breaks the Confluence setup wizard, when Confluence is set up pointing to an empty database via a datasource. The error in the browser is: Setup Datasource Database Failed The following error(s) occurred: Configuring database failed Schema creation complete, but tables could not be found   The log file does not have much more detail: {{ – url: /setup/setupdatasourcedb.action | traceId: 007999f138d7c06d | userName: anonymous | referer: http://wiki.example.com/setup/setupdatasourcedb-start.action | action: setupdatasourcedb}} com.atlassian.config.bootstrap.BootstrapException: Schema creation complete, but tables could not be found. {{ at com.atlassian.config.bootstrap.DefaultAtlassianBootstrapManager.bootstrapDatasource(DefaultAtlassianBootstrapManager.java:318)}} {{ at com.atlassian.confluence.setup.actions.SetupDatasourceAction.setupDatabase(SetupDatasourceAction.java:83)}} {{ at com.atlassian.confluence.setup.actions.AbstractDatabaseCreationAction.execute(AbstractDatabaseCreationAction.java:33)}} {{ at com.atlassian.confluence.setup.actions.SetupDatasourceAction.execute(SetupDatasourceAction.java:63)}} ... I will keep using datasources, and temporarily unset defaultAutoCommit="false" for setups.

            I don't see the issue when using the defaultAutoCommit="false" setting pointed out by Michael Ammann. Seems to solve the problem for us.

            Atlassian, could you please comment on the workaround & if this solves the issue, update the documentation?

            JP

            Jan-Peter Rusch added a comment - I don't see the issue when using the defaultAutoCommit="false" setting pointed out by Michael Ammann. Seems to solve the problem for us. Atlassian, could you please comment on the workaround & if this solves the issue, update the documentation? JP

            Bernd Lindner added a comment - - edited

            Affects also Confluence 7.4.0 (Enterprise Release).

            Bernd Lindner added a comment - - edited Affects also Confluence 7.4.0 ( Enterprise Release ).

            Michael Ammann added a comment - - edited

            To solve these issue, you can set the defaultAutoCommit="false" in the Tomcat datasource configuration. This solved the problem for me.

            It seems to be the same problem than https://confluence.atlassian.com/bamkb/database-updates-fail-with-can-t-call-commit-when-autocommit-true-234652552.html

            Michael Ammann added a comment - - edited To solve these issue, you can set the defaultAutoCommit="false" in the Tomcat datasource configuration. This solved the problem for me. It seems to be the same problem than  https://confluence.atlassian.com/bamkb/database-updates-fail-with-can-t-call-commit-when-autocommit-true-234652552.html

            Our work extends some functionality of comala documentation plugin and it behave "weirdly" (I believe some requests were thrown away etc).

            Ofc you're right fixing is preferable, but at current state I would heavily recommend not to use JNDI.

            Seems like 7.2.0 broke Synchrony on many levels (we were fighting another synchrony bug in the process too).

            Michal Vrany added a comment - Our work extends some functionality of comala documentation plugin and it behave "weirdly" (I believe some requests were thrown away etc). Ofc you're right fixing is preferable, but at current state I would heavily recommend not to use JNDI. Seems like 7.2.0 broke Synchrony on many levels (we were fighting another synchrony bug in the process too).

            Apart from the enormous log, what issues did you discover concerning Synchrony? To me it seems that Atlassian should fix that issue ASAP & support JNDI connections.

            Jan-Peter Rusch added a comment - Apart from the enormous log, what issues did you discover concerning Synchrony? To me it seems that Atlassian should fix that issue ASAP & support JNDI connections.

            We've run into the same issue while developing addon for our customer. Workaround (switch to hibernate configuration in confluence.cfg.xml worked for us).

            To me seems like JNDI support should be removed from documentation because it completely breaks Synchrony (Collaborative editing).

            Michal Vrany added a comment - We've run into the same issue while developing addon for our customer. Workaround (switch to hibernate configuration in confluence.cfg.xml worked for us). To me seems like JNDI support should be removed from documentation because it completely breaks Synchrony (Collaborative editing).

            +1 on @jeff11

            JNDI based datasources separate application configuration from db connections & allow for a pooled & more detailed configuration using the application server (Tomcat) environment. We're using this for several years w/o any problem.  It's documented as an option. So either don't support JNDI connections anymore (Hint: remove documentation & some release notes that it's not supported) OR fix this bug. It's that easy.

            Jan-Peter Rusch added a comment - +1 on @jeff11 JNDI based datasources separate application configuration from db connections & allow for a pooled & more detailed configuration using the application server (Tomcat) environment. We're using this for several years w/o any problem.  It's documented as an option. So either don't support JNDI connections anymore (Hint: remove documentation & some release notes that it's not supported) OR fix this bug. It's that easy.

            JNDI Datasources don't get much love from Atlassian. This is sad, because configuring the database connection in the appserver (Tomcat), rather than the application is just better in every way, operationally:

            • Data is portable between prod and staging. I can rsync my Confluence home directory from prod to staging, and I don't need to hack confluence.cfg.xml to update the database details, because the staging Tomcat is configured to connect to the staging database.
            • I don't have database credentials leaking into my application backups.
            • JavaMelody (JRASERVER-67553) or JMX-based monitoring tools can introspect the Datasource to monitor database connections.

            Jeff Turner added a comment - JNDI Datasources don't get much love from Atlassian. This is sad, because configuring the database connection in the appserver (Tomcat), rather than the application is just better in every way, operationally: Data is portable between prod and staging. I can rsync my Confluence home directory from prod to staging, and I don't need to hack confluence.cfg.xml to update the database details, because the staging Tomcat is configured to connect to the staging database. I don't have database credentials leaking into my application backups. JavaMelody ( JRASERVER-67553 ) or JMX-based monitoring tools can introspect the Datasource to monitor database connections.

              jponting James Ponting
              jwaihou Jonathan Soo
              Affected customers:
              45 This affects my team
              Watchers:
              67 Start watching this issue

                Created:
                Updated:
                Resolved: