The latest Confluence 6.9 EAP milestone is available now! EAP releases provide a snapshot of our work-in-progress and give you an opportunity to test and fix your add-ons before the final release.
In this release we’re finalising work on our brand new read-only feature, to help admins when performing routine maintenance. This feature may have an impact on your add-ons, so please head to How to make your add-on compatible with read-only mode in our developer documentation to find out what you need to do to make sure your add-on is compatible.
As usual, we’ll be releasing weekly milestones and betas during the development of Confluence 6.9, so head to Preparing for Confluence 6.9 to find out what’s changed.
If you have any problems with an EAP release, please raise an issue to let us know. The earlier we know about problems, the more time we’ll have to fix them before the final release.
Quick question - when an instance is in readonly mode - will schedulers and such be paused? If we have maintenance tasks that occur in the background (db clean up etc) - what’s the expected behaviour? Is there an event when the site goes into to and when it comes back out? (Because that would let us pause things and then trigger them when it becomes write capable again).
Would it be possible for you guys to also provide some guidelines on how you want apps to behave in general?
When a Confluence instance is in read-only mode - should the apps treat any persistent storage as read-only as well? Will there be any issues with us updating the database when it’s in r/o ?
For my Macro based apps - it’s pretty easy, but for an app like Announcer for Confluence (Atlassian Marketplace ) that doesn’t really interact with the content (but it does have active objects) - it gets harder for me to decide on the behavior for my app (not trying to get you guys to solve that for me but anything you can guide me behavior wise would be good).
Thanks @rrobins. We have a similar question to @daniel where we could benefit from some tips/guidelines. The intent of this mode, as I understand it, is to reduce the impact and cost of maintenance and upgrades by temporarily ensuring all (important) state is immutable, i.e. the db, filesystem so that no “important” data is lost.
Our app, Analytics for Confluence, uses Active Objects to log activity, such as page views. When in read-only mode, Confluence pages can still obviously be viewed, and it would be ideal for the customer to still capture view activity during that period.
The easy “tick the box” solution is to prevent config changes and also stop capturing any page view activity whilst in read-only mode. However, we’re weighing up if it’s better for the customer to continue capturing page view activity anyway:
In the worst case, this extra data is lost, which is no worse than not capturing any data at all
(e.g. if the admin restores a DB backup on a new server)
However in the best case, the customer wins by retaining page view activity over that period
(e.g. the admin is doing some general database maintenance, or moving a home directory somewhere new)
@rrobins: do you think that’s an appropriate way to handle read-only mode in an app? Any tips, or advice?
Hi Daniel, Tim pretty much nailed the answer to both your questions.
We see the approach as follows:
After the read-only maintenance, if any changes made to config and database/filesystem are lost, then what is the impact. In the case of page view analytics the result would be insignificant. Even for the config, we don’t block this as we feel that admins are owning the responsibility of read-only mode and may have a good case for changing the config whilst it is on.
If the same DB and filesystem are used post read-only mode then you get the benefit of having captured the analytics during read-only operation.
The same goes for scheduler jobs. Think about the impact of keeping or loosing that same database. If it was a nightly clean-up l, then likely it is irrelevant if you prevent the job or not, as the job will run the next day on the same or ‘new’ database with a similar nett result.
On the other hand, if the user changed a critical workflow, edited some content, changed a file, and those changes were lost post read-only mode then they would be both confused and annoyed.
Since I’m very much sensitive of these customer’s needs - would it be possible for us to provide a url in the flag as to what we(the vendor) have defined the expected behavior to be? That way it could be shown in the maintenance mode page where you currently show the compatibility mode. I dropped it in as a suggestion using your handy link at the original post.
Quick question - when an instance is in readonly mode - will schedulers and such be paused? If we have maintenance tasks that occur in the background (db clean up etc) - what’s the expected behaviour? Is there an event when the site goes into to and when it comes back out? (Because that would let us pause things and then trigger them when it becomes write capable again).
Currently, we are not going to pause the scheduler or any scheduled jobs. We do fire a ClusterAccessModeEvent when the administrator turns the read-only mode on and off. You can update your code to listen to this event and act on its value accordingly.
Our app, Analytics for Confluence, uses Active Objects to log activity, such as page views. When in read-only mode, Confluence pages can still obviously be viewed, and it would be ideal for the customer to still capture view activity during that period.
…
do you think that’s an appropriate way to handle read-only mode in an app? Any tips, or advice?
Assume that you are using a REST endpoint with PUT/POST method to record the analytics event, you will be able to whitelist that REST endpoint (via a Java annotation described in the EAP - however, there’s a bug that prevents you from using it right now, we are fixing that issue and the annotation will be ready in the next milestone). Moreover, we don’t block any DB operations. Your analytics data will still be stored in the Active Objects table without any problems.
Is there any pointers on how we can white list an endpoint using this new annotation while still actually building and supporting earlier Confluence versions with the same jar file?
Hi @daniel, this is not likely something we will implement any time soon. It might be worth adding some details in your docs. From our research customer are not overly concerned with the database being written to during read-only mode so long as the user content is not compromised. We are expecting that there should not be a need to explain in any great detail exactly what does and does not occur during read-only mode, on the basis that admins are aware that the database WILL still be written to.
is there anything we should consider wrt. to long running (read-only) and computational expensive tasks?
In our apps we have quite a few of those and I wonder if the intention of the read-only mode is also to somewhat limit the performance impact of user actions during that time so more resources are available for the maintenance tasks.
For example:
Don’t allow full-space content exports because the admin wants to do a database backup and the export is hitting the database at the same time, increasing the overall time required for the database backup, and thereby the time users cannot edit pages.
Should we also prevent such tasks during read-only mode?
Hi Jens,
In our implementation we are not preveventing any page/content exports. Thus would not recommend limiting such read only functions at this time
Btw. I’ve seen that you introduced some new annotations for REST interfaces and block certain HTTP methods when read-only mode is enabled.
Do you provide these annotations in an embeddable separate library for compatibility with older Confluence versions? We’d really like to avoid releasing separate artefacts for older Confluence versions and these annotations are currently the only thing we cannot work around.
We have a REST API that POSTs some user-specific state which does not need to be persisted in the database and we would like to exempt this API from read-only mode. However the exemption annotation will be available only when we compile against 6.9.
If there was such a compatibility library we could bundle it in our app code and your REST filter could still check for the presence of the annotation.
How do others handle this?
@tim does that affect your page view pings as well?
We haven’t attempted the changes yet. We don’t use a REST endpoint for page view pings, however we do for other aspects of our product e.g. changing global permissions to the analytics data.
We will most likely let the admin still change permissions but have a warning present on the page that reminds them they’re in read-only mode and the changes may not necessarily carry across (e.g. if they’re migrating the database via a prior snapshot to a new server), but if doing this would require us to have 2 separate builds we’ll compromise and lock down changing those settings in read-only mode.
Do you provide these annotations in an embeddable separate library for compatibility with older Confluence versions? We’d really like to avoid releasing separate artefacts for older Confluence versions and these annotations are currently the only thing we cannot work around.
Hi @jens,
Thank you for the suggestion. We will provide a compatibility annotation library so that the same artifact will work on older Confluence versions and 6.9.
Related to @jens question, will it be possible to run an older version of confluence in development (via atlas-debug) with code related to readonly mode in my add-on? Right now it fails to compile because certain classes are obviously not there:
[ERROR] .../ReadWriteAccessModeCondition.java:[5,55] package com.atlassian.confluence.api.service.accessmode does not exist
[ERROR] .../ReadWriteAccessModeCondition.java:[6,53] package com.atlassian.confluence.api.model.accessmode does not exist
Hi @dmitry,
Are you using any other conditions for your web items? If you are using some built-in conditions such as PagePermissionCondition with the proper parameter as documented on the developer documentation page, you won’t need the new ReadWriteAccessModeCondition.
We will also provide an equivalent Condition class in the compatibility library so that you can use it instead of the built-in conditions.
