JMS setTimeToLive - PullRequest
       19

JMS setTimeToLive

4 голосов
/ 09 октября 2009

Я использую тему JMS для публикации сообщений. И в производителе сообщений я устанавливаю setTimeToLive. Я ожидаю, что сообщения будут удалены через 16 часов. Но даже после 16 часов сообщение все еще есть в БД и в теме. Есть мысли по этому поводу? Я что-то упустил?

private static final long DEFAULT_TIME_TO_LIVE = 16 * 60 * 60 * 1000;
....
session = getSession(jndiContext);
MessageProducer mp = createTopicMessageProducer(session, jndiContext, topicName);
mp.setTimeToLive(DEFAULT_TIME_TO_LIVE);
Message msg = session.createObjectMessage(obj);
....

my oracele-jdbc2-service.xml имеет следующие запросы

<mbean code="org.jboss.mq.pm.jdbc2.PersistenceManager"
  name="jboss.mq:service=JDBCPersistenceManager">
    <depends optional-attribute-name="ConnectionManager">jboss.jca:service=DataSourceBinding,name=OracleDS</depends>
    <attribute name="SqlProperties">
      INSERT_EMPTY_BLOB = INSERT INTO JMS_MESSAGES (MESSAGEID, DESTINATION, MESSAGEBLOB, TXID, TXOP) VALUES(?,?,EMPTY_BLOB(),?,?)
      LOCK_EMPTY_BLOB = SELECT MESSAGEID, MESSAGEBLOB FROM JMS_MESSAGES WHERE MESSAGEID = ? AND DESTINATION = ? FOR UPDATE
      BLOB_TYPE=BINARYSTREAM_BLOB
      INSERT_TX = INSERT INTO JMS_TRANSACTIONS (TXID) values(?)
      INSERT_MESSAGE = INSERT INTO JMS_MESSAGES (MESSAGEID, DESTINATION, MESSAGEBLOB, TXID, TXOP) VALUES(?,?,?,?,?)
      SELECT_ALL_UNCOMMITED_TXS = SELECT TXID FROM JMS_TRANSACTIONS
      SELECT_MAX_TX = SELECT MAX(TXID) FROM (SELECT MAX(TXID) AS TXID FROM JMS_TRANSACTIONS UNION SELECT MAX(TXID) AS TXID FROM JMS_MESSAGES)
      DELETE_ALL_TX = DELETE FROM JMS_TRANSACTIONS
      SELECT_MESSAGES_IN_DEST = SELECT MESSAGEID, MESSAGEBLOB FROM JMS_MESSAGES WHERE DESTINATION=?
      SELECT_MESSAGE_KEYS_IN_DEST = SELECT MESSAGEID FROM JMS_MESSAGES WHERE DESTINATION=?
      SELECT_MESSAGE = SELECT MESSAGEID, MESSAGEBLOB FROM JMS_MESSAGES WHERE MESSAGEID=? AND DESTINATION=?
      MARK_MESSAGE = UPDATE JMS_MESSAGES SET TXID=?, TXOP=? WHERE MESSAGEID=? AND DESTINATION=?
      UPDATE_MESSAGE = UPDATE JMS_MESSAGES SET MESSAGEBLOB=? WHERE MESSAGEID=? AND DESTINATION=?
      UPDATE_MARKED_MESSAGES = UPDATE JMS_MESSAGES SET TXID=?, TXOP=? WHERE TXOP=?
      UPDATE_MARKED_MESSAGES_WITH_TX = UPDATE JMS_MESSAGES SET TXID=?, TXOP=? WHERE TXOP=? AND TXID=?
      DELETE_MARKED_MESSAGES_WITH_TX = DELETE FROM JMS_MESSAGES MESS WHERE TXOP=? AND EXISTS (SELECT TXID FROM JMS_TRANSACTIONS TX WHERE TX.TXID = MESS.TXID)
      DELETE_TX = DELETE FROM JMS_TRANSACTIONS WHERE TXID = ?
      DELETE_MARKED_MESSAGES = DELETE FROM JMS_MESSAGES WHERE TXID=? AND TXOP=?
      DELETE_TEMPORARY_MESSAGES = DELETE FROM JMS_MESSAGES WHERE TXOP='T'
      DELETE_MESSAGE = DELETE FROM JMS_MESSAGES WHERE MESSAGEID=? AND DESTINATION=?
      CREATE_MESSAGE_TABLE = CREATE TABLE JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL, \
         DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1), \
         MESSAGEBLOB BLOB, PRIMARY KEY (MESSAGEID, DESTINATION) )
      CREATE_IDX_MESSAGE_TXOP_TXID = CREATE INDEX JMS_MESSAGES_TXOP_TXID ON JMS_MESSAGES (TXOP, TXID)
      CREATE_IDX_MESSAGE_DESTINATION = CREATE INDEX JMS_MESSAGES_DESTINATION ON JMS_MESSAGES (DESTINATION)
      CREATE_TX_TABLE = CREATE TABLE JMS_TRANSACTIONS ( TXID INTEGER, PRIMARY KEY (TXID) )
      CREATE_TABLES_ON_STARTUP = TRUE
    </attribute>
    <!-- Uncomment to override the transaction timeout for recovery per queue/subscription, in seconds -->
    <!--attribute name="RecoveryTimeout">0</attribute-->
    <!-- The number of blobs to load at once during message recovery -->
    <attribute name="RecoverMessagesChunk">0</attribute>
  </mbean>

Ответы [ 3 ]

2 голосов
/ 14 ноября 2010

Спецификация JMS не требует от провайдера когда-либо удалять сообщение. Некоторые провайдеры удаляют просроченные сообщения довольно быстро. Некоторые не удаляют их, пока операция просмотра или получения не оценит сообщение на срок действия. Некоторые будут произвольно удалять сообщения время от времени независимо от того, пытался ли клиент просмотреть их или получить. Поддержание фоновой задачи для быстрого удаления просроченных сообщений, очевидно, потребляет ресурсы, поэтому большинство провайдеров выберут определенную степень «отложенного» истечения.

Интересно, что в спецификации JMS также говорится, что «клиенты не должны получать сообщения, срок действия которых истек; однако JMS не гарантирует, что этого не произойдет». Большинство провайдеров хорошо предотвращают доставку сообщений с истекшим сроком, но это не является жестким требованием.

Таким образом, ответ таков: хотя просмотр сообщения в БД или в очереди / теме после истечения срока действия может не быть интуитивно понятным, как «ожидаемое» поведение, оно находится в пределах спецификации. Более важный вопрос заключается в том, доставлено ли указанное сообщение в вашу заявку или нет. Надеюсь, что нет, но даже если это так, спецификация не исключает этого.

0 голосов
/ 02 июня 2017

Привет TTL также зависит от конфигурации приложения сервера приложений. Если вы используете Jboss 6, то он внутренне использует HornetQ для JMS, поэтому для работы TTL необходима некоторая конфигурация в standalone-full.xml.

message-expiry-scan-period, max-delivery-попытки, которые необходимо настроить для работы TTL.

0 голосов
/ 16 декабря 2009

Ваш издатель / подписчик должен быть закодирован таким образом, чтобы отбрасывать просроченные сообщения в соответствии со спецификацией JMS. Нет никаких гарантий, что сообщение будет удалено из очереди после истечения срока его действия.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...