2009-10-09 7 views
4

J'utilise la rubrique JMS pour publier des messages. Et sur le producteur de messages, je suis en train de définir setTimeToLive. Je m'attends à ce que les messages soient supprimés après 16 heures. Mais même après 16 heures, le message est toujours présent dans la base de données comme dans le sujet. Des pensées à ce sujet? Est-ce que je manque quelque chose?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); 
.... 

mon oracele-jdbc2-service.xml ont des requêtes suivantes

<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> 

Répondre

0

Votre Editeur/abonné doit être codé de manière à éliminer les messages périmés selon la spécification JMS. Il n'y a aucune garantie que le message est retiré de la file d'attente après son expiration.

2

La spécification JMS n'exige pas que le fournisseur supprime le message. Certains fournisseurs suppriment les messages expirés plutôt rapidement. Certains ne les suppriment pas jusqu'à ce qu'une opération browse ou get évalue le message pour l'expiration. Certains vont arbitrairement supprimer des messages de temps en temps, peu importe si un client a tenté de les parcourir ou de les obtenir. Garder une tâche d'arrière-plan en vie pour supprimer les messages expirés rapidement consomme évidemment des ressources de sorte que la plupart des fournisseurs vont opter pour un certain degré d'expiration "paresseux". Il est intéressant de noter que la spécification JMS stipule également que "les clients ne doivent pas recevoir les messages qui ont expiré, mais JMS ne garantit pas que cela n'arrivera pas". La plupart des fournisseurs font un bon travail pour empêcher la livraison des messages expirés, mais ce n'est pas une exigence difficile. Donc, la réponse est que, bien que voir le message dans la base de données ou sur une file d'attente/sujet après expiration peut ne pas être intuitif comme le comportement "attendu", il est dans la spécification. La question la plus importante est de savoir si le message est envoyé à votre application ou non. J'espère que ce n'est pas le cas - mais même si c'est le cas, la spécification ne l'exclut pas.

0

Hi TTL dépend également de la configuration de l'application Serveur d'application. Si vous utilisez Jboss 6, alors il utilise en interne HornetQ pour JMS. Par conséquent, certaines configurations sont requises dans standalone-full.xml pour que TTL fonctionne correctement.

message-expiry-scan-period, tentatives de remise maxi qui doivent être configurées pour que le TTL fonctionne.