2009-10-09 4 views
4

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

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); 
.... 

мой 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> 

ответ

0

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

2

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

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

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

0

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

срок действия-истечения срока действия, максимальная доставка-попытки, которые необходимо настроить для обеспечения работы TTL.

Смежные вопросы