|
2733 | 2733 | </doc>
|
2734 | 2734 | <chassis name = "client" implement = "MUST" />
|
2735 | 2735 | </method>
|
| 2736 | + |
| 2737 | + <method name = "nack" index = "120" label = "reject one or more incoming messages"> |
| 2738 | + <doc> |
| 2739 | + This method allows a client to reject one or more incoming messages. It can be |
| 2740 | + used to interrupt and cancel large incoming messages, or return untreatable |
| 2741 | + messages to their original queue. |
| 2742 | + </doc> |
| 2743 | + |
| 2744 | + <rule name = "01"> |
| 2745 | + <doc> |
| 2746 | + The server SHOULD be capable of accepting and processing the Nack method while |
| 2747 | + sending message content with a Deliver or Get-Ok method. I.e. the server should |
| 2748 | + read and process incoming methods while sending output frames. To cancel a |
| 2749 | + partially-send content, the server sends a content body frame of size 1 (i.e. |
| 2750 | + with no data except the frame-end octet). |
| 2751 | + </doc> |
| 2752 | + </rule> |
| 2753 | + |
| 2754 | + <rule name = "02"> |
| 2755 | + <doc> |
| 2756 | + The server SHOULD interpret this method as meaning that the client is unable to |
| 2757 | + process the message at this time. |
| 2758 | + </doc> |
| 2759 | + <doc type = "scenario"> |
| 2760 | + TODO. |
| 2761 | + </doc> |
| 2762 | + </rule> |
| 2763 | + |
| 2764 | + <rule name = "03"> |
| 2765 | + <doc> |
| 2766 | + The client MUST NOT use this method as a means of selecting messages to process. |
| 2767 | + </doc> |
| 2768 | + <doc type = "scenario"> |
| 2769 | + TODO. |
| 2770 | + </doc> |
| 2771 | + </rule> |
| 2772 | + |
| 2773 | + <chassis name = "server" implement = "MUST" /> |
| 2774 | + |
| 2775 | + <field name = "delivery-tag" domain = "delivery-tag" /> |
| 2776 | + |
| 2777 | + <field name = "multiple" domain = "bit" label = "reject multiple messages"> |
| 2778 | + <doc> |
| 2779 | + If set to 1, the delivery tag is treated as "up to and |
| 2780 | + including", so that multiple messages can be rejected |
| 2781 | + with a single method. If set to zero, the delivery tag |
| 2782 | + refers to a single message. If the multiple field is 1, and |
| 2783 | + the delivery tag is zero, this indicates rejection of |
| 2784 | + all outstanding messages. |
| 2785 | + </doc> |
| 2786 | + <rule name = "exists" on-failure = "precondition-failed"> |
| 2787 | + <doc> |
| 2788 | + A message MUST not be rejected more than once. The |
| 2789 | + receiving peer MUST validate that a non-zero delivery-tag |
| 2790 | + refers to an unacknowledged, delivered message, and |
| 2791 | + raise a channel exception if this is not the case. |
| 2792 | + </doc> |
| 2793 | + <doc type = "scenario"> |
| 2794 | + TODO. |
| 2795 | + </doc> |
| 2796 | + </rule> |
| 2797 | + </field> |
| 2798 | + |
| 2799 | + <field name = "requeue" domain = "bit" label = "requeue the message"> |
| 2800 | + <doc> |
| 2801 | + If requeue is true, the server will attempt to requeue the message. If requeue |
| 2802 | + is false or the requeue attempt fails the messages are discarded or dead-lettered. |
| 2803 | + </doc> |
| 2804 | + |
| 2805 | + <rule name = "01"> |
| 2806 | + <doc> |
| 2807 | + The server MUST NOT deliver the message to the same client within the |
| 2808 | + context of the current channel. The recommended strategy is to attempt to |
| 2809 | + deliver the message to an alternative consumer, and if that is not possible, |
| 2810 | + to move the message to a dead-letter queue. The server MAY use more |
| 2811 | + sophisticated tracking to hold the message on the queue and redeliver it to |
| 2812 | + the same client at a later stage. |
| 2813 | + </doc> |
| 2814 | + <doc type = "scenario"> |
| 2815 | + TODO. |
| 2816 | + </doc> |
| 2817 | + </rule> |
| 2818 | + </field> |
| 2819 | + </method> |
| 2820 | + |
2736 | 2821 | </class>
|
2737 | 2822 |
|
2738 | 2823 | <!-- == TX =============================================================== -->
|
|
0 commit comments