provide feedback on AMQP_MANDATORY, AMQP_IMMEDIATE about php-amqp HOT 7 CLOSED

I was digging around this question and found few things.

• As of v3.0.0 Rabbitmq drop support of IMMEDIATE flag (look for 23896) for techincal reason in a favor of message TTL and [Dead Letters Exchange](http://www.rabbitmq.com/dlx.html] which may be used instead.
• Messages published with AMQP_MANDATORY flag are returned with basic.return client-only method, which is not held in read_message_from_channel function, which is on the one hand is trivial to fix, but on the other, due to synchronous PHP architecture is a bit epic to handle. On successful routing we don't receive any methods from server. While basic.publish (and basic.return method too) are asynchronous, everything what happens after data sent to server will be the subject of race conditions and it looks like using Alternate Exchange to handle unroutable messages.

I tried to use select() on socket right after publish to check whether we have any data from server to read it and prevent main thread to be blocked by recv() but i have no idea about how it will work on server under average or heavy load. Personally I, prefer to don't trust such way of processing AMQP_MANDATORY flag.

We have to discuss more about this issue, while declared support of AMQP_MANDATORY and AMQP_IMMEDIATE flags and AMQPExchange::publish() documentation is really confusing for newcomers and those who will never look under the hood of php-amqp extension.

UPD: i would prefer to document that in detail how to handle such kind of messages and maybe set TTL = 0 silently for messages that send with AMQP_IMMEDIATE.

Special thanks to bob2351 from freenode IRC #rabbitmq channel for his help.

from php-amqp.

I totally agree that we should improve the documentation about MANDATORY and IMMEDIATE.

I'm not a fan of silently modifying the TTL of a message. A middleware should not alter the message in any way, imho.
(Remember the message may already carry a TTL). Also this feels like too much hidden magic for my taste.
But it would make a good addition to the docs ;-)

Really supporting MANDATORY would require support in librabbitmq-c and another callback for the consume call. I would stay away from adding our own low level socket handling, the risk of interfering with the protocol state inside librabbitmq is just too high.

OTOH, going with an additional optional callback should be doable and would certainly add value.
Worth the effort?

from php-amqp.

Actually message with TTL header and IMMEDIATE flag are conflicting a bit, so silently rewrite it should not change desired behavior.

rabbitmq-c library already has support of MANDATORY messages. Actually, it is only message type and structure related to this method. Yesterday I tried that and it works as expected, the only problem that it is asynchronous method. Handling with callback is nice, as I see, we have to interrupt execution of main thread and run that callback (if any). Bring async features to the sync PHP nature is a trick.

The socket level is only define do we have any pending data or not and if we have then run reading method from librabbitmq. But as I said, due to asynchronous nature of basic.publish and basic.return is risky to be sure that returned message is exactly the same we sent.

Maybe another callback for consume is not a bad idea, but personally I use produce in one script and consume in another, so when I want to be sure that message delivered i have to run consume method right after produce and block main thread which is highly undesirable because I use rabbitmq here to move long-playing actions into separate thread. In this situation Alternate Exchange works like a charm.

Also, produce is related more to exchanges when consume is close to queues.

Adding callbacks per exchange which called when appropriate method received is kinda solution, but also requires async reading. I'm stuck at this point a bit. On the one hand it is not very difficult to implement, on the other hand we will deal with multithreading in php and all other stuff related to it like resources management and so (I'm not good at threads in php and threadsafe php internals, so it will take some time). But if we have only one publish per script then we may not catch the returned message 😕

from php-amqp.

Am 22.01.2013 18:57 schrieb "Ben Pinepain" [email protected]:

Actually message with TTL header and IMMEDIATE flag are conflicting a
bit, so silently rewrite it should not change desired behavior.

Ahh, cool. In that case I retract my objection. Thanks for clearing that up.

rabbitmq-c library already has support of MANDATORY messages. Actually,
it is only message type and structure related to this method. Yesterday I
tried that and it works as expected, the only problem that it is
asynchronous method. Handling with callback is nice, as I see, we have to
interrupt execution of main thread and run that callback (if any). Bring
async features to the sync PHP nature is a trick.

Maybe another callback for consumer is not a bad idea, but personally I
use produce in one script and consume in another

Geez, where did I have my head? You're completely right, I was confusing
publish and consume.

I shall not comment on this any further for today, it seems I only come up
with rubbish. Tomorrow is a another day;-)

from php-amqp.

It's ok, the stuff is not trivial, I spent few weeks in researches to get to some conclusions how to done with this issue.

So at this moment I have solution for AMQP_IMMEDIATE flag support via TTL=0 header field, which is all according to RabbitMQ docs (it's another disambiguation, extension named amqp but in fact support rabbitmq peppered version of AMQP standard, but it's ok).

For basic.return I'm confused and have no idea how we can done some solution which will not smell, do some magic or involve potentially unreliable logic. But we have invent such, while some part of issue #24 depends on it.

p.s. todo: suport reason and other specific fields for dead-lettered messages in envelope class or even create custom class (inherit from some basic?)

upd: basic.return should works w/o problems for RPC calls

from php-amqp.

If a user is performing a deprecated action, we can rewrite the TTL, but we
should throw the appropriate E_NOTICE.

On Tuesday, January 22, 2013, Ben Pinepain wrote:

Actually message with TTL header and IMMEDIATE flag are conflicting a bit,
so silently rewrite it should not change desired behavior.

rabbitmq-c https://github.com/alanxz/rabbitmq-c library already has
support of MANDATORY messages. Actually, it is only message type and
structure related to this method. Yesterday I tried that and it works as
expected, the only problem that it is asynchronous method. Handling with
callback is nice, as I see, we have to interrupt execution of main thread
and run that callback (if any). Bring async features to the sync PHP nature
is a trick.

The socket level is only define do we have any pending data or not and if
we have then run reading method from librabbitmq. But as I said, due to
asynchronous nature of basic.publish and basic.return is risky to be sure
that returned message is exactly the same we sent.

Maybe another callback for consumer is not a bad idea, but personally I
use produce in one script and consume in another, so when I want to be
sure that message delivered i have to run consume method right after
produce and block main thread which is highly undesirable because I use
rabbitmq here to move long-playing actions into separate thread. In this
situation Alternate Exchange http://www.rabbitmq.com/ae.html works like
a charm.

Also consume method related more to queue and return to exchanges, so
mixing them are maybe not a good idea.

Adding callbacks per exchange which called when appropriate method
received is kinda solution, but also requires async reading. I'm stuck at
this point a bit. On the one hand it is not very difficult to implement, on
the other hand we will deal with multithreading in php and all other stuff
related to it like resources management and so (I'm not good at threads in
php and threadsafe php internals, so it will take some time). But if we
have only one publish per script then we may not catch the returned
message [image: 😕]

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-12556312.

from php-amqp.

Very old issue. Closing.

from php-amqp.