I am familiar with few of MQ Adapters. E.g. webMethods has an MQ adapter that uses Synchronous and Async notification. in Async, it would take message from MQ and "publish it " internally... similar to "seda" architecture (but using a file based storage if the message was "Guaranteed").
ચિરાગ/चिराग/Chirag ------------------------------------------ Sent from My Gmail Account On Tue, Sep 30, 2025 at 5:23 AM Gael LE BELLEGO < [email protected]> wrote: > Hi > > And thanks to both of you. > I'll try to answer your questions. > > Peter, we are using ibm.mq.allclients in other projets, including a tool > for performance testing, and it's running fine (in same condition) > And about TCP connexions (using both netstat and tcpdump) we noticed that > it kept opening new connexions : the "ESTABLISHED" one keeps changing, thus > it sounds like the problem is around here. > That's why we considered (but failed!) using a CachingConnectionFactory. > > You say you have been consuming from MQ to ActiveMQ for years: it was > using the camel JMS component? > > > Chirag, > > Unfortunately, I am not sure I understand your question. I'll try to > answer anyway : our precent implementation was a > "message-driven-channel-adapter" that was asynchronous. > There was no buffering / integration queue in the middle (or none that I > was aware of). > > -----Message d'origine----- > De : Chirag <[email protected]> > Envoyé : lundi 29 septembre 2025 16:30 > À : [email protected] > Objet : Re: Looking for help on "Jms" Component performances for MqSeries > consuming / producing > > ATTENTION: Cet e-mail provient d'une personne externe à votre > organisation. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces > jointes si vous ne connaissez pas l'expéditeur et que vous n'êtes pas sûr > que le contenu est sûr > > Since you are comparing to a previous integration tool ; was previous > integration tool using async option with another queue within "integration"? > > ચિરાગ/चिराग/Chirag > ------------------------------------------ > Sent from My Gmail Account > > > On Sat, Sep 27, 2025 at 11:13 AM Peter Hicks <[email protected]> > wrote: > > > Salut Gael > > > > On Monday, 22 September 2025 at 18:13, Gael LE BELLEGO < > > [email protected]> wrote: > > > > > The routes are going well... but for one case : when we consume from > > > or > > publish to MqSeries, we end up having terrible performances. > > > On a previous application, (implemented with another EIP framework), > > > we > > had a mean message rate of 40 m/s with only one consumer or producer. > > > Currently, our message rate dropped to 2 m/s with the JMS component. > > > (similar comparing conditions). > > > > I have experience of using IBM MQ (not heard it called MQSeries for > > years!) and I can offer you these suggestions: > > > > 1. Switch to using the MQ 'allclient' directly and compare performance > > - in the past I've had problems where publish or subscribe rates were > > limited because a client was connecting, sending/receiving, then > disconnecting. > > 'tcpdump' can help you identify if your client is reusing or setting > > up a new TCP connection as new connections are expensive in MQ terms > > 2. The overhead on persistent messages with IBM MQ is higher than I > > thought it would be, so check your performance when publishing - > > particularly, the I/O throughput of the server is important here > > > > I've been running Camel inside ActiveMQ for 8+ years consuming from an > > MQ Server and republishing to a local AMQ topic - it works really really > well. > > > > > > Peter > > > ATTENTION : Ce message et toutes les pièces jointes (ci-après le > "message") sont confidentiels et strictement réservés aux destinataires qui > procèderont aux vérifications appropriées en matière de virus. Toute > utilisation ou diffusion non autorisée est interdite. > Tout message électronique est susceptible d'altération. L'auteur de ce > message et le Groupe Open déclinent toute responsabilité au titre de ce > message s'il a été altéré, déformé, falsifié ou indûment utilisé par des > tiers, ou encore s'il a causé tout dommage ou perte de toute nature. > Si vous n'êtes pas destinataire de ce message, merci de le détruire > immédiatement et d'avertir l'expéditeur. > > WARNING : This message and any attachments (the "message") are > confidential and strictly intended for their addressees, who will conduct > appropriate virus checks. Any unauthorised use or dissemination is > prohibited. > Messages are susceptible to alteration. The author of this message or Open > Group shall not be liable for the message if altered, changed, falsified or > unduly used by third parties, or for any damage or loss. > If you are not receiver of this message, please cancel it immediately and > inform the sender. > ________________________________ > > Open, responsable de traitement, met en œuvre des traitements de données à > caractère personnel. > Pour en savoir plus : > https://www.open.global/politique-de-protection-donnees-personnelles > > Open, data controller, processes personal data. > Click the link below to find out more details: > https://www.open.global/politique-de-protection-donnees-personnelles >
