Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (中文) » QAnywhere » QAnywhere 参考 » 消息标头和属性

 

消息标头

所有 QAnywhere 消息都支持相同的标头字段集。标头字段包含客户端和提供程序用来标识和路由消息的值。

以下消息标头是预定义的。其使用方法取决于您所拥有的客户端应用程序的类型。

  • Message ID   只读。新消息的消息 ID。仅在发送消息后,此标头才会有值。请参见:

  • Message creation timestamp   只读。Timestamp 标头字段包含消息的创建时间。时间为协调通用时间 (UTC)。它不是消息实际传输的时间,因为事务或其它客户端消息排队可能导致实际发送推迟。可以在收到消息后以及发生回退或提交之前读取此标头;之后则无法读取。请参见:

  • Reply-to address   读写。如果回复地址不存在,则以 VARCHAR(128) 或空值表示。可以在收到消息后以及发生回退或提交之前读取此标头;之后则无法读取。请参见:

  • Message address   只读。以 VARCHAR(128) 表示 QAnywhere 消息地址。QAnywhere 消息地址的形式为 id\queue-name。可以在收到消息后以及发生回退或提交之前读取此标头;之后则无法读取。请参见:

  • Redelivered state of message   只读。以 BIT 表示重新传送的值。值 1 表示正在重新传送消息;值 0 表示现在未重新传送消息。

    如果某消息以前被接收过但未进行确认,则可以重新传送该消息。例如,消息虽已收到,但接收消息的应用程序在崩溃前没有完成对消息内容的处理。这种情况下,QAnywhere 将消息标记为重新传送,以警告接收方注意消息可能只处理了一部分。

    例如,假定消息的接收过程分为三个步骤:

    1. 由使用非事务性 QAnywhere Manager 的应用程序接收消息。

    2. 该应用程序将消息内容和消息 ID 写入名为 T1 的数据库表,然后提交更改。

    3. 应用程序确认此消息。

    如果应用程序在步骤 1 和 2 之间或步骤 2 和 3 之间发生故障,则消息将在应用程序重新启动时重新传送。

    如果在第 1 步和第 2 步之间发生故障,则应通过运行第 2 步和第 3 步来处理重新传送的消息。如果在第 2 步和第 3 步之间发生故障,则消息已得到处理,仅需您确认。

    要确定应用程序发生故障时发生了何种情况,可让应用程序调用 ml_qa_getredelivered,以检查以前是否重新传送过此消息。只有重新传送的消息需要在表 T1 中查找。比起让应用程序访问已接收消息的消息 ID 以查看此消息是否在表 T1 中,这样做效率更高,原因是应用程序故障很少发生。

    可以在收到消息后以及发生回退或提交之前读取此标头;之后则无法读取。

    请参见:

  • Expiration of message   只读(只有在 SQL API 中是读写)。以 TIMESTAMP 表示的到期时间。如果没有到期时间,则返回空值。如果消息未在指定时间内由预期接收者接收,则它将过期。然后,可使用缺省的 QAnywhere 删除规则删除此消息。可以在收到消息后以及发生回退或提交之前读取此标头;之后则无法读取。请参见:

  • Priority of message   读写。QAnywhere API 定义十种级别的优先级值,0 代表最低优先级,9 代表最高优先级。客户端应将优先级 0-4 视为普通优先级等级,将优先级 5-9 视为加速优先级等级。可以在收到消息后以及发生回退或提交之前读取此标头;之后则无法读取。请参见:

  • Message ID of a message for which this message is a reply   读写。以 VARCHAR(128) 表示的回复 ID。客户端可使用 InReplyToID 标头字段,将一条消息与另一条消息相链接。典型应用是将响应消息与其请求消息相链接。回复 ID 是作为此消息回复对象的消息的 ID。可以在收到消息后以及发生回退或提交之前读取此标头;之后则无法读取。请参见:

某些消息标头可以在传输规则中使用。请参见规则引擎定义的变量

另请参见