Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Messenger] [Amqp-messenger] Support content encoding and compression#47592

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
glengemann wants to merge3 commits intosymfony:7.4
base:7.4
Choose a base branch
Loading
fromglengemann:content-encoding-support

Conversation

glengemann
Copy link

QA
Branch?6.2
Bug fix?no
New feature?yes
Deprecations?no
Tickets
LicenseMIT
Doc PRTODO

When I send a message using the AMQP transport together with theAmqpStamp and thecontent-encoding property, the message is not compressed.

TheAMQP protocol, allow through thecontent-encoding property, to “indicate what additional content encodings have been applied to theapplication-data, and thus what decoding mechanisms need to be applied in order to obtain the media-type referenced by the content-type header field”.

The values admitted according to the protocol are:gzip, compress, deflate, identity, etc.

I expect that the body of the message will be compressed and decompressed respectively by the publisher
and the subscriber.

For example, we can send a messages:

$bus->dispatch(newDummyMessage('Foo bar'), [newAmqpStamp(attributes: ['content_encoding' =>'gzip'    ]),]);

and, With the current code the body message (payload) is not compress using gzip:

$ rabbitmqadmin get queue=messages -f pretty_json [  {"exchange":"messages","message_count": 0,"payload":"{\"name\":\"Foo bar\"}","payload_bytes": 18,"payload_encoding":"string","properties": {"content_encoding":"gzip","content_type":"application/json","delivery_mode": 2,"headers": {"X-Message-Stamp-Symfony\\Component\\Messenger\\Stamp\\BusNameStamp":"[{\"busName\":\"messenger.bus.default\"}]","type":"App\\Message\\DummyMessage"      },"timestamp": 1662922329    },"redelivered": true,"routing_key":""  }]

but, if we are aware of the value of thecontent_encoding property we should compress the body message.

$ rabbitmqadmin get queue=messages -f pretty_json [  {"exchange":"messages","message_count": 0,"payload":"H4sIAAAAAAAAA6tWysxNTE8NyC8u8UxRsrI0qwUAri6HchIAAAA=","payload_bytes": 38,"payload_encoding":"base64","properties": {"content_encoding":"gzip","content_type":"application/json","delivery_mode": 2,"headers": {"X-Message-Stamp-App\\Messenger\\UniqueIdStamp":"[{\"uniqueId\":\"631e4bdc3ad3b\"}]","X-Message-Stamp-Symfony\\Component\\Messenger\\Stamp\\BusNameStamp":"[{\"busName\":\"messenger.bus.default\"}]","type":"App\\Message\\AddPonkaToImage"      },"timestamp": 1662929884    },"redelivered": true,"routing_key":""  }]

Finally, the subscriber must be able to uncompressed the body message. I made some changes in order to figure out how
this can be accomplished.

Thanks!, I should be grateful for any comments.

Postscriptum: I closed the PR47545 by mistake :).

jenkoian reacted with thumbs up emoji
@carsonbotcarsonbot added this to the6.2 milestoneSep 16, 2022
@carsonbotcarsonbot changed the title[Messenger][Amqp-messenger] Support content encoding and compression[Messenger] [Amqp-messenger] Support content encoding and compressionSep 16, 2022
@nicolas-grekas
Copy link
Member

What about allowing compression/decompression with any transports? I guess we could add a middleware to do so?
Right now, I see nothing really specific to AMQP.
About the implementation, I'd make things way simpler, no need for any interfaces IMHO. A class doing everything would look fine to me.

@glengemann
Copy link
Author

Hi Nicolas! Thanks for your comments. I have worked on a draft. You can see it in thelast commit. In the draft, I try to implement the (de)compression using a middleware. If the draft is close to what you had in mind, I think that we have a problem.

The compression expects a string in order to compress it. In the opposite direction, the decompression expects a string to decompress it. When we send a message, the string is only available after the serialization. But the serialization process is inside theTransports. TheTransports receive themessage object, serialized it and send it.

A similar problem arises when we consume the message. The stack of middlewares always has themessage object.

These are my ideas. What do you think about them?

@nicolas-grekasnicolas-grekas modified the milestones:6.2,6.3Nov 5, 2022
@nicolas-grekasnicolas-grekas modified the milestones:6.3,6.4May 23, 2023
@nicolas-grekasnicolas-grekas modified the milestones:6.4,7.1Nov 15, 2023
@xabbuhxabbuh modified the milestones:7.1,7.2May 15, 2024
@fabpotfabpot modified the milestones:7.2,7.3Nov 20, 2024
@fabpotfabpot modified the milestones:7.3,7.4May 26, 2025
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@dmitry-shylovdmitry-shylovdmitry-shylov left review comments

Assignees
No one assigned
Projects
None yet
Milestone
7.4
Development

Successfully merging this pull request may close these issues.

6 participants
@glengemann@nicolas-grekas@dmitry-shylov@fabpot@xabbuh@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp