Problem/Motivation

Given external tools may have issues with php serialization, unless they are running php there may be times where JSON is a better choice for all messages (such as when a queue is only used to inject messages, or only read messages from an external source)

As such it would be useful if we could choose the serialization based on the queue name.

Steps to reproduce

N/A

Proposed resolution

Add method for configuring different serialization methods for each queue.

Remaining tasks

User interface changes

None

API changes

TBD

Data model changes

TBD

Issue fork rabbitmq-3416009

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

cmlara created an issue. See original summary.

cmlara’s picture

Status: Active » Needs review

This adds 2 serializers based on core's existing. Both throw an on-api Exception when a failure occurs (serialize() indicates it can never fail and does not have an exception). This is mandatory to properly implement #3416008: Make conversion from json to php serialization easier when upgrading to 4.x and simultaneously fixes a silent bug (that even core has) where serialization failures may be silently hidden. The JSON serializer matches our historical use of json_encode() as compared to Core which uses more escaping for web transfer.

We can remove our own PHP serializer after #3421234: Json and PHP serializers should throw exception on failure. We may want to keep our own JSON serializer due to difference in quoting options.

With this new structure any type of serializer can be implemented to meet the data transfer needs. In theory the core YAML serializer is already compatible and would just need to be tagged with rabbitmq_serializer to be utilized.

I have not implemented this for the Queue workers as they have their own method of defining the serializer.

This will need a 3.x backport.

This does not provide a method to change the serializer globally. I believe we can consider that acceptable given the reason we implemented PHP in 4.x was to avoid an API breach. It would seem reasonable to require an admin to configure each queue that has been verified as acceptable to use non-php serialization.

  • zach.bimson committed a922653b on 4.x authored by cmlara
    Issue #3416009 by cmlara: Allow serialization mode to be configured per...
zach.bimson’s picture

Status: Needs review » Fixed

  • zach.bimson committed a922653b on 5.x authored by cmlara
    Issue #3416009 by cmlara: Allow serialization mode to be configured per...

  • zach.bimson committed a922653b on refactor-dynamic-services authored by cmlara
    Issue #3416009 by cmlara: Allow serialization mode to be configured per...
cmlara’s picture

Status: Fixed » Patch (to be ported)

I still need to look at backporting this to 3.x to allow a smoother path to 4.x.