joram issueshttps://gitlab.ow2.org/joram/joram/-/issues2021-04-13T15:29:47Zhttps://gitlab.ow2.org/joram/joram/-/issues/314062Routage des messages par le bridge JMS2021-04-13T15:29:47ZSerge LacourteRoutage des messages par le bridge JMS<p>Les messages émis sur une destination bridge JMS peuvent être routé vers les différentes connexions en utilisant la propriété jms.Routing :</p>
<ul class="alternate" type="square">
<li>Actuellement la clé de routage correspond au nom...<p>Les messages émis sur une destination bridge JMS peuvent être routé vers les différentes connexions en utilisant la propriété jms.Routing :</p>
<ul class="alternate" type="square">
<li>Actuellement la clé de routage correspond au nom de la ConnectionFactory utilisée pour établir la connexion, il serait sans doute plus agréable pour l'utilisateur de pouvoir utiliser les noms des connexions qu'il définit (on peut éventuellement définir deux propriétés distinctes : jms.Routing.CF et jms.Routing.Connection).</li>
<li>Lorsqu'un message ne peut pas être routé car aucune connexion ne peut-être associée il est mis en attente et cela bloque tous les messages suivants quelques soient leurs propriétés de routage.</li>
</ul>
<i>[JORAM-73] created at 2012-09-21 11:01:33 by freyssinet, version JORAM_5_8_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314132JMS2.0 - API Clarifications - Use of ExceptionListener2021-04-13T15:36:53ZSerge LacourteJMS2.0 - API Clarifications - Use of ExceptionListener<p>Les changements de la spécification liés fonction sont décrits en B.5.16p166, la tache consiste à vérifier que Joram respecte les changements et précisions de la spécification.</p>
<p>Section 4.3.8 "ExceptionListener" has been amende...<p>Les changements de la spécification liés fonction sont décrits en B.5.16p166, la tache consiste à vérifier que Joram respecte les changements et précisions de la spécification.</p>
<p>Section 4.3.8 "ExceptionListener" has been amended to clarify how an ExceptionListener is used</p>
<i>[JORAM-143] created at 2013-07-10 16:37:02 by freyssinet, version JORAM_5_9_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314133JMS2.0 - API Clarifications - Use of stop/close from a message listener2021-04-13T15:36:58ZSerge LacourteJMS2.0 - API Clarifications - Use of stop/close from a message listener<p>Les changements de la spécification liés fonction sont décrits en B.5.17 p166-167, ce changement a entrainé de nombreuses modifications dans la spécification (listés dans la section B.5.17). La tache consiste à vérifier que Joram resp...<p>Les changements de la spécification liés fonction sont décrits en B.5.17 p166-167, ce changement a entrainé de nombreuses modifications dans la spécification (listés dans la section B.5.17). La tache consiste à vérifier que Joram respecte bien la spécification, en particulier des exceptions doivent être levées en cas de mauvais usage de l'API.</p>
<p>If the standard API was used to register the MessageListener then the onMessage method must not call its own Connection's stop or close methods, its own Session's stop method or its own MessageConsumer's close method.</p>
<p>If the simplified API was used to register the MessageListener then the onMessage method must not call its own JMSContext's stop or close methods or its own JMSConsumer's close method.</p>
<i>[JORAM-144] created at 2013-07-10 16:47:08 by freyssinet, version JORAM_5_9_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314134JMS2.0 - API Clarifications - Use of noLocal when creating a durable subscrip...2021-04-13T15:37:04ZSerge LacourteJMS2.0 - API Clarifications - Use of noLocal when creating a durable subscription<p>Les changements de la spécification liés fonction sont décrits en B.5.18 p167. Cette tache consiste à contrôler que Joram respecte la spécification, elle est liée à "<a href="http://tiga:8080/browse/JORAM-133" title="JMS2.0 - Multiple...<p>Les changements de la spécification liés fonction sont décrits en B.5.18 p167. Cette tache consiste à contrôler que Joram respecte la spécification, elle est liée à "<a href="http://tiga:8080/browse/JORAM-133" title="JMS2.0 - Multiple consumers on topic suscription"><del>JORAM-133</del></a> - JMS2.0 - Multiple consumers on topic suscription " et "<a href="http://tiga:8080/browse/JORAM-140" title="JMS2.0 - API Clarifications - Client Identifier"><del>JORAM-140</del></a> - JMS2.0 - API Clarifications - Client Identifier".</p>
<p>The specification has been amended to clarify the effect of setting the noLocal argument when creating a durable subscription. This was poorly defined in JMS 1.1.</p>
<p>In addition, the definition of noLocal has been extended to cover the case added in JMS 2.0 and described in section B.5.5 where a durable subscription has more than one active consumer</p>
<p>The new definition of noLocal is given in section 6.11.3 "Durable subscriptions". This states that when a durable subscription is created on a topic, the noLocal argument may be used to specify that messages published to the topic by its own connection or any other with the same client identifier will not be added to the durable subscription. It also states that if the client identifier is unset then setting noLocal to true will cause an exception to be thrown.</p>
<i>[JORAM-145] created at 2013-07-10 16:52:28 by freyssinet, version JORAM_5_9_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314143JMS2.0 - TCK - asynchronous sending2021-04-13T15:37:56ZSerge LacourteJMS2.0 - TCK - asynchronous sending<p>"4.6.2.4. Close, commit or rollback", p58.</p>
<p>If the close method is called on the MessageProducer, Session, Connection or JMSContext object then the JMS provider must block until any incomplete send operations have been complete...<p>"4.6.2.4. Close, commit or rollback", p58.</p>
<p>If the close method is called on the MessageProducer, Session, Connection or JMSContext object then the JMS provider must block until any incomplete send operations have been completed and all CompletionListener callbacks have returned before closing the object and returning.</p>
<p>If the session is transacted (uses a local transaction) then when the commit or rollback method is called the JMS provider must block until any incomplete send operations have been completed and all CompletionListener callbacks have returned before performing the commit or rollback.</p>
<p>Incomplete sends should be allowed to complete normally unless an error occurs.</p>
<i>[JORAM-154] created at 2013-08-09 09:08:45 by freyssinet, version JORAM_5_9_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314153Nouveau mécanisme de swap des messages2021-04-13T15:38:56ZSerge LacourteNouveau mécanisme de swap des messages<p>Ajout d'une interface MessageTable dans joram-mom-core.</p>
<p>Objectif : permettre de gérer le swap de message de manière plus efficace dans JoramMQ.</p>
<p>Deux implémentations existent :</p>
<ul class="alternate" type="square">
...<p>Ajout d'une interface MessageTable dans joram-mom-core.</p>
<p>Objectif : permettre de gérer le swap de message de manière plus efficace dans JoramMQ.</p>
<p>Deux implémentations existent :</p>
<ul class="alternate" type="square">
<li>la première dans Joram OW2 qui est une simple table de hash identique à celle utilisée par Joram 5.9.0. Le swap est géré indépendamment et globalement (par la JVM) au travers du mécanisme de "soft reference".</li>
<li>la seconde dans JoramMQ qui gère le swap de message de manière explicite (sans utiliser le mécanisme de "soft reference"). De plus, les messages non persistents peuvent également être swappés, ce qui n'est pas le cas avec Joram 5.9.0.</li>
</ul>
<p>L'utilisation de cette interface implique quelques légères modifications du code de Joram OW2 :</p>
<ul class="alternate" type="square">
<li>UserAgent : à la fin de la réaction à la notification TopicMsgsReply, la méthode 'checkSwap' de MessageTable doit être appelée.</li>
<li>UserAgent : le nettoyage effectué dans 'cleanPendingMessages' doit être délégué à MessageTable au travers d'une méthode 'clean'. Pour le nettoyage des identifiants de message de chaque ClientSubscription, il y a deux possibilités :</li>
<li>retirer les messages invalides de chaque ClientSubscription : c'est la manière actuelle de faire avec Joram 5.9.0.</li>
<li>ne pas les retirer et accepter que la MessageTable renvoie 'null' lorsqu'un message a été invalidé et extrait. Ce fonctionnement me paraît plus efficace. Par contre, chaque ClientSubscription est mise à jour de manière "lazy" (en différé, au moment où le message invalide est demandé) et non de manière synchrone avec la MessageTable.</li>
</ul>
<i>[JORAM-164] created at 2013-11-27 15:54:43 by feliot, version JORAM_5_9_1</i>https://gitlab.ow2.org/joram/joram/-/issues/314154Optimisation du stockage des identifiants de message pour une souscription do...2021-04-13T15:39:01ZSerge LacourteOptimisation du stockage des identifiants de message pour une souscription donnée<p>Ajout d'une interface MessageIdList dans joram-mom-core.</p>
<p>Objectif : permettre de stocker la liste des identifiants de message par morceaux dans JoramMQ. De plus, cette interface permet également de ne pas stocker les identifia...<p>Ajout d'une interface MessageIdList dans joram-mom-core.</p>
<p>Objectif : permettre de stocker la liste des identifiants de message par morceaux dans JoramMQ. De plus, cette interface permet également de ne pas stocker les identifiants de message non persistant.</p>
<p>Deux implémentations existent :</p>
<ul class="alternate" type="square">
<li>la première dans Joram OW2 qui est une simple liste identique à celle utilisée par Joram 5.9.0. La seule différence est que cette liste est stockée à l'extérieur de ClientSubscription en tant qu'objet spécifique avec un nom (tx name) qui lui est propre.</li>
<li>la seconde dans JoramMQ qui permet de stocker la liste en différents morceaux (donc plusieurs objets persistants). Elle permet également de ne pas stocker les identifiants de message non persistant sauf par effet de bord lorsqu'un morceau de la liste contient à la fois des identifiants de messages persistants et non persistants.</li>
</ul>
<p>L'utilisation de cette interface implique l'extraction du code d'encodage de la liste hors de ClientSubscription.</p>
<i>[JORAM-165] created at 2013-11-27 15:58:52 by feliot, version JORAM_5_9_1</i>https://gitlab.ow2.org/joram/joram/-/issues/314155Persistance plus efficace de UserAgent2021-04-13T15:39:07ZSerge LacourtePersistance plus efficace de UserAgent<p>A la réception de messages provenant d'un topic (TopicMsgsReply, TopicDeliveryTimeNot) ou d'un ordre de commit provenant d'un client JMS (CommitRequest), une sauvegarde du UserAgent est faite. Cette sauvegarde pourrait être évitée ou ...<p>A la réception de messages provenant d'un topic (TopicMsgsReply, TopicDeliveryTimeNot) ou d'un ordre de commit provenant d'un client JMS (CommitRequest), une sauvegarde du UserAgent est faite. Cette sauvegarde pourrait être évitée ou faite de manière plus efficace :<br/>
1- TopicMsgsReply: un compteur d'arrivée de message ("arrivalsCounter") est incrémenté. Est-ce que la sauvegarde de ce compteur est nécessaire ? Si oui, il faudrait séparer la persistance de ce compteur du reste de l'état du UserAgent qui est potentiellement volumineux. Si non, il suffit de ne pas sauvegarder le UserAgent.<br/>
2- CommitRequest: la sauvegarde de UserAgent semble être inutile dans ce cas.<br/>
3- TopicDeliveryTimeNot: idem.</p>
<p>Il y a peut-être encore d'autres cas à optimiser. Je pense que plus généralement, la persistance de UserAgent doit être modulaire afin d'éviter de sauvegarder systématiquement un gros volume de données.</p>
<p>Des commentaires lèvent déjà le doute au sujet de ces sauvegardes :<br/>
"// TODO (AF): is it needed to save the proxy ?"<br/>
"// TODO (AF): The message saving does it need the proxy saving ?"</p>
<p>De plus, depuis que la persistance de ClientSubscription est séparée de celle de UserAgent, ces sauvegardes ne semblent plus nécessaires.</p>
<p>Le test SpecJMS crée beaucoup de clients pour un même UserAgent entraînant un état assez gros, en particulier la table 'subsClientIDs' reliant les noms de souscriptions au 'clientId'. En conséquence, les sauvegardes décrites ci-dessus pénalisent le fonctionnement de Joram.</p>
<i>[JORAM-166] created at 2013-11-29 15:46:35 by feliot, version JORAM_5_9_1</i>https://gitlab.ow2.org/joram/joram/-/issues/314159Persistance plus efficace de Queue2021-04-13T15:39:30ZSerge LacourtePersistance plus efficace de Queue<p>A la manière de ce qui a été fait dans UserAgent, il est proposé de rendre la persistance de Queue plus modulaire en séparant les états suivants :</p>
<ul class="alternate" type="square">
<li>l'état de l'agent, contenant en particuli...<p>A la manière de ce qui a été fait dans UserAgent, il est proposé de rendre la persistance de Queue plus modulaire en séparant les états suivants :</p>
<ul class="alternate" type="square">
<li>l'état de l'agent, contenant en particulier les requêtes de réception</li>
<li>le compteur d'arrivée</li>
<li>les contextes de délivrance de message (id de USerAgent, id de client, message)</li>
</ul>
<p>La persistance est plus efficace pour les raisons suivantes :</p>
<ul class="alternate" type="square">
<li>les états sont sauvés de manière modulaire (3 états) et non de manière globale à l'agent (1 seul état)</li>
<li>la table des contextes de délivrance remplace deux tables persistantes (double stockage des identifiants de messages)</li>
<li>les contextes de message transients ne sont pas sauvés</li>
</ul>
<p>Deux classes sont définies :</p>
<ul class="alternate" type="square">
<li>QueueArrivalState : gestion du compteur d'arrivée des message</li>
<li>QueueDeliveryTable : gestion des contextes de délivrance</li>
</ul>
<p>Une question se pose au sujet de l'intérêt du stockage des contextes de délivrance, en particulier vers un UserAgent local. En effet, il semble que ces contextes soient ignorés au redémarrage comme si le client avait fait un "deny" (voir code de la classe Queue dans la méthode 'initialize'). Je me demande donc à quoi sert la persistance de ces contextes quand le UserAgent est local.</p>
<p>Pourquoi est-ce que les contextes de délivrance vers des UserAgents distants (autres serveurs Joram) ne sont pas ignorés aussi ? Quelle est la différence concernant la délivrance des messages ?</p>
<p>Par ailleurs, les bugs suivants pourraient exister (à confirmer) :</p>
<ul class="alternate" type="square">
<li>quand un acquittement de message transient est perdu, est-ce que le contexte de délivrance reste indéfiniment dans la table ? A noter qu'un contexte de délivrance de message transient peut être persisté par effet de bord.</li>
<li>un client local en HA (ou en reconnexion automatique) peut acquitter un message persistant dont le contexte de délivrance n'existe plus. Dans ce cas, la destruction du message n'est pas faite et un WARN est écrit dans le log. Ne devrait-on pas prévoir ce cas en détruisant le message à partir de son identifiant ?</li>
</ul>
<i>[JORAM-170] created at 2013-12-05 11:08:13 by feliot, version JORAM_5_9_1</i>https://gitlab.ow2.org/joram/joram/-/issues/314170Faut-il renommer la propriété de configuration 'noAckedQueue' ?2021-04-13T15:40:37ZSerge LacourteFaut-il renommer la propriété de configuration 'noAckedQueue' ?<p>La propriété 'noAckedQueue' permet d'éviter d'utiliser le protocole de ré-émission des requêtes JMS. Ce protocole est utile en mode HA avec réplication active.</p>
<p>Par défaut ce protocole est utilisé ('noAckedQueue' = false). Cepe...<p>La propriété 'noAckedQueue' permet d'éviter d'utiliser le protocole de ré-émission des requêtes JMS. Ce protocole est utile en mode HA avec réplication active.</p>
<p>Par défaut ce protocole est utilisé ('noAckedQueue' = false). Cependant on peut affecter la propriété 'noAckedQueue' à la valeur 'true' pour éviter ce protocole de ré-émission qui pénalise les performances.</p>
<p>Or, le nom de la propriété 'noAckedQueue' pourrait être interprété comme un moyen de désactiver les acquittements de message envoyé à une queue JMS : "no acked queue".</p>
<p>Pourrait-on renommer cette propriété, par exemple avec le nom 'noRequestRedelivery' ?</p>
<i>[JORAM-181] created at 2013-12-19 13:19:00 by feliot, version JORAM_5_9_1</i>https://gitlab.ow2.org/joram/joram/-/issues/314172Problème de fiabilité avec un topic en abonnement durable ?2021-04-13T15:40:49ZSerge LacourteProblème de fiabilité avec un topic en abonnement durable ?<p>Les messages délivrés à un abonnement durable sont traités dans la réaction de UserAgent à la notification TopicMsgsReply. Le traitement est fait en trois étapes principales :<br/>
1- parcours des messages par chaque ClientSubscriptio...<p>Les messages délivrés à un abonnement durable sont traités dans la réaction de UserAgent à la notification TopicMsgsReply. Le traitement est fait en trois étapes principales :<br/>
1- parcours des messages par chaque ClientSubscription : méthode 'browseNewMessages'<br/>
2- sauvegarde des messages persistants délivrés à des souscriptions durables<br/>
3- délivrance effective des messages aux clients : méthode 'deliver'</p>
<p>En cas de panne, il est possible, même si la fenêtre est très réduite, qu'un message soit délivré à un client avant qu'il ne soit sauvegardé. En effet, la délivrance des messages est initiée à l'étape 3, donc avant que la réaction à TopicMsgsReply ne soit validée.</p>
<p>On pourrait donc avoir le scénario suivant :</p>
<ul class="alternate" type="square">
<li>un abonné durable reçoit un message</li>
<li>le serveur Joram tombe en panne avant que le message ne soit sauvegardé</li>
<li>l'abonné se reconnecte et ne reçoit pas le message une deuxième fois, ce qui devrait être le cas puisque le message n'a pas été acquitté</li>
<li>l'abonné acquitte le message : l'acquittement ne peut être traité car le message n'existe pas</li>
</ul>
<p>Est-ce que ce fonctionnement est acceptable du point de vue des MOMs (des queues) et de la spécification JMS ?</p>
<i>[JORAM-183] created at 2014-01-13 11:32:40 by feliot, version JORAM_5_9_1</i>https://gitlab.ow2.org/joram/joram/-/issues/314173Topic plus efficace en mode hiérarchique et cluster2021-04-13T15:40:54ZSerge LacourteTopic plus efficace en mode hiérarchique et cluster<p>Actuellement, les notifications transmettant les messages aux topics réplicats et au topic parent sont persistantes.</p>
<p>Dans le cas où ces topics (réplicat ou parent) sont locaux, il est plus efficace de leur envoyer une notifica...<p>Actuellement, les notifications transmettant les messages aux topics réplicats et au topic parent sont persistantes.</p>
<p>Dans le cas où ces topics (réplicat ou parent) sont locaux, il est plus efficace de leur envoyer une notification transiente, la fiabilité étant assurée par le callback transmis par la notification initiale (déclenchant la réaction).</p>
<p>Dans le cas où il n'y aurait pas de callback dans la notification initiale, le mode persistant doit être conservé en local afin d'assurer la fiabilité de la transmission.</p>
<p>Pour bénéficier de cette amélioration, il faut donc utiliser le mécanisme de callback dans les adaptateurs, par exemple AMQP et MQTT.</p>
<i>[JORAM-184] created at 2014-01-16 11:15:18 by feliot, version JORAM_5_9_1</i>https://gitlab.ow2.org/joram/joram/-/issues/314177Bug dans UserAgent en réception de messages de Topic ?2021-04-13T15:41:19ZSerge LacourteBug dans UserAgent en réception de messages de Topic ?<p>Il est possible qu'il y ait un bug dans UserAgent à la réception d'un message provenant d'un Topic (TopicMsgsReply) : <br/>
1- Un MOM message est créé, avec un compteur d'ack qui est nul.<br/>
2- Dans ClientSubscription (méthode 'brow...<p>Il est possible qu'il y ait un bug dans UserAgent à la réception d'un message provenant d'un Topic (TopicMsgsReply) : <br/>
1- Un MOM message est créé, avec un compteur d'ack qui est nul.<br/>
2- Dans ClientSubscription (méthode 'browseNewMessages'), le MOM message est mis dans la table des messages si le compteur d'ack est nul :</p>
<p>// It's the first delivery, adds the message to the proxy's table<br/>
if (message.acksCounter == 0)<br/>
messagesTable.put(message);</p>
<p>La clé du message dans la table est son identifiant.</p>
<p>Or, il est possible qu'un même message soit délivré plusieurs fois à un UserAgent via plusieurs notifications TopicMsgsReply. Dans ce cas, il semble que le deuxième message écrase le premier ce qui engendre des incohérences, notamment dans la gestion des compteurs d'ack.</p>
<p>Par exemple si un UserAgent est abonné à une hiérarchie de Topics B->A (A est parent et B enfant), il recevra deux fois les messages publiés vers B, une fois venant de B et une deuxième fois venant du Topic parent A.</p>
<p>Est-ce que le cas d'une réception multiple des messages est géré dans UserAgent ? Est-ce qu'il y a un bug à ce niveau ?</p>
<i>[JORAM-188] created at 2014-01-23 11:01:53 by feliot, version JORAM_5_9_1</i>https://gitlab.ow2.org/joram/joram/-/issues/314178Combinaison Topic Parent et Topic Cluster2021-04-13T15:41:24ZSerge LacourteCombinaison Topic Parent et Topic Cluster<p>Comme décrit par la figure jointe, il serait intéressant de combiner les fonctions de Topic Parent (hiérarchique) et de Topic Cluster.</p>
<p>Actuellement, une telle combinaison pose problème car elle multiplie la diffusion d'un même...<p>Comme décrit par la figure jointe, il serait intéressant de combiner les fonctions de Topic Parent (hiérarchique) et de Topic Cluster.</p>
<p>Actuellement, une telle combinaison pose problème car elle multiplie la diffusion d'un même message à chaque niveau de la hiérarchie de Topics.</p>
<p>Une façon de faire serait de passer les identifiants des serveurs traversés dans la notification TopicForwardNot afin d'éviter qu'un serveur reçoive plusieurs fois le même message venant de l'extérieur.</p>
<p>La diffusion au sein du cluster sur un même serveur serait maintenue pour permettre de paralléliser le traitement des abonnements sur plusieurs Topics avec un Multi-Engine (la charge des abonnements étant partagée sur les topics du cluster).</p>
<i>[JORAM-189] created at 2014-01-23 11:47:24 by feliot, version JORAM_5_9_1</i>https://gitlab.ow2.org/joram/joram/-/issues/314193Topic MQTT en mode cluster2021-04-13T15:42:54ZSerge LacourteTopic MQTT en mode cluster<p>Les abonnements MQTT sont répliqués dans chaque Topic (au sens Agent du terme) d'un cluster de Topics. Les messages ne sont donc pas systématiquement diffusés à tous les Topics (Agents) d'un cluster. Les abonnements MQTT sont pris en ...<p>Les abonnements MQTT sont répliqués dans chaque Topic (au sens Agent du terme) d'un cluster de Topics. Les messages ne sont donc pas systématiquement diffusés à tous les Topics (Agents) d'un cluster. Les abonnements MQTT sont pris en compte pour ne diffuser les messages que vers les Topics (Agents) qui ont des abonnés MQTT intéressés.</p>
<i>[JORAM-204] created at 2014-09-30 10:57:39 by feliot, version JORAM_5_9_1</i>https://gitlab.ow2.org/joram/joram/-/issues/314202Shared subscriptions (JMS 2.0)2021-04-13T15:43:48ZSerge LacourteShared subscriptions (JMS 2.0)<p>Le contrôle de flux de Topic (activate/passivate) ne semble pas fonctionner avec les souscriptions partagées.</p>
<p>Le traitement de ActivateConsumerRequest ne prend pas en compte les souscriptions partagées.</p>
<p>Je propose d'aj...<p>Le contrôle de flux de Topic (activate/passivate) ne semble pas fonctionner avec les souscriptions partagées.</p>
<p>Le traitement de ActivateConsumerRequest ne prend pas en compte les souscriptions partagées.</p>
<p>Je propose d'ajouter le code suivant :</p>
<p> if (req.getActivate() == 0) {<br/>
if (!sharedSubs.containsKey(subName)) {
sub.setActive(req.getActivate());
} else {
SharedCtx sharedCtx = sharedSubs.get(subName);
sharedCtx.remove(activeCtx.getId());
}<br/>
} else {<br/>
if (!sharedSubs.containsKey(subName)) {
sub.setActive(req.getActivate());
} } else {
SharedCtx sharedCtx = sharedSubs.get(subName);
sharedCtx.put(activeCtx.getId(), activeCtx.getId());
}<br/>
}</p>
<p>On pourrait faire mieux en ajoutant les 'getActivate' de chaque abonné.</p>
<i>[JORAM-213] created at 2015-01-23 18:02:14 by feliot, version JORAM_5_10_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314203Algo LRU de gestion des souscriptions partagées2021-04-13T15:43:53ZSerge LacourteAlgo LRU de gestion des souscriptions partagées<p>Je ne comprends pas certains aspects de l'algorithme :<br/>
1- à quoi sert la boucle 'while' et en particulier le test final 'sharedCtx.size() < i' ?<br/>
2- pourquoi n'y a-t'il pas une itération sur les 'sharedCtx' (qui me semble imp...<p>Je ne comprends pas certains aspects de l'algorithme :<br/>
1- à quoi sert la boucle 'while' et en particulier le test final 'sharedCtx.size() < i' ?<br/>
2- pourquoi n'y a-t'il pas une itération sur les 'sharedCtx' (qui me semble importante si un abonnés n'est plus actif) ?</p>
<p>J'aurais écrit le code suivant (sans la boucle 'while') :</p>
<p>Iterator<Entry<Integer, Integer>> it = sharedCtx.entrySet().iterator();<br/>
sharedLoop: while (it.hasNext()) {<br/>
Entry<Integer, Integer> entry = it.next();<br/>
ClientContext ctx = (ClientContext) contexts.get(new Integer(<br/>
entry.getKey()));<br/>
if (ctx.getActivated()) {
ctxId = ctx.getId();
if (logger.isLoggable(BasicLevel.DEBUG))
logger.log(BasicLevel.DEBUG, "Subscription " + subName
+ ", ctxId = " + ctxId);
sharedCtx.get(ctxId);// update LRU
break sharedLoop;
}<br/>
}</p>
<i>[JORAM-214] created at 2015-01-23 18:08:04 by feliot, version JORAM_5_10_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314204Erreur lors du close avec des souscriptions partagées2021-04-13T15:43:59ZSerge LacourteErreur lors du close avec des souscriptions partagées<p>La variable 'sub' semble être nulle (probablement lié à une fermeture faite deux fois pour le même 'sub').</p>
<p>UserAgent.doReact : UserAgent:#0.0.1026 - unexpected error during request: (org.objectweb.joram.shared.client.CnxCloseR...<p>La variable 'sub' semble être nulle (probablement lié à une fermeture faite deux fois pour le même 'sub').</p>
<p>UserAgent.doReact : UserAgent:#0.0.1026 - unexpected error during request: (org.objectweb.joram.shared.client.CnxCloseRequest@5c4a65ec<br/>
,requestId=-1,target=null)<br/>
java.lang.NullPointerException<br/>
at org.objectweb.joram.mom.proxies.UserAgent.doReact(UserAgent.java:2503<br/>
)<br/>
at org.objectweb.joram.mom.proxies.UserAgent.doReact(UserAgent.java:1561<br/>
)<br/>
at org.objectweb.joram.mom.proxies.UserAgent.reactToClientRequest(UserAg<br/>
ent.java:1305)<br/>
at org.objectweb.joram.mom.proxies.UserAgent.doReact(UserAgent.java:805)<br/>
at org.objectweb.joram.mom.proxies.UserAgent.react(UserAgent.java:498)<br/>
at com.scalagent.batchengine.BatchEngine.run(BatchEngine.java:1246)<br/>
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.<br/>
java:1145)<br/>
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor<br/>
.java:615)<br/>
at java.lang.Thread.run(Thread.java:744)</p>
<i>[JORAM-215] created at 2015-01-23 18:13:38 by feliot, version JORAM_5_10_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314213Contrôle de flux pour les souscriptions2021-04-13T15:44:52ZSerge LacourteContrôle de flux pour les souscriptions<p>Actuellement le contrôle de flux limite le nombre de messages envoyés à chaque délivrance avec le test suivant (méthode deliver() de ClientSubscription) :</p>
<p>if (active < deliverables.size())</p>
<p>Ce contrôle ne limite pas le ...<p>Actuellement le contrôle de flux limite le nombre de messages envoyés à chaque délivrance avec le test suivant (méthode deliver() de ClientSubscription) :</p>
<p>if (active < deliverables.size())</p>
<p>Ce contrôle ne limite pas le nombre de messages en cours d'acquittement. Ces messages sont représentés par la table 'deliveredIds'.</p>
<p>La taille de la table 'deliveredIds' ne doit pas être trop grande. En effet les identifiants sont stockés en bloc (dans ClientSubscription). Si le nombre de messages dépasse 100.000, alors la table stockée prend plusieurs Mo et peut même dépasser la taille d'un fichier de log.</p>
<p>En remplaçant 'deliverables' par 'deliveredIds', le contrôle de flux permet de limiter le nombre de messages en attente. La taille de 'deliveredIds' est inférieur à 'active'.</p>
<p>if (active < deliveredIds.size())</p>
<p>Par ailleurs, la méthode 'acknowledge' devrait appeler 'deliver' quand la taille de 'deliveredIds' repasse sous un seuil, par exemple active/2.</p>
<i>[JORAM-224] created at 2015-02-03 17:50:15 by feliot, version JORAM_5_10_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314224Duplication de messages en entrée de la queue d'acquisition.2021-04-13T15:46:00ZSerge LacourteDuplication de messages en entrée de la queue d'acquisition.<p>Le mécanisme d'acquisition de messages JMS (classe JMSAcquisition) peut délivrer plusieurs fois un message en cas de panne ou de perte de connexion (rupture de connexion entre l'envoi de la notification d'acquisition) et le commit JMS...<p>Le mécanisme d'acquisition de messages JMS (classe JMSAcquisition) peut délivrer plusieurs fois un message en cas de panne ou de perte de connexion (rupture de connexion entre l'envoi de la notification d'acquisition) et le commit JMS.</p>
<p>La queue d'acquisition traite la redélivrance d'un message mais ne garde l'historique que d'un message alors que l'ordre des messages délivrés pourrait être modifié suite au rollback.</p>
<i>[JORAM-235] created at 2015-05-21 10:34:13 by freyssinet, version JORAM_5_9_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314261REST MapMessage2021-04-13T15:49:46ZSerge LacourteREST MapMessage<p>Le message (MapMessage) doit etre transforme dans un format Json a la place d'une hashtable java serialise. </p>
<i>[JORAM-272] created at 2017-07-05 16:29:28 by tachker, version JORAM_5_14_0</i><p>Le message (MapMessage) doit etre transforme dans un format Json a la place d'une hashtable java serialise. </p>
<i>[JORAM-272] created at 2017-07-05 16:29:28 by tachker, version JORAM_5_14_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314265Bad behavior in Rest/JMS API2021-04-13T15:50:10ZSerge LacourteBad behavior in Rest/JMS API<p>The receive-next-message link get next message if the corresponding message doesn't exist.</p>
<i>[JORAM-276] created at 2017-07-21 09:19:46 by freyssinet, version JORAM_5_13_0</i><p>The receive-next-message link get next message if the corresponding message doesn't exist.</p>
<i>[JORAM-276] created at 2017-07-21 09:19:46 by freyssinet, version JORAM_5_13_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314296Export/Import des messages JMS2021-04-28T07:58:06ZSerge LacourteExport/Import des messages JMS<p>Ajouter des méthodes d'administration aux Queues / Souscriptions pour permettre l'export d'un message ou de l'ensemble des messages.<br/>
Prévoir une méthode permettant l'import d'un groupe de message.</p>
<i>[JORAM-307] created at 20...<p>Ajouter des méthodes d'administration aux Queues / Souscriptions pour permettre l'export d'un message ou de l'ensemble des messages.<br/>
Prévoir une méthode permettant l'import d'un groupe de message.</p>
<i>[JORAM-307] created at 2018-11-15 08:13:46 by freyssinet, version JORAM_5_15_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314317Problème potentiel dans Outbound[Queue|Topic]Connection2021-04-13T15:55:29ZSerge LacourteProblème potentiel dans Outbound[Queue|Topic]Connection<p>La méthode createSession de OutboundConnection a été modifiée pour prendre en compte la possibilité que la connexion sous-jacente ne soit plus valide. Le code équivalent des méthodes create<span class="error">&#91;Queue|Topic&#93;</sp...<p>La méthode createSession de OutboundConnection a été modifiée pour prendre en compte la possibilité que la connexion sous-jacente ne soit plus valide. Le code équivalent des méthodes create<span class="error">[Queue|Topic]</span>Session des classes Outbound<span class="error">[Queue|Topic]</span>Connection n'a pas été modifié en conséquence.</p>
<i>[JORAM-328] created at 2019-03-13 09:35:07 by freyssinet, version JORAM_5_16_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314324Rollback transactionnel avec cache de session activé dans Spring.2021-04-13T15:56:13ZSerge LacourteRollback transactionnel avec cache de session activé dans Spring.<p>Lorsque le cache de session de Spring est activé, la remontée d'une exception dans le listener ne déclenche pas de rollback.</p>
<i>[JORAM-335] created at 2019-05-13 17:06:10 by freyssinet, version JORAM_5_16_0</i><p>Lorsque le cache de session de Spring est activé, la remontée d'une exception dans le listener ne déclenche pas de rollback.</p>
<i>[JORAM-335] created at 2019-05-13 17:06:10 by freyssinet, version JORAM_5_16_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314341Deadlock with completion listener (JMS 2.0)2022-04-25T08:55:05ZSerge LacourteDeadlock with completion listener (JMS 2.0)<p>Ce problème est mis en évidence par le test jms2.test7. L'interblocage est décrit par la stacktrace des 2 threads ci-dessous :</p>
<p>"main" #1 prio=5 os_prio=0 tid=0x00000000028f5000 nid=0x61d4 in Object.wait() <span class="error">&...<p>Ce problème est mis en évidence par le test jms2.test7. L'interblocage est décrit par la stacktrace des 2 threads ci-dessous :</p>
<p>"main" #1 prio=5 os_prio=0 tid=0x00000000028f5000 nid=0x61d4 in Object.wait() <span class="error">[0x000000000282f000]</span><br/>
java.lang.Thread.State: WAITING (on object monitor)<br/>
at java.lang.Object.wait(Native Method)</p>
<ul class="alternate" type="square">
<li>waiting on <0x000000076ca399e0> (a org.objectweb.joram.client.jms.connection.Requestor)<br/>
at org.objectweb.joram.client.jms.connection.Requestor.request(Requestor.java:199)</li>
<li>locked <0x000000076ca399e0> (a org.objectweb.joram.client.jms.connection.Requestor)<br/>
at org.objectweb.joram.client.jms.connection.Requestor.request(Requestor.java:126)</li>
<li>locked <0x000000076ca399e0> (a org.objectweb.joram.client.jms.connection.Requestor)<br/>
at org.objectweb.joram.client.jms.Session.commit(Session.java:1612)</li>
<li>locked <0x000000076ca397b0> (a org.objectweb.joram.client.jms.Session)<br/>
at org.objectweb.joram.client.jms.JMSContext.commit(JMSContext.java:371)<br/>
at joram.jms2.Test7.run(Test7.java:74)<br/>
at joram.jms2.Test7.main(Test7.java:45)</li>
</ul>
<p>"(org.objectweb.joram.client.jms.Connection@957a0000,proxyId=#0.0.1026,key=0)" #19 prio=5 os_prio=0 tid=0x000000001fb34800 nid=0x22e0 waiting for monitor entry <span class="error">[0x000000002114e000]</span><br/>
java.lang.Thread.State: BLOCKED (on object monitor)<br/>
at org.objectweb.joram.client.jms.Session.commit(Session.java:1560)</p>
<ul class="alternate" type="square">
<li>waiting to lock <0x000000076ca397b0> (a org.objectweb.joram.client.jms.Session)<br/>
at org.objectweb.joram.client.jms.JMSContext.commit(JMSContext.java:371)<br/>
at joram.jms2.Test7.onCompletion(Test7.java:105)<br/>
at org.objectweb.joram.client.jms.connection.CompletionListener.onCompletion(CompletionListener.java:64)<br/>
at org.objectweb.joram.client.jms.connection.RequestMultiplexer$DemultiplexerDaemon.run(RequestMultiplexer.java:605)<br/>
at java.lang.Thread.run(Thread.java:745)</li>
</ul>
<i>[JORAM-352] created at 2019-10-08 17:10:12 by freyssinet, version JORAM_5_13_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314344Sauvegarde des propriétés liés à la persistance.2021-04-13T15:58:14ZSerge LacourteSauvegarde des propriétés liés à la persistance.<p>Les propriétés nécessaires à l'initialisation de la persistance ne peuvent pas être définies dans la configuration de Joram car elles ne peuvent pas être retrouvées lors du redémarrage.<br/>
Il faudrait les stocker dans un fichier de ...<p>Les propriétés nécessaires à l'initialisation de la persistance ne peuvent pas être définies dans la configuration de Joram car elles ne peuvent pas être retrouvées lors du redémarrage.<br/>
Il faudrait les stocker dans un fichier de propriété dans le répertoire de persistance à l'image du fichier TFC (see <a href="http://tiga:8080/browse/JORAM-354" title="Message d'erreur au démarrage "TFC file does not exist"">JORAM-354</a>).<br/>
Ce mécanisme pourrait être implanté dans AbstractTransaction et être commun aux différentes implantations (voir le fichier TPF).</p>
<i>[JORAM-355] created at 2019-10-29 17:00:24 by freyssinet, version JORAM_5_16_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314351Usage de la méthode Transaction.loadAll pour le rechargement des queues de me...2022-11-21T09:44:29ZSerge LacourteUsage de la méthode Transaction.loadAll pour le rechargement des queues de messages<p>Le rechargement des queues contenant un grand nombre de messages est couteux (Joram#358).<br/>
La méthode Transaction.loadAll permet d'optimiser le chargement d'objets depuis la BDD en les factorisant en une unique opération.<br/>
Act...<p>Le rechargement des queues contenant un grand nombre de messages est couteux (Joram#358).<br/>
La méthode Transaction.loadAll permet d'optimiser le chargement d'objets depuis la BDD en les factorisant en une unique opération.<br/>
Actuellement son utilisation pose problème lorsque le swap des messages est activé car cette méthode ne permet pas de filtrer les objets 'body' des objets 'header'.<br/>
Il faudrait soit modifier le nommage des objets 'header' et 'body', ce qui pose un problème de compatibilité ascendante, soit que cette méthode permette un filtrage plus intelligent ce qui n'est pas évident avec le SQL LIKE.</p>
<i>[JORAM-362] created at 2020-02-04 11:27:34 by freyssinet, version JORAM_5_18_0-SNAPSHOT</i>https://gitlab.ow2.org/joram/joram/-/issues/314360Authentification externe (fichier) du client JMS2021-04-13T15:59:50ZSerge LacourteAuthentification externe (fichier) du client JMS<p>Les données user/password de l'authentification JMS sont actuellement conservées dans la base de persistance au travers du topic d'administration. Hormis le fait que ceux-ci sont conservés sans encryptage cela rend difficile leur modi...<p>Les données user/password de l'authentification JMS sont actuellement conservées dans la base de persistance au travers du topic d'administration. Hormis le fait que ceux-ci sont conservés sans encryptage cela rend difficile leur modification par l'utilisateur.</p>
<p>L'authentification Joram/JMS repose sur l'interface Identity qui permet différentes implantations, il serait souhaitable d'offrir une implantation fichier identique à celle de JoramMQ/MQTT.</p>
<i>[JORAM-371] created at 2020-08-28 07:37:17 by freyssinet, version JORAM_5_18_0-SNAPSHOT</i>https://gitlab.ow2.org/joram/joram/-/issues/314362Implantation des méthodes cleanWaitingRequest et cleanPendingMessage du MBean...2021-04-13T16:00:02ZSerge LacourteImplantation des méthodes cleanWaitingRequest et cleanPendingMessage du MBean de la Queue<p>Ces méthodes uniquement utilisées au travers de l'interface du MBean (JMX) ont été vidées de leur contenu suite à <a href="http://tiga:8080/browse/JORAM-372" title="Exception ArrayIndexOutOfBoundsException durant le nettoyage de la fi...<p>Ces méthodes uniquement utilisées au travers de l'interface du MBean (JMX) ont été vidées de leur contenu suite à <a href="http://tiga:8080/browse/JORAM-372" title="Exception ArrayIndexOutOfBoundsException durant le nettoyage de la file de requête de la queue."><del>JORAM-372</del></a>. Une implantation possible est d'utiliser une notification synchrone (SyncNot) dont le traitement consistera à appeler les méthodes correspondantes.</p>
<i>[JORAM-373] created at 2020-12-09 18:26:53 by freyssinet, version JORAM_5_17_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314368Rebouclage de la numérotation des messages et redémarrage2022-04-27T08:43:41ZSerge LacourteRebouclage de la numérotation des messages et redémarrage<p>Les messages sont numérotés par un int 32 bits (31 en fait puisque seules les valeurs positives sont prises en compte). Lorsque le compteur arrive au maximum il est remis à 0.<br/>
Cela ne pose normalement pas de problème sauf si le s...<p>Les messages sont numérotés par un int 32 bits (31 en fait puisque seules les valeurs positives sont prises en compte). Lorsque le compteur arrive au maximum il est remis à 0.<br/>
Cela ne pose normalement pas de problème sauf si le serveur est redémarré alors que des messages avant et après réinitialisation cohabitent dans les files des MessageConsumer. Lors du redémarrage les messages avec les plus petits indices seront insérés en tête de file, et les autres pourraient même ne pas être distribués.</p>
<i>[JORAM-379] created at 2021-02-07 17:26:56 by freyssinet, version JORAM_5_17_0</i>https://gitlab.ow2.org/joram/joram/-/issues/314371Contenu du répertoire de persistance2021-04-28T07:14:47ZAndre FreyssinetContenu du répertoire de persistanceLe répertoire de persistance s# contient à la fois les objets du repository, les fichiers de logs et le répertoire de cache de Felix.Le répertoire de persistance s# contient à la fois les objets du repository, les fichiers de logs et le répertoire de cache de Felix.Andre FreyssinetAndre Freyssinethttps://gitlab.ow2.org/joram/joram/-/issues/314390Updates Jakarta/JMS version to 3.1.02024-01-19T06:05:40ZAndre FreyssinetUpdates Jakarta/JMS version to 3.1.0Jakarta Messaging 3.1 will be a minor update with fixes and enhancements.
This version needs Java 11.Jakarta Messaging 3.1 will be a minor update with fixes and enhancements.
This version needs Java 11.https://gitlab.ow2.org/joram/joram/-/issues/314391Updates Maven plugins2023-10-04T13:04:21ZAndre FreyssinetUpdates Maven pluginsThe following plugin updates are available:
- maven-assembly-plugin: 3.3.0 -> 3.4.2
- maven-gpg-plugin: 1.6 -> 3.0.1
- maven-javadoc-plugin: 3.0.0 -> 3.3.1
- maven-release-plugin: 2.5.3 -> 3.0.0-M4
- maven-surefire-plugi: 2.22.2 -> 3.0.0...The following plugin updates are available:
- maven-assembly-plugin: 3.3.0 -> 3.4.2
- maven-gpg-plugin: 1.6 -> 3.0.1
- maven-javadoc-plugin: 3.0.0 -> 3.3.1
- maven-release-plugin: 2.5.3 -> 3.0.0-M4
- maven-surefire-plugi: 2.22.2 -> 3.0.0-M5
The following plugins do not have their version specified:
- maven-release-plugin: (from super-pom) 3.0.0-M4
Project inherits minimum Maven version as: 3.8.3
Plugins require minimum Maven version of: 3.1.0https://gitlab.ow2.org/joram/joram/-/issues/314392Jersey reference in jakarta.ws2024-03-11T09:56:18ZAndre FreyssinetJersey reference in jakarta.wsWhen using Jersey in a JakartaWS application it is necessary to inject the names of the Jersey implementation classes for RuntimeDelegate and ClientBuilder.
Ideally JakartaWS discovers the implementation itself but it does not seem to wo...When using Jersey in a JakartaWS application it is necessary to inject the names of the Jersey implementation classes for RuntimeDelegate and ClientBuilder.
Ideally JakartaWS discovers the implementation itself but it does not seem to work in our case, perhaps it is due to OSGi, or to our environment.
Currently, we set specified global environment variables in all classes using JakartaWS. On the one hand it is not very practical, on the other hand it prevents any evolution of the implementation (a priori our code is almost independent of Jersey).https://gitlab.ow2.org/joram/joram/-/issues/314396Handling delayed messages in queues.2024-03-21T14:37:42ZAndre FreyssinetHandling delayed messages in queues.Currently the management of delayed messages is not scalable. Messages are not kept in the queue (memory) and a task is scheduled for each (the message is kept in this task and sent with the publication notification).
This way of handli...Currently the management of delayed messages is not scalable. Messages are not kept in the queue (memory) and a task is scheduled for each (the message is kept in this task and sent with the publication notification).
This way of handling timed messages is not scalable. We should maintain an ordered list of timed messages, and set a timer for the first timeout (see Scheduler class).https://gitlab.ow2.org/joram/joram/-/issues/314397Export a JMS queue to JSon2024-03-27T14:13:38ZAndre FreyssinetExport a JMS queue to JSonAllows the export in JSon format of a JMS queue and all its messages (delivered and delayed). The first objective is to be able to retrieve the state of a queue for observation purposes. The final objective could be to rebuild an identic...Allows the export in JSon format of a JMS queue and all its messages (delivered and delayed). The first objective is to be able to retrieve the state of a queue for observation purposes. The final objective could be to rebuild an identical queue at a (new) broker (possibly after correcting potential errors).
See #314394 and #314395.Andre FreyssinetAndre Freyssinet