Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-23206

Multiple versions with status 'Published' when using asynchronous publishing

    Details

    • Sprint:
      Castor Core S3, Castor Core S4

      Description

      With asynchronous publishing enabled, it is possible that creating/publishing multiple versions of the same object will result in multiple Published versions

      Steps to reproduce:
      1. Create and publish a content object (for example article).
      2. Enable asynchronous publishing content.ini, AsynchronousPublishing=enabled, clear caches if necessary.
      3. Edit and publish multiple versions of the same object.
      4. Start the publishing script in daemon mode:

        $ php bin/php/ezasynchronouspublisher.php --daemon
        

      Result: In content object's "Manage Versions" screen, multiple versions will be "Published"

        Issue Links

          Activity

          Hide
          Bertrand Dunogier added a comment - - edited

          status

          I started investigating that. I might have good news: asynchronous publishing might be fine. But the bad news is that I can reproduce it without it... see this gist: https://gist.github.com/bdunogier/b47784a14a9cc946a0c6.

          (run with ezexec.php)

          It creates one content and 10 versions, and publishes them all in //. Play with the commented code to publish using asynchronous publishing or... just ask me. Anyway, I get 10 publish versions with or without async pub.

          It sounds quite clear to me that this is a pure locking issue. Note: we have a clear UX thing here... some people want to edit multiple languages simultaneously. Maybe this is where we should offer a workaround in some way...

          what's happening

          Anyway, the issue should be quite clear:
          1. all processes start at the same time
          2. when they start their transaction, there are 10 drafts in the database, one being published
          3. archiving does nothing, since there is nothing to archive
          4. the published draft is marked as published
          5. done

          solutions

          1. Locking would work.
          2. Asynchronous publishing could ease that out by only sending 1 version of the same content at the same time. I've actually been thinking about that. Can suplement #1 by hiding the dust for the user.
          3. Think of another trick. A workflow where you can edit in a language, store the draft (v4), edit a new language on top of v4, store it (v5), and repeat ad nauseam until you hit "Send for publishing".

          Overall, it really feels like a misuse of a product where the use-case is not covered.

          I'd also be very surprised if there wasn't severe consistency issues in data... if they're not published in the right order, copyTranslations in the publishing transaction will miss translations that are being copied.

          *Overall: I don't think we can really support publishing of multiple versions at the same time. The database part needs to be sequential, at the very least*

          Show
          Bertrand Dunogier added a comment - - edited status I started investigating that. I might have good news: asynchronous publishing might be fine. But the bad news is that I can reproduce it without it... see this gist: https://gist.github.com/bdunogier/b47784a14a9cc946a0c6 . (run with ezexec.php) It creates one content and 10 versions, and publishes them all in //. Play with the commented code to publish using asynchronous publishing or... just ask me. Anyway, I get 10 publish versions with or without async pub. It sounds quite clear to me that this is a pure locking issue. Note: we have a clear UX thing here... some people want to edit multiple languages simultaneously. Maybe this is where we should offer a workaround in some way... what's happening Anyway, the issue should be quite clear: 1. all processes start at the same time 2. when they start their transaction, there are 10 drafts in the database, one being published 3. archiving does nothing, since there is nothing to archive 4. the published draft is marked as published 5. done solutions 1. Locking would work. 2. Asynchronous publishing could ease that out by only sending 1 version of the same content at the same time. I've actually been thinking about that. Can suplement #1 by hiding the dust for the user. 3. Think of another trick. A workflow where you can edit in a language, store the draft (v4), edit a new language on top of v4, store it (v5), and repeat ad nauseam until you hit "Send for publishing". Overall, it really feels like a misuse of a product where the use-case is not covered. I'd also be very surprised if there wasn't severe consistency issues in data... if they're not published in the right order, copyTranslations in the publishing transaction will miss translations that are being copied. * Overall: I don't think we can really support publishing of multiple versions at the same time. The database part needs to be sequential, at the very least *
          Hide
          Gaetano Giunta (Inactive) added a comment -

          In your description you miss the step where current published version is moved to archived. This is imho where we can/should act.

          What about: after publication transaction finishes, check if there are any other published versions, mark them archived?
          There might be a race condition in there, leading to only-archived versions, but it could work for the edit-online case 99% of time.

          Locking should be easy to achieve in async publication - this could be a good compromise, as that is the solution we recommend for the highly-concurrent-editing

          I appreciate your hint about copytranslations, as this might explain the problems with the translations sometimes not getting updated.

          As for whether this is/should be supported, I leave PM to decide. But imho we should support it. Working with a single browser tab open is so 90s...
          Plus: what about multiple translators working on the same content at the same time? we can not tell them to just phone each other when they are done...

          Last but no least: your gist is a bit simplistic, I think, compared to the real publication process. I think the "real" editing GUI already has more code which introduces some form of serialization, at least as far as a single user / browser is concerned. It might even be the php session locking, for all I know (to be explored mpre...). But I could not trigger this from a browser in standard mode, and I could in async mode.

          Show
          Gaetano Giunta (Inactive) added a comment - In your description you miss the step where current published version is moved to archived. This is imho where we can/should act. What about: after publication transaction finishes, check if there are any other published versions, mark them archived? There might be a race condition in there, leading to only-archived versions, but it could work for the edit-online case 99% of time. Locking should be easy to achieve in async publication - this could be a good compromise, as that is the solution we recommend for the highly-concurrent-editing I appreciate your hint about copytranslations, as this might explain the problems with the translations sometimes not getting updated. As for whether this is/should be supported, I leave PM to decide. But imho we should support it. Working with a single browser tab open is so 90s... Plus: what about multiple translators working on the same content at the same time? we can not tell them to just phone each other when they are done... Last but no least: your gist is a bit simplistic, I think, compared to the real publication process. I think the "real" editing GUI already has more code which introduces some form of serialization, at least as far as a single user / browser is concerned. It might even be the php session locking, for all I know (to be explored mpre...). But I could not trigger this from a browser in standard mode, and I could in async mode.
          Hide
          Gaetano Giunta (Inactive) added a comment -

          @bertrand with a bit of luck we could implement locking with current code and a different queue dispatcher. unlocking event is easy - but we need to trigger it within queue dispatcher even in case the forked process dies halfway without resetting it.
          oh, and while at it, a pre-publish queue event is nice to have as well (I use it for ezperflogger)

          Show
          Gaetano Giunta (Inactive) added a comment - @bertrand with a bit of luck we could implement locking with current code and a different queue dispatcher. unlocking event is easy - but we need to trigger it within queue dispatcher even in case the forked process dies halfway without resetting it. oh, and while at it, a pre-publish queue event is nice to have as well (I use it for ezperflogger)
          Hide
          Bertrand Dunogier added a comment -

          "affect master just fine" => "affect master as well" ?

          Yes. I get more cynical at night, like some kind of werewolf

          Show
          Bertrand Dunogier added a comment - "affect master just fine" => "affect master as well" ? Yes. I get more cynical at night, like some kind of werewolf
          Hide
          Bertrand Dunogier added a comment -
          Show
          Bertrand Dunogier added a comment - Asynchronous publishing fix: https://github.com/ezsystems/ezpublish-legacy/pull/1043 .
          Show
          Bertrand Dunogier added a comment - - edited Merged to master https://github.com/ezsystems/ezpublish-legacy/commit/d50f48197596b9920e0e3cf853691f3e83c5d268
          Hide
          Paulo Nunes (Inactive) added a comment -

          QA Approved

          tested on eZ Publish 4.7, 5.0, 5.1, 5.2, 5.3 and master

          Show
          Paulo Nunes (Inactive) added a comment - QA Approved tested on eZ Publish 4.7, 5.0, 5.1, 5.2, 5.3 and master

            People

            • Assignee:
              Unassigned
              Reporter:
              Joao Inacio (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Agile