IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

API standards et tierces Java Discussion :

[MQ / JMS] onMessage() consommation et relecture d'un message


Sujet :

API standards et tierces Java

  1. #1
    kij
    kij est déconnecté
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    362
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 362
    Par défaut [MQ / JMS] onMessage() consommation et relecture d'un message
    Bonjour,

    Je suis en train de mettre en place un programme Java serveur qui lit une queue remote via JMS.

    Ce programme tourne en tâche de fond, et traite les messages reçu via un JMSListener et la méthode onMessage()

    Dans la méthode onMessage, selon le type de message, je vais en traiter certains et pas d'autres.

    Deux problèmes distincts se posent:

    - Lorsqu'un message sera traité, il va appeler la méthode 'acknowledge' sur lui-même, consumant ainsi tous les messages lus par la session en court. Comment faire donc pour que le message n'ayant pas à être traité ne soit pas consommé lors d'un acknowledge() d'un autre message ?
    - Comment faire pour que le listener traite à nouveau les messages non traités une fois la queue entièrement traitée ? (exemple: il y a 100 messages dans la queue, dont 3 qui n'ont pas a être traité par le programme. Après traintement de la queue il doit donc en rester 3, le programme doit pouvoir détecter à nouveau ces trois messages dans le 'onMessage')

    J'ai lu quelques sujets sur la première question, comme quoi la solution serait une queue temporaire. Je n'ai pas vraiment bien compris en quoi cela permettrait de résoudre le problème... si jamais quelqun a des explications / une solution à me proposer je suis tout ouïe

    Pour ce qui est de la seconde question, je n'ai pas encore trouvé de sujet la traitant, je suis donc ouvert à toute proposition.

    Si je n'ai pas été suffisamment clair, n'hésitez pas à m'en faire part.

    En remerciant d'avance ceux qui pourront m'aider sur ce sujet.

    Cordialement.

  2. #2
    kij
    kij est déconnecté
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    362
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 362
    Par défaut
    Bonjour,

    J'ai une autre question, laissons de coté les précédentes pour le moment.

    J'ai un programme lisant les messages déposés dans une queue, qui créer une connection, une sessions, un consumer et un listenerpour ce consumer, de sorte que les messages soit traités dans la méthode 'onMessage' de cet listener.

    Le problème c'est que je souhaite donner le travaille à faire (traitement d'un message arrivé) à un thread.

    N'y a-t-il pas d'autres solutions "embarquées" qui gère en interne ce "thread pooling" ? Comme l'implémentation JMS sous JBoss par exemple ? Sous forme de transaction déclenchées lors de la réception d'un message dans la queue. Comme un tel processus peut-il être implémenter en Java ?

  3. #3
    Membre très actif
    Profil pro
    Inscrit en
    Février 2010
    Messages
    766
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2010
    Messages : 766
    Par défaut
    C'est assez vague, difficile de savoir ce que tu veux faire.
    Il existe la notion de transaction pour traiter des paquets de message. Tu n'es même pas obliger de consommer les messages et faire que du Browse.

  4. #4
    kij
    kij est déconnecté
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2005
    Messages
    362
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2005
    Messages : 362
    Par défaut
    Effectivement la notion de transaction est là pour traider des messages par paquets, permettant ainsi de pouvoir faire un rollback sur l'ensemble de ces messages en cas de problème.

    Je n'ai donc pas utiliser le bon vocabulaire.

    En gros mon souhait:
    Pouvoir traiter plusieurs dizaine de message écrits dans la queue en même temps. C'est donc la notion de thread pool que je cherche à avoir en "natif", et non devoir le coder moi-même (chose déjà faite mais pour le coup peu optimum)

    J'ai trouvé ma réponse : utiliser les Message Driven Bean de JBoss.

    Le pooling est gérer tout seul (selon les configurations JBoss bien entendu). Un MDB sera lancé pour chaque message reçu dans la queue (dans la limite max configurée)

    Me reste plus qu'à implémenter mon propre MDB pour effectuer le traitement voulu.

    Lien qui dit tout ce qu'il y a à savoir sur les MDB:
    http://www.huihoo.org/jboss/online_m...0/ch08s20.html

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [JMS - Amqp] Metrics pour l'envoi des messages avec JMS
    Par facilus68 dans le forum API standards et tierces
    Réponses: 0
    Dernier message: 02/05/2012, 11h19
  2. Consommation de message JMS
    Par krum dans le forum Wildfly/JBoss
    Réponses: 20
    Dernier message: 20/07/2009, 09h29
  3. Consommation de messages JMS par une application Web
    Par romain3395 dans le forum Wildfly/JBoss
    Réponses: 7
    Dernier message: 09/02/2009, 21h41
  4. [JMS] Consommation de message dans file JMS
    Par ujoodha dans le forum Java EE
    Réponses: 3
    Dernier message: 04/10/2008, 05h13
  5. MDB indiqué au serveur JMS que le message à bien été consommé
    Par romano2003 dans le forum Wildfly/JBoss
    Réponses: 1
    Dernier message: 22/07/2007, 16h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo