Re: JMS MessageProducer very slow writing to Cluster Queue - Resolved
James,
Thanks. You are exactly right - I was using the same Session to send
messages while a consumer in that Session had registered a
MessageListener. A basic violation of Session single-threading. I
could have saved myself a lot of headaches by reading the JMS
specification!
For what its worth, I do think that having Websphere MQ detect this and
throw a runtime exeception would be a valuable application programming
aid. I assume it is a common mistake that JMS novices make.
-- Mark
> -Original Message-
> From: James Kingdon [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 01, 2004 6:21 AM
> To: MQSeries List; Mark D. Hansen
> Subject: Re: JMS MessageProducer very slow writing to Cluster Queue -
> Resolved
>
>
> Hi Mark,
>
> It sounds like you may have been using the same Session
> instance for the
> MessageListener and the MessageProducer. This is technically
> a violation
> of the JMS specification (unless the MessageProducer is used
> from within
> onMessage) as it breaks the single threaded use of sessions. Some
> versions of MQ JMS detect this case and throw an exception, but I
> believe the latest version lets it through, in which case it would be
> likely to suffer the sort of performance issues you describe.
> I'll take
> it up with the current code owner to find out the position on
> allowing
> the call vs throwing an exception.
>
> If the above is the cause of your problem, the solution is to
> either use
> a different session for the MessageProducers or to ensure
> that you only
> use the MessageProducers from within onMessage, whichever best meets
> your application requirements. In general, you should always
> ensure that
> a Session is never used concurrently, which includes calls across the
> set of objects created from that Session such as MessageProducers and
> MessageConsumers. The exception is for calls to Connection
> and Session
> close. You need to keep in mind that the async delivery
> mechanism also
> counts as a Thread and is considered to own the Session if
> there is at
> least one MessageListener registered on the MessageConsumers of that
> Session and the Connection is started. Section 4.4.6 "Conventions for
> Using a Session" of the JMS spec' covers this in more detail.
>
> Regards,
> James.
>
> Mark D. Hansen wrote:
>
> >Sorry to reply to my own post, but I figured this out and
> I'm wondering if anyone else has had a similar experience.
> >
> >It turned out that when I got rid of the JMS MessageListener
> that I was using on the Queue Manager that was trying to send
> to the cluster queue, my performance went through the roof.
> Maybe the MessageListener was blocking the mechanism by which
> messages get put to a cluster queue?!?!
> >
> >Anybody got any ideas that might shed some light on this behavior?
> >
> >Thanks,
> >
> >Mark
> >
> >
> >
> >>-Original Message-
> >>From: Mark D. Hansen
> >>Sent: Tuesday, March 30, 2004 11:22 AM
> >>To: 'MQ (E-mail)'
> >>Cc: Mark D. Hansen
> >>Subject: JMS MessageProducer very slow writing to Cluster Queue
> >>
> >>
> >>I'm tearing my hair out with this. Any help would be much
> >>appreciated.
> >>
> >>Whenever I invoke MessageProducer.send() where the
> >>MessageProducer has been defined on a Cluster Queue, it takes
> >>about 5 seconds for the send method to return. However,
> >>producing message to a local queue is quick.
> >>
> >>Below is script that sets up the cluster.
> >>
> >>** MSQC commands to set up the Client
> >>** Make the QMGR a Cluster Repository
> >>ALTER QMGR REPOS(EAI)
> >>** Join the EAI cluster
> >>DEFINE CHANNEL(TO.EAI_CLIENT) CHLTYPE(CLUSRCVR) +
> >> TRPTYPE(TCP) CONNAME('eai-client2.javector.com') +
> >> CLUSTER(EAI) +
> >> DESCR('Cluster-receiver channel for QM_eai_client') +
> >> REPLACE
> >>DEFINE CHANNEL(TO.EAI_SERVER) CHLTYPE(CLUSSDR) TRPTYPE(TCP) +
> >> CONNAME('javector-server.javector.com') CLUSTER(EAI) +
> >> DESCR('Cluster-sender channel going to QM_eai_server') +
> >> REPLACE
> >>** Define local queue to receive responses
> >>DEFINE QLOCAL('EAI_RESPONSES') REPLACE +
> >> CLUSTER(EAI) +
> >> DESCR('For receiving responses from services') +
> >> DEFPSIST(YES) SHARE
> >>
> >>
> >>
> >
> >Instructions for managing your mailing list subscription are
> provided in
> >the Listserv General Users Guide available at http://www.lsoft.com
> >Archive: http://vm.akh-wien.ac.at/MQSeries.archive
> >
> >
> >
> >
>
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS MessageProducer very slow writing to Cluster Queue - Resolved
Hi Mark,
It sounds like you may have been using the same Session instance for the
MessageListener and the MessageProducer. This is technically a violation
of the JMS specification (unless the MessageProducer is used from within
onMessage) as it breaks the single threaded use of sessions. Some
versions of MQ JMS detect this case and throw an exception, but I
believe the latest version lets it through, in which case it would be
likely to suffer the sort of performance issues you describe. I'll take
it up with the current code owner to find out the position on allowing
the call vs throwing an exception.
If the above is the cause of your problem, the solution is to either use
a different session for the MessageProducers or to ensure that you only
use the MessageProducers from within onMessage, whichever best meets
your application requirements. In general, you should always ensure that
a Session is never used concurrently, which includes calls across the
set of objects created from that Session such as MessageProducers and
MessageConsumers. The exception is for calls to Connection and Session
close. You need to keep in mind that the async delivery mechanism also
counts as a Thread and is considered to own the Session if there is at
least one MessageListener registered on the MessageConsumers of that
Session and the Connection is started. Section 4.4.6 "Conventions for
Using a Session" of the JMS spec' covers this in more detail.
Regards,
James.
Mark D. Hansen wrote:
Sorry to reply to my own post, but I figured this out and I'm wondering if anyone else has had a similar experience.
It turned out that when I got rid of the JMS MessageListener that I was using on the Queue Manager that was trying to send to the cluster queue, my performance went through the roof. Maybe the MessageListener was blocking the mechanism by which messages get put to a cluster queue?!?!
Anybody got any ideas that might shed some light on this behavior?
Thanks,
Mark
-Original Message-
From: Mark D. Hansen
Sent: Tuesday, March 30, 2004 11:22 AM
To: 'MQ (E-mail)'
Cc: Mark D. Hansen
Subject: JMS MessageProducer very slow writing to Cluster Queue
I'm tearing my hair out with this. Any help would be much
appreciated.
Whenever I invoke MessageProducer.send() where the
MessageProducer has been defined on a Cluster Queue, it takes
about 5 seconds for the send method to return. However,
producing message to a local queue is quick.
Below is script that sets up the cluster.
** MSQC commands to set up the Client
** Make the QMGR a Cluster Repository
ALTER QMGR REPOS(EAI)
** Join the EAI cluster
DEFINE CHANNEL(TO.EAI_CLIENT) CHLTYPE(CLUSRCVR) +
TRPTYPE(TCP) CONNAME('eai-client2.javector.com') +
CLUSTER(EAI) +
DESCR('Cluster-receiver channel for QM_eai_client') +
REPLACE
DEFINE CHANNEL(TO.EAI_SERVER) CHLTYPE(CLUSSDR) TRPTYPE(TCP) +
CONNAME('javector-server.javector.com') CLUSTER(EAI) +
DESCR('Cluster-sender channel going to QM_eai_server') +
REPLACE
** Define local queue to receive responses
DEFINE QLOCAL('EAI_RESPONSES') REPLACE +
CLUSTER(EAI) +
DESCR('For receiving responses from services') +
DEFPSIST(YES) SHARE
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS MessageProducer very slow writing to Cluster Queue - Resolved
Sorry to reply to my own post, but I figured this out and I'm wondering if anyone else
has had a similar experience.
It turned out that when I got rid of the JMS MessageListener that I was using on the
Queue Manager that was trying to send to the cluster queue, my performance went
through the roof. Maybe the MessageListener was blocking the mechanism by which
messages get put to a cluster queue?!?!
Anybody got any ideas that might shed some light on this behavior?
Thanks,
Mark
> -Original Message-
> From: Mark D. Hansen
> Sent: Tuesday, March 30, 2004 11:22 AM
> To: 'MQ (E-mail)'
> Cc: Mark D. Hansen
> Subject: JMS MessageProducer very slow writing to Cluster Queue
>
>
> I'm tearing my hair out with this. Any help would be much
> appreciated.
>
> Whenever I invoke MessageProducer.send() where the
> MessageProducer has been defined on a Cluster Queue, it takes
> about 5 seconds for the send method to return. However,
> producing message to a local queue is quick.
>
> Below is script that sets up the cluster.
>
> ** MSQC commands to set up the Client
> ** Make the QMGR a Cluster Repository
> ALTER QMGR REPOS(EAI)
> ** Join the EAI cluster
> DEFINE CHANNEL(TO.EAI_CLIENT) CHLTYPE(CLUSRCVR) +
> TRPTYPE(TCP) CONNAME('eai-client2.javector.com') +
> CLUSTER(EAI) +
> DESCR('Cluster-receiver channel for QM_eai_client') +
> REPLACE
> DEFINE CHANNEL(TO.EAI_SERVER) CHLTYPE(CLUSSDR) TRPTYPE(TCP) +
> CONNAME('javector-server.javector.com') CLUSTER(EAI) +
> DESCR('Cluster-sender channel going to QM_eai_server') +
> REPLACE
> ** Define local queue to receive responses
> DEFINE QLOCAL('EAI_RESPONSES') REPLACE +
> CLUSTER(EAI) +
> DESCR('For receiving responses from services') +
> DEFPSIST(YES) SHARE
>
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
