2010-10-21 7 views
0

J'écris un gestionnaire de messages pour une application de transmission de messages ebXML. Le message suit le modèle Request-Response. Le processus est simple: l'expéditeur envoie un message, le destinataire reçoit le message et renvoie une réponse. Jusqu'ici tout va bien.Algorithme de demande-réponse asynchrone avec limite de temps de réponse

À la réception d'un message, le récepteur a défini un délai de réponse (TTR) au message. Cela peut aller de quelques secondes à quelques heures/jours.

Ma question est la suivante: Comment l'expéditeur devrait-il gérer le TTR? J'ai besoin que ce soit un processus asynchrone, car le TTR pourrait être assez long (plusieurs jours). Comment puis-je en quelque sorte compter le minuteur, mais ne pas attacher les ressources du système pour de longues périodes de temps. Il pourrait y avoir de gros volumes de messages.

Mon idée initiale est d'avoir une collection "en attente", à laquelle le message Id est ajouté, avec son temps d'expiration TTR. Je voudrais ensuite interroger la collection sur une base régulière. Lorsque le temporisateur expire, le message Id serait déplacé vers une collection "expirée" et la transaction de message serait terminée. Lorsque l'expéditeur reçoit une réponse, il peut vérifier la collection "Waiting" pour son message envoyé correspondant, et confirmer que la réponse a été reçue à temps. Le message serait alors retiré de la collection pour la prochaine étape du traitement.

Cela ressemble-t-il à une solution robuste. Je suis sûr que c'est un problème résolu, mais il y a peu d'informations précieuses sur ce type d'algorithme. Je prévois de l'implémenter en C#, mais le langage de mise en œuvre est un peu hors de propos à ce stade je pense.

Merci pour votre entrée

Répondre

1

En fonction du nombre de clients que vous pouvez utiliser les files d'attente JMS persistants. Une file d'attente par identifiant client. Le message restera dans la file d'attente jusqu'à ce qu'un client se connecte à lui pour le récupérer.

Je ne comprends pas le but du TTR. Est-ce plus une mesure du côté client qui signifie que si la réponse ne peut pas être retournée dans un certain délai, alors ne vous embêtez pas à l'envoyer? Ou est-ce à utiliser sur le serveur pour planifier le travail et faire ce qui est requis maintenant et pousser les demandes avec un temps de réponse plus tard à faire plus tard?

C'est une question large ...

Questions connexes