Java MQ Thread Question

Tim,

You are correct. Each thread has its own connection.

Raúl L. Acevedo
Senior IT Architect
IBM Global Business Services
Application Innovation Services (AIS)
818 599 6626 mobile
acevedor-r/Jw6+rmf7HQT0dZR+***@public.gmane.org email

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 08/05/2013 01:33 PM
Subject: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello,

Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know off of
the top of their head.

The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a connect
and open of a queue under thread 1, and then threads 2-6 come along and do
gets from the queue. Threads 2-6 have not done a connect or open on the
queue before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open the
queue, before it could do a get. Am I mistaken?

Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Brumbaugh Glen

2013-08-05 18:07:12 UTC

Tim,

The MQI calls are "Single Threaded" through the one MQConn handle. Thus, there may only be one current API call at a time. There is no requirement, other than common sense and/or good design, that a single WMQ handle cannot be shared between multiple threads. If this were to be done, however, the individual threads would have to implement some kind of locking mechanism to serialize their parallel access of a serial resource. A singleton Java class, for instance, could provide the necessary serialization. From the description of the developer's input, the implementation does not seem to be this sophisticated, but it could be.

HTH.

Regards,

Glen Brumbaugh
Prolifics

Post by Raul Acevedo
Tim,
You are correct. Each thread has its own connection.
Raúl L. Acevedo
Senior IT Architect
IBM Global Business Services
Application Innovation Services (AIS)
818 599 6626 mobile
<graycol.gif>Tim Zielke ---08/05/2013 01:33:33 PM---Hello, Normally, I would try to research this type of question more, but I am pressed for time this
Date: 08/05/2013 01:33 PM
Subject: Java MQ Thread Question
Hello,
Normally, I would try to research this type of question more, but I am pressed for time this week and hoping someone on the list might know off of the top of their head.
The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java developer who is saying that his multi-threaded java code does a connect and open of a queue under thread 1, and then threads 2-6 come along and do gets from the queue. Threads 2-6 have not done a connect or open on the queue before issuing the get, according to the developer. I was under the impression that each thread would need to separately connect and open the queue, before it could do a get. Am I mistaken?
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Andrew Hickson

2013-08-05 18:22:30 UTC

At the MQI level, the MQCONNX verb allows a connect request to create an
hConn that can be used under multiple threads.
The
MQCNO_HANDLE_SHARE_BLOCK/MQCNO_HANDLE_SHARE_NO_BLOCK/MQCNO_HANDLE_SHARE_NONE
options control what type of connection is created, whether the hConn is
only valid under the thread that created it, and the behavior when
multiple concurrent MQI requests are made on the same hConn. Under the
covers it's not possible for multiple concurrent MQI requests to actually
be processed in parallel, however the queue manager can serialize multiple
concurrent request when MQCNO_HANDLE_SHARE_BLOCK is specified.

From: Brumbaugh Glen <glen.brumbaugh-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 05/08/2013 19:07
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Tim,

The MQI calls are "Single Threaded" through the one MQConn handle. Thus,
there may only be one current API call at a time. There is no
requirement, other than common sense and/or good design, that a single WMQ
handle cannot be shared between multiple threads. If this were to be
done, however, the individual threads would have to implement some kind of
locking mechanism to serialize their parallel access of a serial resource.
A singleton Java class, for instance, could provide the necessary
serialization. From the description of the developer's input, the
implementation does not seem to be this sophisticated, but it could be.

HTH.

Regards,

Glen Brumbaugh
Prolifics

On Aug 5, 2013, at 1:44 PM, Raul Acevedo <acevedor-rIXRsD/***@public.gmane.org> wrote:

Tim,

You are correct. Each thread has its own connection.

Raúl L. Acevedo
Senior IT Architect
IBM Global Business Services
Application Innovation Services (AIS)
818 599 6626 mobile
acevedor-r/Jw6+rmf7HQT0dZR+***@public.gmane.org email

<graycol.gif>Tim Zielke ---08/05/2013 01:33:33 PM---Hello, Normally, I
would try to research this type of question more, but I am pressed for
time this

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 08/05/2013 01:33 PM
Subject: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello,

Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know off
of the top of their head.

The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a connect
and open of a queue under thread 1, and then threads 2-6 come along and do
gets from the queue. Threads 2-6 have not done a connect or open on the
queue before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open the
queue, before it could do a get. Am I mistaken?

Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Oliver S Fisse

2013-08-05 18:16:31 UTC

Tim,

I believe the answer to your question can be found in the link below:

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/ja11160_.htm

As you can see, it pretty much depends on whether the threads in the
application require simultaneous (concurrent) access to the MQ objects.

Oliver Fisse

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 08/05/2013 01:23 PM
Subject: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello,

Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know off
of the top of their head.

The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a connect
and open of a queue under thread 1, and then threads 2-6 come along and do
gets from the queue. Threads 2-6 have not done a connect or open on the
queue before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open the
queue, before it could do a get. Am I mistaken?

Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Bob Juch

2013-08-05 18:39:43 UTC

To provide a definitive answer, we need to know if this Java program
is JMS or Java using the API.

Bob Juch
Juch Services LLC

On Mon, Aug 5, 2013 at 2:22 PM, Andrew Hickson

Post by Andrew Hickson
At the MQI level, the MQCONNX verb allows a connect request to create an
hConn that can be used under multiple threads.
The
MQCNO_HANDLE_SHARE_BLOCK/MQCNO_HANDLE_SHARE_NO_BLOCK/MQCNO_HANDLE_SHARE_NONE
options control what type of connection is created, whether the hConn is
only valid under the thread that created it, and the behavior when multiple
concurrent MQI requests are made on the same hConn. Under the covers it's
not possible for multiple concurrent MQI requests to actually be processed
in parallel, however the queue manager can serialize multiple concurrent
request when MQCNO_HANDLE_SHARE_BLOCK is specified.
Date: 05/08/2013 19:07
Subject: Re: Java MQ Thread Question
________________________________
Tim,
The MQI calls are "Single Threaded" through the one MQConn handle. Thus,
there may only be one current API call at a time. There is no requirement,
other than common sense and/or good design, that a single WMQ handle cannot
be shared between multiple threads. If this were to be done, however, the
individual threads would have to implement some kind of locking mechanism to
serialize their parallel access of a serial resource. A singleton Java
class, for instance, could provide the necessary serialization. From the
description of the developer's input, the implementation does not seem to be
this sophisticated, but it could be.
HTH.
Regards,
Glen Brumbaugh
Prolifics
Tim,
You are correct. Each thread has its own connection.
Raúl L. Acevedo
Senior IT Architect
IBM Global Business Services
Application Innovation Services (AIS)
818 599 6626 mobile
<graycol.gif>Tim Zielke ---08/05/2013 01:33:33 PM---Hello, Normally, I would
try to research this type of question more, but I am pressed for time this
Date: 08/05/2013 01:33 PM
Subject: Java MQ Thread Question
________________________________
Hello,
Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know off of
the top of their head.
The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a connect and
open of a queue under thread 1, and then threads 2-6 come along and do gets
from the queue. Threads 2-6 have not done a connect or open on the queue
before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open the
queue, before it could do a get. Am I mistaken?
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Bob Juch

2013-08-05 17:38:12 UTC

Tim,

If you're talking about JMS, you're correct.

Bob Juch
Juch Services LLC

Post by Tim Zielke
Hello,
Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know off of
the top of their head.
The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a connect and
open of a queue under thread 1, and then threads 2-6 come along and do gets
from the queue. Threads 2-6 have not done a connect or open on the queue
before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open the
queue, before it could do a get. Am I mistaken?
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Tim Zielke

2013-08-05 19:06:15 UTC

Hi Bob,

This is a Java stand alone application. So no JMS.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Bob Juch
Sent: Monday, August 05, 2013 12:38 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

Tim,

If you're talking about JMS, you're correct.

Bob Juch
Juch Services LLC

Bob Juch

2013-08-05 19:59:44 UTC

Tim,

Well it could be anything then. I'd believe the programmer. It was
considerate of your programmer to use only one connection.

Bob Juch
Juch Services LLC

Post by Tim Zielke
Hi Bob,
This is a Java stand alone application. So no JMS.
Thanks,
Tim
-----Original Message-----
Sent: Monday, August 05, 2013 12:38 PM
Subject: Re: Java MQ Thread Question
Tim,
If you're talking about JMS, you're correct.
Bob Juch
Juch Services LLC

in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Tim Zielke

2013-08-05 20:25:48 UTC

Hi Bob,

So just to clarify, the developer is saying that he has threads where the first API that is issued is a GET. So he has thread 1 that is doing a connection and the open on a request queue. And then threads 2 - 6 come along later and issue a GET, with no previous connection or open issued before the GET on these subsequent threads. I am thinking this is not possible and he is confused. I don't have a practical way to test this out in Java, so I would have to do this with a C program (which I know is not an apples to apples comparison). However, based on what others have said, I am thinking what the developer is saying is not possible. In other words, you can not issue a GET on a thread, if you have not first issued the CONN and OPEN on that same thread.

Are you saying that for a Java stand alone program, it would be possible for this type of behavior to occur as the developer is describing it? Specifically, one thread can do the connect and open for a queue, and then a subsequent thread (which has not issued a connect or open) could come along later and issue a GET?

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Bob Juch
Sent: Monday, August 05, 2013 3:00 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

Tim,

Well it could be anything then. I'd believe the programmer. It was
considerate of your programmer to use only one connection.

Bob Juch
Juch Services LLC

Jefferson Lowrey

2013-08-05 20:37:31 UTC

It's absolutely possible.

The Java API represents the queue handle (that would be returned from
MQOPEN) as an object of type MQQueue.

This object can be made visible across all threads, and accessed from all
threads - either by declaring it as a static object or by passing it
around in method calls or through other means.

MQ behind the scenes will be synchronizing all of the calls on that object
- so each get() will happen one after another, not simultaneously. This
means that the threads can potentially conflict with each other, in that
one thread could have to wait for all of the rest of the threads to finish
gets before it got any data.

The link posted by Oliver Fisse mentions this and discusses that the way
to avoid the synchronization is to create one connection for each thread.

But, yes, what the programmer has told you is absolutely possible, and
entirely likely. It may or may not be a good idea for the specific
usecase being implemented.

Thank you,

Jeff Lowrey

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 08/05/2013 01:27 PM
Subject: Re: [MQSERIES] Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hi Bob,

So just to clarify, the developer is saying that he has threads where the
first API that is issued is a GET. So he has thread 1 that is doing a
connection and the open on a request queue. And then threads 2 - 6 come
along later and issue a GET, with no previous connection or open issued
before the GET on these subsequent threads. I am thinking this is not
possible and he is confused. I don't have a practical way to test this
out in Java, so I would have to do this with a C program (which I know is
not an apples to apples comparison). However, based on what others have
said, I am thinking what the developer is saying is not possible. In
other words, you can not issue a GET on a thread, if you have not first
issued the CONN and OPEN on that same thread.

Are you saying that for a Java stand alone program, it would be possible
for this type of behavior to occur as the developer is describing it?
Specifically, one thread can do the connect and open for a queue, and then
a subsequent thread (which has not issued a connect or open) could come
along later and issue a GET?

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Bob Juch
Sent: Monday, August 05, 2013 3:00 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

Tim,

Well it could be anything then. I'd believe the programmer. It was
considerate of your programmer to use only one connection.

Bob Juch
Juch Services LLC

Post by Tim Zielke
Hi Bob,
This is a Java stand alone application. So no JMS.
Thanks,
Tim
-----Original Message-----

Behalf Of Bob Juch

Post by Tim Zielke
Sent: Monday, August 05, 2013 12:38 PM
Subject: Re: Java MQ Thread Question
Tim,
If you're talking about JMS, you're correct.
Bob Juch
Juch Services LLC

Post by Tim Zielke
Hello,
Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know

off of

Post by Tim Zielke
the top of their head.
The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a

connect and

Post by Tim Zielke
open of a queue under thread 1, and then threads 2-6 come along and do

gets

Post by Tim Zielke
from the queue. Threads 2-6 have not done a connect or open on the

queue

Post by Tim Zielke
before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open

the

Post by Tim Zielke
queue, before it could do a get. Am I mistaken?
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided

in the

Post by Tim Zielke
Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Bob Juch

2013-08-05 20:40:11 UTC

Tim,

No, that's not possible without something else doing a connect and
open. Are you sure he's not using JMS as that's how programmers using
it see the world. BTDT(GTTS).

I wrote an exit on one contract so that each time a connect was done
it put out the IP address because we were having our available
connections eaten up. You might want to do the same. When a JMS
application started up we'd see 12 connects done, one after the other,
due to it having 12 threads.

Bob Juch
Juch Services LLC

Post by Tim Zielke
Hi Bob,
So just to clarify, the developer is saying that he has threads where the first API that is issued is a GET. So he has thread 1 that is doing a connection and the open on a request queue. And then threads 2 - 6 come along later and issue a GET, with no previous connection or open issued before the GET on these subsequent threads. I am thinking this is not possible and he is confused. I don't have a practical way to test this out in Java, so I would have to do this with a C program (which I know is not an apples to apples comparison). However, based on what others have said, I am thinking what the developer is saying is not possible. In other words, you can not issue a GET on a thread, if you have not first issued the CONN and OPEN on that same thread.
Are you saying that for a Java stand alone program, it would be possible for this type of behavior to occur as the developer is describing it? Specifically, one thread can do the connect and open for a queue, and then a subsequent thread (which has not issued a connect or open) could come along later and issue a GET?
Thanks,
Tim
-----Original Message-----
Sent: Monday, August 05, 2013 3:00 PM
Subject: Re: Java MQ Thread Question
Tim,
Well it could be anything then. I'd believe the programmer. It was
considerate of your programmer to use only one connection.
Bob Juch
Juch Services LLC

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Bob Juch

2013-08-05 20:43:14 UTC

Jeff,

How could that work if the first API call is MQGET? Something else
would have had to do the connect and open and if the programmer is to
be believed there is nothing else.

Bob Juch
Juch Services LLC

Post by Jefferson Lowrey
It's absolutely possible.
The Java API represents the queue handle (that would be returned from
MQOPEN) as an object of type MQQueue.
This object can be made visible across all threads, and accessed from all
threads - either by declaring it as a static object or by passing it around
in method calls or through other means.
MQ behind the scenes will be synchronizing all of the calls on that object -
so each get() will happen one after another, not simultaneously. This means
that the threads can potentially conflict with each other, in that one
thread could have to wait for all of the rest of the threads to finish gets
before it got any data.
The link posted by Oliver Fisse mentions this and discusses that the way to
avoid the synchronization is to create one connection for each thread.
But, yes, what the programmer has told you is absolutely possible, and
entirely likely. It may or may not be a good idea for the specific usecase
being implemented.
Thank you,
Jeff Lowrey
Date: 08/05/2013 01:27 PM
Subject: Re: [MQSERIES] Java MQ Thread Question
________________________________
Hi Bob,
So just to clarify, the developer is saying that he has threads where the
first API that is issued is a GET. So he has thread 1 that is doing a
connection and the open on a request queue. And then threads 2 - 6 come
along later and issue a GET, with no previous connection or open issued
before the GET on these subsequent threads. I am thinking this is not
possible and he is confused. I don't have a practical way to test this out
in Java, so I would have to do this with a C program (which I know is not an
apples to apples comparison). However, based on what others have said, I am
thinking what the developer is saying is not possible. In other words, you
can not issue a GET on a thread, if you have not first issued the CONN and
OPEN on that same thread.
Are you saying that for a Java stand alone program, it would be possible for
this type of behavior to occur as the developer is describing it?
Specifically, one thread can do the connect and open for a queue, and then a
subsequent thread (which has not issued a connect or open) could come along
later and issue a GET?
Thanks,
Tim
-----Original Message-----
Bob Juch
Sent: Monday, August 05, 2013 3:00 PM
Subject: Re: Java MQ Thread Question
Tim,
Well it could be anything then. I'd believe the programmer. It was
considerate of your programmer to use only one connection.
Bob Juch
Juch Services LLC

Post by Tim Zielke
Hi Bob,
This is a Java stand alone application. So no JMS.
Thanks,
Tim
-----Original Message-----
Of Bob Juch
Sent: Monday, August 05, 2013 12:38 PM
Subject: Re: Java MQ Thread Question
Tim,
If you're talking about JMS, you're correct.
Bob Juch
Juch Services LLC

Post by Tim Zielke
Hello,
Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know off
of
the top of their head.
The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a connect
and
open of a queue under thread 1, and then threads 2-6 come along and do
gets
from the queue. Threads 2-6 have not done a connect or open on the queue
before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open the
queue, before it could do a get. Am I mistaken?
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the
Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Darren Douch

2013-08-05 21:11:58 UTC

To jump in late, I think Tim "mis-spoke" on that later append .. the first API
call on a secondary thread was an MQGET is what I believe he meant, and what he
originally stated.

As Jeff and others have said, yes it's possible. I would suggest/guess it's
less common than the one connection per thread design because commits are done
on the connection, so any thread could potentially be committing the work of all
the others. You need to be careful of your design if sharing connections.

Darren.

Post by Bob Juch
Jeff,
How could that work if the first API call is MQGET? Something else
would have had to do the connect and open and if the programmer is to
be believed there is nothing else.
Bob Juch
Juch Services LLC

Post by Tim Zielke
Hello,
Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know off
of
the top of their head.
The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a connect
and
open of a queue under thread 1, and then threads 2-6 come along and do
gets
from the queue. Threads 2-6 have not done a connect or open on the queue
before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open the
queue, before it could do a get. Am I mistaken?
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the
Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Jefferson Lowrey

2013-08-05 21:18:01 UTC

Bob -
The Java API works like this:
1) You create an MQQueueManager object. This represents an equivalent to
the MQCONN call, and includes an internal storage of the Connection handle
returned by the MQCONN
2) You use the MQQueueManager object to create an MQQueue object. This
represents the equivalent to an MQOPEN call, which uses the internal
connection handle from the MQQueueManager and stores the object handle
returned from the MQOPEN.

So the MQQueue object holds the MQOPEN queue handle, and then passes that
to each MQGET.

Again, the MQQueue object can either be made visible 'globally' to all
threads, or can be passed into each thread as the thread is created, or
through other means can be accessed directly from each thread. As long as
the first thread has actually created the MQQueue object, the connect and
open have been done.

It's confusing if you're not used to object oriented development, but it's
straight forward if you are.

If you're not used to object oriented development, you can think of each
instance of an object as a global structure that also contains pointers
to methods.

Thank you,

Jeff Lowrey

From: Bob Juch <bob-zLFDEVZazB/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 08/05/2013 01:53 PM
Subject: Re: [MQSERIES] Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Jeff,

How could that work if the first API call is MQGET? Something else
would have had to do the connect and open and if the programmer is to
be believed there is nothing else.

Bob Juch
Juch Services LLC

all

Post by Jefferson Lowrey
threads - either by declaring it as a static object or by passing it

around

Post by Jefferson Lowrey
in method calls or through other means.
MQ behind the scenes will be synchronizing all of the calls on that

object -

Post by Jefferson Lowrey
so each get() will happen one after another, not simultaneously. This

means

Post by Jefferson Lowrey
that the threads can potentially conflict with each other, in that one
thread could have to wait for all of the rest of the threads to finish

gets

Post by Jefferson Lowrey
before it got any data.
The link posted by Oliver Fisse mentions this and discusses that the way

Post by Jefferson Lowrey
avoid the synchronization is to create one connection for each thread.
But, yes, what the programmer has told you is absolutely possible, and
entirely likely. It may or may not be a good idea for the specific

usecase

Post by Jefferson Lowrey
being implemented.
Thank you,
Jeff Lowrey
Date: 08/05/2013 01:27 PM
Subject: Re: [MQSERIES] Java MQ Thread Question
________________________________
Hi Bob,
So just to clarify, the developer is saying that he has threads where

the

Post by Jefferson Lowrey
first API that is issued is a GET. So he has thread 1 that is doing a
connection and the open on a request queue. And then threads 2 - 6 come
along later and issue a GET, with no previous connection or open issued
before the GET on these subsequent threads. I am thinking this is not
possible and he is confused. I don't have a practical way to test this

out

Post by Jefferson Lowrey
in Java, so I would have to do this with a C program (which I know is

not an

Post by Jefferson Lowrey
apples to apples comparison). However, based on what others have said,

I am

Post by Jefferson Lowrey
thinking what the developer is saying is not possible. In other words,

you

Post by Jefferson Lowrey
can not issue a GET on a thread, if you have not first issued the CONN

and

Post by Jefferson Lowrey
OPEN on that same thread.
Are you saying that for a Java stand alone program, it would be possible

for

Post by Jefferson Lowrey
this type of behavior to occur as the developer is describing it?
Specifically, one thread can do the connect and open for a queue, and

then a

Post by Jefferson Lowrey
subsequent thread (which has not issued a connect or open) could come

along

Post by Jefferson Lowrey
later and issue a GET?
Thanks,
Tim
-----Original Message-----

Behalf Of

Post by Jefferson Lowrey
Bob Juch
Sent: Monday, August 05, 2013 3:00 PM
Subject: Re: Java MQ Thread Question
Tim,
Well it could be anything then. I'd believe the programmer. It was
considerate of your programmer to use only one connection.
Bob Juch
Juch Services LLC

Post by Tim Zielke
Hi Bob,
This is a Java stand alone application. So no JMS.
Thanks,
Tim
-----Original Message-----

Behalf

Post by Tim Zielke
Of Bob Juch
Sent: Monday, August 05, 2013 12:38 PM
Subject: Re: Java MQ Thread Question
Tim,
If you're talking about JMS, you're correct.
Bob Juch
Juch Services LLC

Post by Tim Zielke
Hello,
Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know

off

Post by Tim Zielke
of
the top of their head.
The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a

connect

Post by Tim Zielke
and
open of a queue under thread 1, and then threads 2-6 come along and do
gets
from the queue. Threads 2-6 have not done a connect or open on the

queue

Post by Tim Zielke
before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open

the

Post by Tim Zielke
the
Listserv General Users Guide available at http://www.lsoft.com

in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided

Post by Tim Zielke
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided

Post by Tim Zielke
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

the

Post by Jefferson Lowrey
Listserv General Users Guide available at http://www.lsoft.com

Tim Zielke

2013-08-05 21:33:30 UTC

Thank you all for the input. I really appreciate it!

I went back and read my last post, and it made sense to me. But I can see how someone could take some of it another way.

Bottom line is that what Bob, Jeff, and Darren have been saying are consistent with what the developer is saying, so that has helped clear up some MQ misunderstandings on my end, especially with threads. I need to go back and run another application activity trace on this Java application to confirm, but I believe this multi-threaded Java application is also using syncpoints and commits on the GETs and PUTs on this shared connection handle amongst the multiple threads. So this application probably has some commit/integrity issues as Darren pointed out below.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Darren Douch
Sent: Monday, August 05, 2013 4:12 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

To jump in late, I think Tim "mis-spoke" on that later append .. the first API
call on a secondary thread was an MQGET is what I believe he meant, and what he
originally stated.

As Jeff and others have said, yes it's possible. I would suggest/guess it's
less common than the one connection per thread design because commits are done
on the connection, so any thread could potentially be committing the work of all
the others. You need to be careful of your design if sharing connections.

Darren.

Post by Tim Zielke
Hello,
Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know off
of
the top of their head.
The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a connect
and
open of a queue under thread 1, and then threads 2-6 come along and do
gets
from the queue. Threads 2-6 have not done a connect or open on the queue
before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open the
queue, before it could do a get. Am I mistaken?
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the
Listserv General Users Guide available at http://www.lsoft.com

Bob Juch

2013-08-05 21:49:15 UTC

Jeff,

I knew that; I've helped with debugging many times. I was just
observing that the programmer wasn't describing what must be happening
properly. As the programmer would have to do a lot of extra work to
properly share the connection across the threads, that may not
actually be happening. Or perhaps the connection is NOT being shared
properly?

Bob Juch
Juch Services LLC

Post by Jefferson Lowrey
Bob -
1) You create an MQQueueManager object. This represents an equivalent to
the MQCONN call, and includes an internal storage of the Connection handle
returned by the MQCONN
2) You use the MQQueueManager object to create an MQQueue object. This
represents the equivalent to an MQOPEN call, which uses the internal
connection handle from the MQQueueManager and stores the object handle
returned from the MQOPEN.
So the MQQueue object holds the MQOPEN queue handle, and then passes that to
each MQGET.
Again, the MQQueue object can either be made visible 'globally' to all
threads, or can be passed into each thread as the thread is created, or
through other means can be accessed directly from each thread. As long as
the first thread has actually created the MQQueue object, the connect and
open have been done.
It's confusing if you're not used to object oriented development, but it's
straight forward if you are.
If you're not used to object oriented development, you can think of each
instance of an object as a global structure that also contains pointers to
methods.
Thank you,
Jeff Lowrey
Date: 08/05/2013 01:53 PM
Subject: Re: [MQSERIES] Java MQ Thread Question
________________________________
Jeff,
How could that work if the first API call is MQGET? Something else
would have had to do the connect and open and if the programmer is to
be believed there is nothing else.
Bob Juch
Juch Services LLC

Post by Jefferson Lowrey
It's absolutely possible.
The Java API represents the queue handle (that would be returned from
MQOPEN) as an object of type MQQueue.
This object can be made visible across all threads, and accessed from all
threads - either by declaring it as a static object or by passing it
around
in method calls or through other means.
MQ behind the scenes will be synchronizing all of the calls on that object
-
so each get() will happen one after another, not simultaneously. This
means
that the threads can potentially conflict with each other, in that one
thread could have to wait for all of the rest of the threads to finish
gets
before it got any data.
The link posted by Oliver Fisse mentions this and discusses that the way
to
avoid the synchronization is to create one connection for each thread.
But, yes, what the programmer has told you is absolutely possible, and
entirely likely. It may or may not be a good idea for the specific
usecase
being implemented.
Thank you,
Jeff Lowrey
Date: 08/05/2013 01:27 PM
Subject: Re: [MQSERIES] Java MQ Thread Question
________________________________
Hi Bob,
So just to clarify, the developer is saying that he has threads where the
first API that is issued is a GET. So he has thread 1 that is doing a
connection and the open on a request queue. And then threads 2 - 6 come
along later and issue a GET, with no previous connection or open issued
before the GET on these subsequent threads. I am thinking this is not
possible and he is confused. I don't have a practical way to test this
out
in Java, so I would have to do this with a C program (which I know is not
an
apples to apples comparison). However, based on what others have said, I
am
thinking what the developer is saying is not possible. In other words,
you
can not issue a GET on a thread, if you have not first issued the CONN and
OPEN on that same thread.
Are you saying that for a Java stand alone program, it would be possible
for
this type of behavior to occur as the developer is describing it?
Specifically, one thread can do the connect and open for a queue, and then
a
subsequent thread (which has not issued a connect or open) could come
along
later and issue a GET?
Thanks,
Tim
-----Original Message-----
Of
Bob Juch
Sent: Monday, August 05, 2013 3:00 PM
Subject: Re: Java MQ Thread Question
Tim,
Well it could be anything then. I'd believe the programmer. It was
considerate of your programmer to use only one connection.
Bob Juch
Juch Services LLC

Post by Tim Zielke
Hello,
Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know off
of
the top of their head.
The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a connect
and
open of a queue under thread 1, and then threads 2-6 come along and do
gets
from the queue. Threads 2-6 have not done a connect or open on the
queue
before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open
the
queue, before it could do a get. Am I mistaken?
Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt
________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the
Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Tim Zielke

2013-09-18 13:55:53 UTC

Hi Andy,

I had one follow up on this thread.

For the most part in an API trace of a multi-threaded application, I see the behavior you mentioned below where the API (begins and ends) are serialized and only one API begin or end is running in the trace. However, for the case listed below where managed call backs are being used, I see an MQCTL end and MQGET begin running in what looks like a parallel fashion. I also see this behavior happening consistently in the trace.

Would the MQCTL end and MQGET begin (the MQGET that would run asynchronously on the MQ managed call back thread) be a case where two API calls could run in parallel?

I have listed an example of what I am seeing in the trace below. You can see the MQCTL end running on thread 2 and the MQGET begin running on thread 5 running in what appears to be parallel fashion.

This managed call back was set up so that an MQGET of 2033 would be issued immediately to the consumer function once the managed call back was activated and if no message was available on the queue.

This trace was run on a 7.1.0.2 Solaris 10 queue manager.

08:02:21.402789 554.2 CONN:1400006 __________
08:02:21.402832 554.2 CONN:1400006 MQCTL <<
*08:02:21.402797 554.5 CONN:1400006 __________
08:02:21.402856 554.2 CONN:1400006 Hconn : Input Parm
08:02:21.402882 554.5 CONN:1400006 MQGET >>
08:02:21.402905 554.2 CONN:1400006 Operation : Input Parm
08:02:21.402929 554.5 CONN:1400006 Hconn:
08:02:21.402952 554.2 CONN:1400006 CtlOpts:
08:02:21.402978 554.5 CONN:1400006 0x0000: 01400006 |***@.. |
08:02:21.403025 554.5 CONN:1400006 Msgdesc:
*08:02:21.402999 554.2 CONN:1400006 0x0000: 43544c4f 00000001 00000000 ffffffff |CTLO............|
08:02:21.402999 554.2 CONN:1400006 0x0010: 00000000 00000000 |........ |
08:02:21.403049 554.5 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
08:02:21.403049 554.5 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
08:02:21.403049 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
08:02:21.403049 554.5 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
08:02:21.403049 554.5 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
08:02:21.403071 554.2 CONN:1400006 Compcode:
08:02:21.403093 554.5 CONN:1400006 Bufferlength:
08:02:21.403115 554.2 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403166 554.2 CONN:1400006 Reason:
*08:02:21.403140 554.5 CONN:1400006 0x0000: 00002000 |.. . |
08:02:21.403191 554.2 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403212 554.5 CONN:1400006 Buffer : Output Parm
08:02:21.403259 554.5 CONN:1400006 Datalength : Output Parm
08:02:21.403277 554.5 CONN:1400006 Compcode : Output Parm
08:02:21.403293 554.5 CONN:1400006 Reason : Output Parm
08:02:21.403615 554.5 CONN:1400006 __________
08:02:21.403639 554.5 CONN:1400006 MQGET <<
08:02:21.403656 554.5 CONN:1400006 Hconn : Input Parm
08:02:21.403674 554.5 CONN:1400006 Hconn:
08:02:21.403692 554.5 CONN:1400006 0x0000: 01400006 |***@.. |
08:02:21.403709 554.5 CONN:1400006 CbContext:
08:02:21.403726 554.5 CONN:1400006 0x0000: ffffffff 26c3f221 ffffffff 00000002 |....&..!........|
08:02:21.403726 554.5 CONN:1400006 0x0010: 00000000 00000000 00000000 00000000 |................|
08:02:21.403726 554.5 CONN:1400006 0x0020: 00000001 02b42d50 00000000 00000000 |......-P........|
08:02:21.403726 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403743 554.5 CONN:1400006 Msgdesc:
08:02:21.403762 554.5 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
08:02:21.403762 554.5 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
08:02:21.403762 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
08:02:21.403762 554.5 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
08:02:21.403762 554.5 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
08:02:21.403782 554.5 CONN:1400006 Bufferlength:
08:02:21.403799 554.5 CONN:1400006 0x0000: 00002000 |.. . |
08:02:21.403816 554.5 CONN:1400006 Datalength:
08:02:21.403834 554.5 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403850 554.5 CONN:1400006 Compcode:
08:02:21.403865 554.5 CONN:1400006 0x0000: 00000002 |.... |
08:02:21.403880 554.5 CONN:1400006 Reason:
08:02:21.403897 554.5 CONN:1400006 0x0000: 000007f1 |.... |
08:02:21.426780 554.5 CONN:1400006 __________

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Monday, August 05, 2013 1:22 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

At the MQI level, the MQCONNX verb allows a connect request to create an hConn that can be used under multiple threads.
The MQCNO_HANDLE_SHARE_BLOCK/MQCNO_HANDLE_SHARE_NO_BLOCK/MQCNO_HANDLE_SHARE_NONE options control what type of connection is created, whether the hConn is only valid under the thread that created it, and the behavior when multiple concurrent MQI requests are made on the same hConn. Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel, however the queue manager can serialize multiple concurrent request when MQCNO_HANDLE_SHARE_BLOCK is specified.

From: Brumbaugh Glen <glen.brumbaugh-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 05/08/2013 19:07
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
________________________________

Tim,

The MQI calls are "Single Threaded" through the one MQConn handle. Thus, there may only be one current API call at a time. There is no requirement, other than common sense and/or good design, that a single WMQ handle cannot be shared between multiple threads. If this were to be done, however, the individual threads would have to implement some kind of locking mechanism to serialize their parallel access of a serial resource. A singleton Java class, for instance, could provide the necessary serialization. From the description of the developer's input, the implementation does not seem to be this sophisticated, but it could be.

HTH.

Regards,

Glen Brumbaugh
Prolifics

On Aug 5, 2013, at 1:44 PM, Raul Acevedo <acevedor-rIXRsD/***@public.gmane.org<mailto:acevedor-rIXRsD/***@public.gmane.org>> wrote:

Tim,

You are correct. Each thread has its own connection.

Raúl L. Acevedo
Senior IT Architect
IBM Global Business Services
Application Innovation Services (AIS)
818 599 6626 mobile
acevedor-r/Jw6+rmf7HQT0dZR+***@public.gmane.org<mailto:acevedor-r/Jw6+rmf7HQT0dZR+***@public.gmane.org> email

<graycol.gif>Tim Zielke ---08/05/2013 01:33:33 PM---Hello, Normally, I would try to research this type of question more, but I am pressed for time this

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:tim.zielke-PR+tvw7B/***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+***@public.gmane.orgac.at>,
Date: 08/05/2013 01:33 PM
Subject: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:***@listserv.meduniwien.ac.at>>

________________________________

Hello,

Normally, I would try to research this type of question more, but I am pressed for time this week and hoping someone on the list might know off of the top of their head.

The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java developer who is saying that his multi-threaded java code does a connect and open of a queue under thread 1, and then threads 2-6 come along and do gets from the queue. Threads 2-6 have not done a connect or open on the queue before issuing the get, according to the developer. I was under the impression that each thread would need to separately connect and open the queue, before it could do a get. Am I mistaken?

Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt
________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Andrew Hickson

2013-09-18 18:08:18 UTC

In order to be useful an MQCTL with MQOP_STOP/MQOP_SUSPEND has to be able
to run while the hConn is 'in use' by an async consume thread and so the
behavior of MQCTL is slightly different than for other MQI calls.
The snippet of trace provided here is too short for me to be able to see
exactly what is going on. I don't believe MQCTL is intended to interact
directly with MQGET (as opposed to an 'MQGET' issued on behalf of
callback) and the trace is too short for me to see the context of either
the MQGET oir the MQCTL calls.

sorry
Andy.

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 18/09/2013 14:58
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hi Andy,

I had one follow up on this thread.

For the most part in an API trace of a multi-threaded application, I see
the behavior you mentioned below where the API (begins and ends) are
serialized and only one API begin or end is running in the trace. However,
for the case listed below where managed call backs are being used, I see
an MQCTL end and MQGET begin running in what looks like a parallel
fashion. I also see this behavior happening consistently in the trace.

Would the MQCTL end and MQGET begin (the MQGET that would run
asynchronously on the MQ managed call back thread) be a case where two API
calls could run in parallel?

I have listed an example of what I am seeing in the trace below. You can
see the MQCTL end running on thread 2 and the MQGET begin running on
thread 5 running in what appears to be parallel fashion.

This managed call back was set up so that an MQGET of 2033 would be issued
immediately to the consumer function once the managed call back was
activated and if no message was available on the queue.

This trace was run on a 7.1.0.2 Solaris 10 queue manager.

08:02:21.402789 554.2 CONN:1400006 __________
08:02:21.402832 554.2 CONN:1400006 MQCTL <<
*08:02:21.402797 554.5 CONN:1400006 __________
08:02:21.402856 554.2 CONN:1400006 Hconn : Input
Parm
08:02:21.402882 554.5 CONN:1400006 MQGET >>
08:02:21.402905 554.2 CONN:1400006 Operation : Input
Parm
08:02:21.402929 554.5 CONN:1400006 Hconn:
08:02:21.402952 554.2 CONN:1400006 CtlOpts:
08:02:21.402978 554.5 CONN:1400006 0x0000: 01400006
|***@.. |
08:02:21.403025 554.5 CONN:1400006 Msgdesc:
*08:02:21.402999 554.2 CONN:1400006 0x0000: 43544c4f
00000001 00000000 ffffffff |CTLO............|
08:02:21.402999 554.2 CONN:1400006 0x0010: 00000000
00000000 |........ |
08:02:21.403049 554.5 CONN:1400006 0x0000: 4d442020
00000002 00000000 00000008 |MD ............|
08:02:21.403049 554.5 CONN:1400006 0x0010: ffffffff
00000000 00000111 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0020: 20202020
20202020 ffffffff 00000002 | ........|
08:02:21.403049 554.5 CONN:1400006 0x0030: 00000000
00000000 00000000 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0040: ===
Skipping 17 Duplicate Lines === |................|
08:02:21.403049 554.5 CONN:1400006 0x0150: 00000000
00000000 00000000 00000001 |................|
08:02:21.403049 554.5 CONN:1400006 0x0160: 00000000
00000000 ffffffff |............ |
08:02:21.403071 554.2 CONN:1400006 Compcode:
08:02:21.403093 554.5 CONN:1400006 Bufferlength:
08:02:21.403115 554.2 CONN:1400006 0x0000: 00000000
|.... |
08:02:21.403166 554.2 CONN:1400006 Reason:
*08:02:21.403140 554.5 CONN:1400006 0x0000: 00002000
|.. . |
08:02:21.403191 554.2 CONN:1400006 0x0000: 00000000
|.... |
08:02:21.403212 554.5 CONN:1400006 Buffer : Output
Parm
08:02:21.403259 554.5 CONN:1400006 Datalength : Output
Parm
08:02:21.403277 554.5 CONN:1400006 Compcode : Output
Parm
08:02:21.403293 554.5 CONN:1400006 Reason : Output
Parm
08:02:21.403615 554.5 CONN:1400006 __________
08:02:21.403639 554.5 CONN:1400006 MQGET <<
08:02:21.403656 554.5 CONN:1400006 Hconn : Input
Parm
08:02:21.403674 554.5 CONN:1400006 Hconn:
08:02:21.403692 554.5 CONN:1400006 0x0000: 01400006
|***@.. |
08:02:21.403709 554.5 CONN:1400006 CbContext:
08:02:21.403726 554.5 CONN:1400006 0x0000: ffffffff
26c3f221 ffffffff 00000002 |....&..!........|
08:02:21.403726 554.5 CONN:1400006 0x0010: 00000000
00000000 00000000 00000000 |................|
08:02:21.403726 554.5 CONN:1400006 0x0020: 00000001
02b42d50 00000000 00000000 |......-P........|
08:02:21.403726 554.5 CONN:1400006 0x0030: 00000000
00000000 00000000 00000000 |................|
08:02:21.403743 554.5 CONN:1400006 Msgdesc:
08:02:21.403762 554.5 CONN:1400006 0x0000: 4d442020
00000002 00000000 00000008 |MD ............|
08:02:21.403762 554.5 CONN:1400006 0x0010: ffffffff
00000000 00000111 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0020: 20202020
20202020 ffffffff 00000002 | ........|
08:02:21.403762 554.5 CONN:1400006 0x0030: 00000000
00000000 00000000 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0040: ===
Skipping 17 Duplicate Lines === |................|
08:02:21.403762 554.5 CONN:1400006 0x0150: 00000000
00000000 00000000 00000001 |................|
08:02:21.403762 554.5 CONN:1400006 0x0160: 00000000
00000000 ffffffff |............ |
08:02:21.403782 554.5 CONN:1400006 Bufferlength:
08:02:21.403799 554.5 CONN:1400006 0x0000: 00002000
|.. . |
08:02:21.403816 554.5 CONN:1400006 Datalength:
08:02:21.403834 554.5 CONN:1400006 0x0000: 00000000
|.... |
08:02:21.403850 554.5 CONN:1400006 Compcode:
08:02:21.403865 554.5 CONN:1400006 0x0000: 00000002
|.... |
08:02:21.403880 554.5 CONN:1400006 Reason:
08:02:21.403897 554.5 CONN:1400006 0x0000: 000007f1
|.... |
08:02:21.426780 554.5 CONN:1400006 __________

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Andrew Hickson
Sent: Monday, August 05, 2013 1:22 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

At the MQI level, the MQCONNX verb allows a connect request to create an
hConn that can be used under multiple threads.
The
MQCNO_HANDLE_SHARE_BLOCK/MQCNO_HANDLE_SHARE_NO_BLOCK/MQCNO_HANDLE_SHARE_NONE
options control what type of connection is created, whether the hConn is
only valid under the thread that created it, and the behavior when
multiple concurrent MQI requests are made on the same hConn. Under the
covers it's not possible for multiple concurrent MQI requests to actually
be processed in parallel, however the queue manager can serialize multiple
concurrent request when MQCNO_HANDLE_SHARE_BLOCK is specified.

From: Brumbaugh Glen <glen.brumbaugh-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 05/08/2013 19:07
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Tim,

The MQI calls are "Single Threaded" through the one MQConn handle. Thus,
there may only be one current API call at a time. There is no
requirement, other than common sense and/or good design, that a single WMQ
handle cannot be shared between multiple threads. If this were to be
done, however, the individual threads would have to implement some kind of
locking mechanism to serialize their parallel access of a serial resource.
A singleton Java class, for instance, could provide the necessary
serialization. From the description of the developer's input, the
implementation does not seem to be this sophisticated, but it could be.

HTH.

Regards,

Glen Brumbaugh
Prolifics

On Aug 5, 2013, at 1:44 PM, Raul Acevedo <acevedor-rIXRsD/***@public.gmane.org> wrote:
Tim,

You are correct. Each thread has its own connection.

Raúl L. Acevedo
Senior IT Architect
IBM Global Business Services
Application Innovation Services (AIS)
818 599 6626 mobile
acevedor-r/Jw6+rmf7HQT0dZR+***@public.gmane.org email

<graycol.gif>Tim Zielke ---08/05/2013 01:33:33 PM---Hello, Normally, I
would try to research this type of question more, but I am pressed for
time this

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 08/05/2013 01:33 PM
Subject: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

Hello,

Normally, I would try to research this type of question more, but I am
pressed for time this week and hoping someone on the list might know off
of the top of their head.

The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java
developer who is saying that his multi-threaded java code does a connect
and open of a queue under thread 1, and then threads 2-6 come along and do
gets from the queue. Threads 2-6 have not done a connect or open on the
queue before issuing the get, according to the developer. I was under the
impression that each thread would need to separately connect and open the
queue, before it could do a get. Am I mistaken?

Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Tim Zielke

2013-10-04 18:54:48 UTC

Hello MQLIST,

Here is another example of MQI behavior that is confusing me. This was run on a 7.1.0.2 queue manager on Solaris 10. In this case the application had registered multiple consumer functions. You can see that the MQGET << (GET end) are not being serialized and running in parallel for 5 different threads, at least that is how it looks to me. This seems odd and also seems to contradict the statement previously in this thread "Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel". It looks like these MQGET ends are running in parallel to me.

Am I misunderstanding something here?

Does anyone have any comments to clear up my confusion?

Thanks,
Tim

WebSphere MQ Formatted Trace - Formatter V3

+-----------------------------------------------------------------------+
| |
| WebSphere MQ Formatted Trace V3 |
| =============================== |
| |
| Date/Time :- 09/06/13 07:35:32 CST |
| UTC Time :- 1378470932.076600 |
| UTC Time Offset :- 5 (CST) |
| Host Name :- xxxxxxxx |
| Operating System :- SunOS 5.10 |
| LVLS :- 7.1.0.2 |
| Product Long Name :- WebSphere MQ for Solaris (SPARC platform) |
| CMVC Level :- p710-002-121018 |
| Installation Path :- /opt/mqm |
| Installation Name :- Installation1 (1) |
| Effective UserID :- 101 (wsphere) |
| Real UserID :- 101 (wsphere) |
| Program Name :- java |
| Addressing Mode :- 64-bit |
| Process :- 4822 |
| QueueManager :- |
| Reentrant :- 1 |
| |
+-----------------------------------------------------------------------+

Formatting options: None
Formatter installation path: /opt/mqm
Formatter version: 7.1.0.2

Timestamp Process.Thread Trace Ident Trace Data
===========================================================
*07:47:04.101935 4822.16 CONN:1400010 __________
07:47:04.101935 4822.10 CONN:140000a __________
07:47:04.102778 4822.16 CONN:1400010 MQGET <<
*07:47:04.102302 4822.6 CONN:1400006 __________
*07:47:04.101958 4822.12 CONN:140000c __________
07:47:04.102820 4822.16 CONN:1400010 Hconn : Input Parm
07:47:04.102871 4822.12 CONN:140000c MQGET <<
*07:47:04.102840 4822.6 CONN:1400006 MQGET <<
*07:47:04.102800 4822.10 CONN:140000a MQGET <<
07:47:04.102925 4822.6 CONN:1400006 Hconn : Input Parm
07:47:04.102946 4822.10 CONN:140000a Hconn : Input Parm
*07:47:04.102903 4822.12 CONN:140000c Hconn : Input Parm
07:47:04.102998 4822.8 CONN:1400008 __________
*07:47:04.102884 4822.16 CONN:1400010 Hconn:
07:47:04.102982 4822.10 CONN:140000a Hconn:
07:47:04.103058 4822.16 CONN:1400010 0x0000: 01400010 |***@.. |
*07:47:04.103007 4822.12 CONN:140000c Hconn:
07:47:04.103080 4822.10 CONN:140000a 0x0000: 0140000a |***@. |
*07:47:04.103031 4822.8 CONN:1400008 MQGET <<
07:47:04.103151 4822.10 CONN:140000a CbContext:
*07:47:04.103095 4822.16 CONN:1400010 CbContext:
07:47:04.103207 4822.10 CONN:140000a 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.103207 4822.10 CONN:140000a 0x0010: 00000001 02f02b70 00000000 00000000 |......+p........|
07:47:04.103207 4822.10 CONN:140000a 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.103207 4822.10 CONN:140000a 0x0030: 00000000 00000000 00000000 00000000 |................|
*07:47:04.103127 4822.12 CONN:140000c 0x0000: 0140000c |***@. |
*07:47:04.102961 4822.6 CONN:1400006 Hconn:
07:47:04.103224 4822.16 CONN:1400010 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.103224 4822.16 CONN:1400010 0x0010: 00000001 01263420 00000000 00000000 |.....&4 ........|
07:47:04.103224 4822.16 CONN:1400010 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.103224 4822.16 CONN:1400010 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103225 4822.14 CONN:140000e __________
07:47:04.103255 4822.10 CONN:140000a Msgdesc:
07:47:04.103374 4822.14 CONN:140000e MQGET <<
*07:47:04.103348 4822.16 CONN:1400010 Msgdesc:
*07:47:04.103287 4822.12 CONN:140000c CbContext:
07:47:04.103395 4822.10 CONN:140000a 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.103395 4822.10 CONN:140000a 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.103395 4822.10 CONN:140000a 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.103395 4822.10 CONN:140000a 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103395 4822.10 CONN:140000a 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.103395 4822.10 CONN:140000a 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.103395 4822.10 CONN:140000a 0x0160: 00000000 00000000 ffffffff |............ |
*07:47:04.103326 4822.6 CONN:1400006 0x0000: 01400006 |***@.. |
*07:47:04.103176 4822.8 CONN:1400008 Hconn : Input Parm
07:47:04.103513 4822.6 CONN:1400006 CbContext:
07:47:04.103537 4822.8 CONN:1400008 Hconn:
*07:47:04.103469 4822.12 CONN:140000c 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.103469 4822.12 CONN:140000c 0x0010: 00000001 03808240 00000000 00000000 |***@........|
07:47:04.103469 4822.12 CONN:140000c 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.103469 4822.12 CONN:140000c 0x0030: 00000000 00000000 00000000 00000000 |................|
*07:47:04.103449 4822.16 CONN:1400010 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.103449 4822.16 CONN:1400010 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.103449 4822.16 CONN:1400010 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.103449 4822.16 CONN:1400010 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103449 4822.16 CONN:1400010 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.103449 4822.16 CONN:1400010 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.103449 4822.16 CONN:1400010 0x0160: 00000000 00000000 ffffffff |............ |
*07:47:04.103424 4822.14 CONN:140000e Hconn : Input Parm
07:47:04.103557 4822.6 CONN:1400006 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.103557 4822.6 CONN:1400006 0x0010: 00000001 00f58a20 00000000 00000000 |....... ........|
07:47:04.103557 4822.6 CONN:1400006 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.103557 4822.6 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
*07:47:04.103490 4822.10 CONN:140000a Bufferlength:
07:47:04.103584 4822.8 CONN:1400008 0x0000: 01400008 |***@.. |
07:47:04.103652 4822.16 CONN:1400010 Bufferlength:
07:47:04.103762 4822.8 CONN:1400008 CbContext:
*07:47:04.103711 4822.6 CONN:1400006 Msgdesc:
07:47:04.103817 4822.8 CONN:1400008 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.103817 4822.8 CONN:1400008 0x0010: 00000001 01511c60 00000000 00000000 |.....Q.`........|
07:47:04.103817 4822.8 CONN:1400008 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.103817 4822.8 CONN:1400008 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103838 4822.6 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.103838 4822.6 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.103838 4822.6 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.103838 4822.6 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103838 4822.6 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.103838 4822.6 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.103838 4822.6 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
*07:47:04.103731 4822.10 CONN:140000a 0x0000: 00002000 |.. . |
*07:47:04.103619 4822.12 CONN:140000c Msgdesc:
07:47:04.103901 4822.6 CONN:1400006 Bufferlength:
*07:47:04.103685 4822.14 CONN:140000e Hconn:
07:47:04.103986 4822.6 CONN:1400006 0x0000: 00002000 |.. . |
*07:47:04.103859 4822.8 CONN:1400008 Msgdesc:
07:47:04.104040 4822.6 CONN:1400006 Datalength:
*07:47:04.103929 4822.10 CONN:140000a Datalength:
07:47:04.104008 4822.14 CONN:140000e 0x0000: 0140000e |***@.. |
07:47:04.104078 4822.8 CONN:1400008 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.104078 4822.8 CONN:1400008 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.104078 4822.8 CONN:1400008 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.104078 4822.8 CONN:1400008 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.104078 4822.8 CONN:1400008 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.104078 4822.8 CONN:1400008 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.104078 4822.8 CONN:1400008 0x0160: 00000000 00000000 ffffffff |............ |
07:47:04.104135 4822.10 CONN:140000a 0x0000: 00000000 |.... |
07:47:04.104192 4822.8 CONN:1400008 Bufferlength:
*07:47:04.104103 4822.6 CONN:1400006 0x0000: 00000000 |.... |
07:47:04.104156 4822.14 CONN:140000e CbContext:
*07:47:04.103783 4822.16 CONN:1400010 0x0000: 00002000 |.. . |
07:47:04.104274 4822.6 CONN:1400006 Compcode:
07:47:04.104372 4822.16 CONN:1400010 Datalength:
*07:47:04.104210 4822.10 CONN:140000a Compcode:
*07:47:04.103966 4822.12 CONN:140000c 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.103966 4822.12 CONN:140000c 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.103966 4822.12 CONN:140000c 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.103966 4822.12 CONN:140000c 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103966 4822.12 CONN:140000c 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.103966 4822.12 CONN:140000c 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.103966 4822.12 CONN:140000c 0x0160: 00000000 00000000 ffffffff |............ |
07:47:04.104397 4822.6 CONN:1400006 0x0000: 00000002 |.... |
07:47:04.104486 4822.12 CONN:140000c Bufferlength:
*07:47:04.104455 4822.10 CONN:140000a 0x0000: 00000002 |.... |
*07:47:04.104427 4822.16 CONN:1400010 0x0000: 00000000 |.... |
*07:47:04.104251 4822.8 CONN:1400008 0x0000: 00002000 |.. . |
07:47:04.104334 4822.14 CONN:140000e 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.104334 4822.14 CONN:140000e 0x0010: 00000001 01b19d60 00000000 00000000 |.......`........|
07:47:04.104334 4822.14 CONN:140000e 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.104334 4822.14 CONN:140000e 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.104636 4822.8 CONN:1400008 Datalength:
*07:47:04.104571 4822.10 CONN:140000a Reason:
07:47:04.104657 4822.14 CONN:140000e Msgdesc:
*07:47:04.104536 4822.12 CONN:140000c 0x0000: 00002000 |.. . |
07:47:04.104605 4822.16 CONN:1400010 Compcode:
07:47:04.104750 4822.14 CONN:140000e 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.104750 4822.14 CONN:140000e 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.104750 4822.14 CONN:140000e 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.104750 4822.14 CONN:140000e 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.104750 4822.14 CONN:140000e 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.104750 4822.14 CONN:140000e 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.104750 4822.14 CONN:140000e 0x0160: 00000000 00000000 ffffffff |............ |
*07:47:04.104680 4822.8 CONN:1400008 0x0000: 00000000 |.... |
07:47:04.104769 4822.12 CONN:140000c Datalength:
07:47:04.104832 4822.14 CONN:140000e Bufferlength:
*07:47:04.104714 4822.10 CONN:140000a 0x0000: 00007811 |..x. |
07:47:04.104801 4822.16 CONN:1400010 0x0000: 00000002 |.... |
07:47:04.104854 4822.8 CONN:1400008 Compcode:
07:47:04.104977 4822.16 CONN:1400010 Reason:
*07:47:04.104882 4822.12 CONN:140000c 0x0000: 00000000 |.... |
07:47:04.104914 4822.14 CONN:140000e 0x0000: 00002000 |.. . |
*07:47:04.104508 4822.6 CONN:1400006 Reason:
07:47:04.105042 4822.12 CONN:140000c Compcode:
*07:47:04.104994 4822.8 CONN:1400008 0x0000: 00000002 |.... |
07:47:04.105099 4822.6 CONN:1400006 0x0000: 00007811 |..x. |
*07:47:04.105072 4822.14 CONN:140000e Datalength:
07:47:04.105118 4822.12 CONN:140000c 0x0000: 00000002 |.... |
07:47:04.105147 4822.8 CONN:1400008 Reason:
07:47:04.105201 4822.14 CONN:140000e 0x0000: 00000000 |.... |
07:47:04.105223 4822.12 CONN:140000c Reason:
07:47:04.105248 4822.8 CONN:1400008 0x0000: 00007811 |..x. |
07:47:04.105273 4822.14 CONN:140000e Compcode:
07:47:04.105290 4822.12 CONN:140000c 0x0000: 00007811 |..x. |
07:47:04.105331 4822.14 CONN:140000e 0x0000: 00000002 |.... |
07:47:04.105372 4822.14 CONN:140000e Reason:
07:47:04.105396 4822.14 CONN:140000e 0x0000: 00007811 |..x. |
*07:47:04.105019 4822.16 CONN:1400010 0x0000: 00007811 |..x. |
===========================================================

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, September 18, 2013 1:08 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

In order to be useful an MQCTL with MQOP_STOP/MQOP_SUSPEND has to be able to run while the hConn is 'in use' by an async consume thread and so the behavior of MQCTL is slightly different than for other MQI calls.
The snippet of trace provided here is too short for me to be able to see exactly what is going on. I don't believe MQCTL is intended to interact directly with MQGET (as opposed to an 'MQGET' issued on behalf of callback) and the trace is too short for me to see the context of either the MQGET oir the MQCTL calls.

sorry
Andy.

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 18/09/2013 14:58
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
________________________________

Hi Andy,

I had one follow up on this thread.

For the most part in an API trace of a multi-threaded application, I see the behavior you mentioned below where the API (begins and ends) are serialized and only one API begin or end is running in the trace. However, for the case listed below where managed call backs are being used, I see an MQCTL end and MQGET begin running in what looks like a parallel fashion. I also see this behavior happening consistently in the trace.

Would the MQCTL end and MQGET begin (the MQGET that would run asynchronously on the MQ managed call back thread) be a case where two API calls could run in parallel?

I have listed an example of what I am seeing in the trace below. You can see the MQCTL end running on thread 2 and the MQGET begin running on thread 5 running in what appears to be parallel fashion.

This managed call back was set up so that an MQGET of 2033 would be issued immediately to the consumer function once the managed call back was activated and if no message was available on the queue.

This trace was run on a 7.1.0.2 Solaris 10 queue manager.

08:02:21.402789 554.2 CONN:1400006 __________
08:02:21.402832 554.2 CONN:1400006 MQCTL <<
*08:02:21.402797 554.5 CONN:1400006 __________
08:02:21.402856 554.2 CONN:1400006 Hconn : Input Parm
08:02:21.402882 554.5 CONN:1400006 MQGET >>
08:02:21.402905 554.2 CONN:1400006 Operation : Input Parm
08:02:21.402929 554.5 CONN:1400006 Hconn:
08:02:21.402952 554.2 CONN:1400006 CtlOpts:
08:02:21.402978 554.5 CONN:1400006 0x0000: 01400006 |***@.. |
08:02:21.403025 554.5 CONN:1400006 Msgdesc:
*08:02:21.402999 554.2 CONN:1400006 0x0000: 43544c4f 00000001 00000000 ffffffff |CTLO............|
08:02:21.402999 554.2 CONN:1400006 0x0010: 00000000 00000000 |........ |
08:02:21.403049 554.5 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
08:02:21.403049 554.5 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
08:02:21.403049 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
08:02:21.403049 554.5 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
08:02:21.403049 554.5 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
08:02:21.403071 554.2 CONN:1400006 Compcode:
08:02:21.403093 554.5 CONN:1400006 Bufferlength:
08:02:21.403115 554.2 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403166 554.2 CONN:1400006 Reason:
*08:02:21.403140 554.5 CONN:1400006 0x0000: 00002000 |.. . |
08:02:21.403191 554.2 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403212 554.5 CONN:1400006 Buffer : Output Parm
08:02:21.403259 554.5 CONN:1400006 Datalength : Output Parm
08:02:21.403277 554.5 CONN:1400006 Compcode : Output Parm
08:02:21.403293 554.5 CONN:1400006 Reason : Output Parm
08:02:21.403615 554.5 CONN:1400006 __________
08:02:21.403639 554.5 CONN:1400006 MQGET <<
08:02:21.403656 554.5 CONN:1400006 Hconn : Input Parm
08:02:21.403674 554.5 CONN:1400006 Hconn:
08:02:21.403692 554.5 CONN:1400006 0x0000: 01400006 |***@.. |
08:02:21.403709 554.5 CONN:1400006 CbContext:
08:02:21.403726 554.5 CONN:1400006 0x0000: ffffffff 26c3f221 ffffffff 00000002 |....&..!........|
08:02:21.403726 554.5 CONN:1400006 0x0010: 00000000 00000000 00000000 00000000 |................|
08:02:21.403726 554.5 CONN:1400006 0x0020: 00000001 02b42d50 00000000 00000000 |......-P........|
08:02:21.403726 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403743 554.5 CONN:1400006 Msgdesc:
08:02:21.403762 554.5 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
08:02:21.403762 554.5 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
08:02:21.403762 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
08:02:21.403762 554.5 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
08:02:21.403762 554.5 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
08:02:21.403782 554.5 CONN:1400006 Bufferlength:
08:02:21.403799 554.5 CONN:1400006 0x0000: 00002000 |.. . |
08:02:21.403816 554.5 CONN:1400006 Datalength:
08:02:21.403834 554.5 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403850 554.5 CONN:1400006 Compcode:
08:02:21.403865 554.5 CONN:1400006 0x0000: 00000002 |.... |
08:02:21.403880 554.5 CONN:1400006 Reason:
08:02:21.403897 554.5 CONN:1400006 0x0000: 000007f1 |.... |
08:02:21.426780 554.5 CONN:1400006 __________

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Monday, August 05, 2013 1:22 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

At the MQI level, the MQCONNX verb allows a connect request to create an hConn that can be used under multiple threads.
The MQCNO_HANDLE_SHARE_BLOCK/MQCNO_HANDLE_SHARE_NO_BLOCK/MQCNO_HANDLE_SHARE_NONE options control what type of connection is created, whether the hConn is only valid under the thread that created it, and the behavior when multiple concurrent MQI requests are made on the same hConn. Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel, however the queue manager can serialize multiple concurrent request when MQCNO_HANDLE_SHARE_BLOCK is specified.

From: Brumbaugh Glen <glen.brumbaugh-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 05/08/2013 19:07
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

________________________________

Tim,

The MQI calls are "Single Threaded" through the one MQConn handle. Thus, there may only be one current API call at a time. There is no requirement, other than common sense and/or good design, that a single WMQ handle cannot be shared between multiple threads. If this were to be done, however, the individual threads would have to implement some kind of locking mechanism to serialize their parallel access of a serial resource. A singleton Java class, for instance, could provide the necessary serialization. From the description of the developer's input, the implementation does not seem to be this sophisticated, but it could be.

HTH.

Regards,

Glen Brumbaugh
Prolifics

On Aug 5, 2013, at 1:44 PM, Raul Acevedo <acevedor-rIXRsD/***@public.gmane.org<mailto:acevedor-rIXRsD/***@public.gmane.org>> wrote:

Tim,

You are correct. Each thread has its own connection.

Raúl L. Acevedo
Senior IT Architect
IBM Global Business Services
Application Innovation Services (AIS)
818 599 6626 mobile
acevedor-r/Jw6+rmf7HQT0dZR+***@public.gmane.org<mailto:acevedor-r/Jw6+rmf7HQT0dZR+***@public.gmane.org> email

<graycol.gif>Tim Zielke ---08/05/2013 01:33:33 PM---Hello, Normally, I would try to research this type of question more, but I am pressed for time this

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:tim.zielke-PR+tvw7B/***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+***@public.gmane.orgac.at>,
Date: 08/05/2013 01:33 PM
Subject: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:***@listserv.meduniwien.ac.at>>

________________________________

Hello,

Normally, I would try to research this type of question more, but I am pressed for time this week and hoping someone on the list might know off of the top of their head.

The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java developer who is saying that his multi-threaded java code does a connect and open of a queue under thread 1, and then threads 2-6 come along and do gets from the queue. Threads 2-6 have not done a connect or open on the queue before issuing the get, according to the developer. I was under the impression that each thread would need to separately connect and open the queue, before it could do a get. Am I mistaken?

Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Paul Clarke

2013-10-04 19:22:00 UTC

Iâm not that familiar with the Java trace format but is it possible that there are 5 different connections here ? If you have different connections then there would be no serialisation.
Even if you were using one connection then just showing the MQGET functions calls and the return may not be sufficient to show you the serialisation call itself, it depends entirely on where that serialisation takes place. In other words, you could indeed see 5 threads each entering MQGET for the same connection and calling a number of functions before deciding that they do indeed contend with each other. At which point I would expect you to see only one of the threads proceed.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: Tim Zielke
Sent: Friday, October 04, 2013 7:54 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

Hello MQLIST,

Here is another example of MQI behavior that is confusing me. This was run on a 7.1.0.2 queue manager on Solaris 10. In this case the application had registered multiple consumer functions. You can see that the MQGET << (GET end) are not being serialized and running in parallel for 5 different threads, at least that is how it looks to me. This seems odd and also seems to contradict the statement previously in this thread "Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel". It looks like these MQGET ends are running in parallel to me.

Am I misunderstanding something here?

Does anyone have any comments to clear up my confusion?

Thanks,

Tim

WebSphere MQ Formatted Trace - Formatter V3

+-----------------------------------------------------------------------+

| |

| WebSphere MQ Formatted Trace V3 |

| =============================== |

| |

| Date/Time :- 09/06/13 07:35:32 CST |

| UTC Time :- 1378470932.076600 |

| UTC Time Offset :- 5 (CST) |

| Host Name :- xxxxxxxx |

| Operating System :- SunOS 5.10 |

| LVLS :- 7.1.0.2 |

| Product Long Name :- WebSphere MQ for Solaris (SPARC platform) |

| CMVC Level :- p710-002-121018 |

| Installation Path :- /opt/mqm |

| Installation Name :- Installation1 (1) |

| Effective UserID :- 101 (wsphere) |

| Real UserID :- 101 (wsphere) |

| Program Name :- java |

| Addressing Mode :- 64-bit |

| Process :- 4822 |

| QueueManager :- |

| Reentrant :- 1 |

| |

+-----------------------------------------------------------------------+

Formatting options: None

Formatter installation path: /opt/mqm

Formatter version: 7.1.0.2

Timestamp Process.Thread Trace Ident Trace Data

===========================================================

*07:47:04.101935 4822.16 CONN:1400010 __________

07:47:04.101935 4822.10 CONN:140000a __________

07:47:04.102778 4822.16 CONN:1400010 MQGET <<

*07:47:04.102302 4822.6 CONN:1400006 __________

*07:47:04.101958 4822.12 CONN:140000c __________

07:47:04.102820 4822.16 CONN:1400010 Hconn : Input Parm

07:47:04.102871 4822.12 CONN:140000c MQGET <<

*07:47:04.102840 4822.6 CONN:1400006 MQGET <<

*07:47:04.102800 4822.10 CONN:140000a MQGET <<

07:47:04.102925 4822.6 CONN:1400006 Hconn : Input Parm

07:47:04.102946 4822.10 CONN:140000a Hconn : Input Parm

*07:47:04.102903 4822.12 CONN:140000c Hconn : Input Parm

07:47:04.102998 4822.8 CONN:1400008 __________

*07:47:04.102884 4822.16 CONN:1400010 Hconn:

07:47:04.102982 4822.10 CONN:140000a Hconn:

07:47:04.103058 4822.16 CONN:1400010 0x0000: 01400010 |***@.. |

*07:47:04.103007 4822.12 CONN:140000c Hconn:

07:47:04.103080 4822.10 CONN:140000a 0x0000: 0140000a |***@. |

*07:47:04.103031 4822.8 CONN:1400008 MQGET <<

07:47:04.103151 4822.10 CONN:140000a CbContext:

*07:47:04.103095 4822.16 CONN:1400010 CbContext:

07:47:04.103207 4822.10 CONN:140000a 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.103207 4822.10 CONN:140000a 0x0010: 00000001 02f02b70 00000000 00000000 |......+p........|

07:47:04.103207 4822.10 CONN:140000a 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.103207 4822.10 CONN:140000a 0x0030: 00000000 00000000 00000000 00000000 |................|

*07:47:04.103127 4822.12 CONN:140000c 0x0000: 0140000c |***@. |

*07:47:04.102961 4822.6 CONN:1400006 Hconn:

07:47:04.103224 4822.16 CONN:1400010 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.103224 4822.16 CONN:1400010 0x0010: 00000001 01263420 00000000 00000000 |.....&4 ........|

07:47:04.103224 4822.16 CONN:1400010 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.103224 4822.16 CONN:1400010 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103225 4822.14 CONN:140000e __________

07:47:04.103255 4822.10 CONN:140000a Msgdesc:

07:47:04.103374 4822.14 CONN:140000e MQGET <<

*07:47:04.103348 4822.16 CONN:1400010 Msgdesc:

*07:47:04.103287 4822.12 CONN:140000c CbContext:

07:47:04.103395 4822.10 CONN:140000a 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.103395 4822.10 CONN:140000a 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.103395 4822.10 CONN:140000a 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.103395 4822.10 CONN:140000a 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103395 4822.10 CONN:140000a 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.103395 4822.10 CONN:140000a 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.103395 4822.10 CONN:140000a 0x0160: 00000000 00000000 ffffffff |............ |

*07:47:04.103326 4822.6 CONN:1400006 0x0000: 01400006 |***@.. |

*07:47:04.103176 4822.8 CONN:1400008 Hconn : Input Parm

07:47:04.103513 4822.6 CONN:1400006 CbContext:

07:47:04.103537 4822.8 CONN:1400008 Hconn:

*07:47:04.103469 4822.12 CONN:140000c 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.103469 4822.12 CONN:140000c 0x0010: 00000001 03808240 00000000 00000000 |***@........|

07:47:04.103469 4822.12 CONN:140000c 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.103469 4822.12 CONN:140000c 0x0030: 00000000 00000000 00000000 00000000 |................|

*07:47:04.103449 4822.16 CONN:1400010 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.103449 4822.16 CONN:1400010 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.103449 4822.16 CONN:1400010 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.103449 4822.16 CONN:1400010 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103449 4822.16 CONN:1400010 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.103449 4822.16 CONN:1400010 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.103449 4822.16 CONN:1400010 0x0160: 00000000 00000000 ffffffff |............ |

*07:47:04.103424 4822.14 CONN:140000e Hconn : Input Parm

07:47:04.103557 4822.6 CONN:1400006 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.103557 4822.6 CONN:1400006 0x0010: 00000001 00f58a20 00000000 00000000 |....... ........|

07:47:04.103557 4822.6 CONN:1400006 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.103557 4822.6 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|

*07:47:04.103490 4822.10 CONN:140000a Bufferlength:

07:47:04.103584 4822.8 CONN:1400008 0x0000: 01400008 |***@.. |

07:47:04.103652 4822.16 CONN:1400010 Bufferlength:

07:47:04.103762 4822.8 CONN:1400008 CbContext:

*07:47:04.103711 4822.6 CONN:1400006 Msgdesc:

07:47:04.103817 4822.8 CONN:1400008 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.103817 4822.8 CONN:1400008 0x0010: 00000001 01511c60 00000000 00000000 |.....Q.`........|

07:47:04.103817 4822.8 CONN:1400008 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.103817 4822.8 CONN:1400008 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103838 4822.6 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.103838 4822.6 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.103838 4822.6 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.103838 4822.6 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103838 4822.6 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.103838 4822.6 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.103838 4822.6 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |

*07:47:04.103731 4822.10 CONN:140000a 0x0000: 00002000 |.. . |

*07:47:04.103619 4822.12 CONN:140000c Msgdesc:

07:47:04.103901 4822.6 CONN:1400006 Bufferlength:

*07:47:04.103685 4822.14 CONN:140000e Hconn:

07:47:04.103986 4822.6 CONN:1400006 0x0000: 00002000 |.. . |

*07:47:04.103859 4822.8 CONN:1400008 Msgdesc:

07:47:04.104040 4822.6 CONN:1400006 Datalength:

*07:47:04.103929 4822.10 CONN:140000a Datalength:

07:47:04.104008 4822.14 CONN:140000e 0x0000: 0140000e |***@.. |

07:47:04.104078 4822.8 CONN:1400008 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.104078 4822.8 CONN:1400008 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.104078 4822.8 CONN:1400008 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.104078 4822.8 CONN:1400008 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.104078 4822.8 CONN:1400008 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.104078 4822.8 CONN:1400008 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.104078 4822.8 CONN:1400008 0x0160: 00000000 00000000 ffffffff |............ |

07:47:04.104135 4822.10 CONN:140000a 0x0000: 00000000 |.... |

07:47:04.104192 4822.8 CONN:1400008 Bufferlength:

*07:47:04.104103 4822.6 CONN:1400006 0x0000: 00000000 |.... |

07:47:04.104156 4822.14 CONN:140000e CbContext:

*07:47:04.103783 4822.16 CONN:1400010 0x0000: 00002000 |.. . |

07:47:04.104274 4822.6 CONN:1400006 Compcode:

07:47:04.104372 4822.16 CONN:1400010 Datalength:

*07:47:04.104210 4822.10 CONN:140000a Compcode:

*07:47:04.103966 4822.12 CONN:140000c 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.103966 4822.12 CONN:140000c 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.103966 4822.12 CONN:140000c 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.103966 4822.12 CONN:140000c 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103966 4822.12 CONN:140000c 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.103966 4822.12 CONN:140000c 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.103966 4822.12 CONN:140000c 0x0160: 00000000 00000000 ffffffff |............ |

07:47:04.104397 4822.6 CONN:1400006 0x0000: 00000002 |.... |

07:47:04.104486 4822.12 CONN:140000c Bufferlength:

*07:47:04.104455 4822.10 CONN:140000a 0x0000: 00000002 |.... |

*07:47:04.104427 4822.16 CONN:1400010 0x0000: 00000000 |.... |

*07:47:04.104251 4822.8 CONN:1400008 0x0000: 00002000 |.. . |

07:47:04.104334 4822.14 CONN:140000e 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.104334 4822.14 CONN:140000e 0x0010: 00000001 01b19d60 00000000 00000000 |.......`........|

07:47:04.104334 4822.14 CONN:140000e 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.104334 4822.14 CONN:140000e 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.104636 4822.8 CONN:1400008 Datalength:

*07:47:04.104571 4822.10 CONN:140000a Reason:

07:47:04.104657 4822.14 CONN:140000e Msgdesc:

*07:47:04.104536 4822.12 CONN:140000c 0x0000: 00002000 |.. . |

07:47:04.104605 4822.16 CONN:1400010 Compcode:

07:47:04.104750 4822.14 CONN:140000e 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.104750 4822.14 CONN:140000e 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.104750 4822.14 CONN:140000e 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.104750 4822.14 CONN:140000e 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.104750 4822.14 CONN:140000e 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.104750 4822.14 CONN:140000e 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.104750 4822.14 CONN:140000e 0x0160: 00000000 00000000 ffffffff |............ |

*07:47:04.104680 4822.8 CONN:1400008 0x0000: 00000000 |.... |

07:47:04.104769 4822.12 CONN:140000c Datalength:

07:47:04.104832 4822.14 CONN:140000e Bufferlength:

*07:47:04.104714 4822.10 CONN:140000a 0x0000: 00007811 |..x. |

07:47:04.104801 4822.16 CONN:1400010 0x0000: 00000002 |.... |

07:47:04.104854 4822.8 CONN:1400008 Compcode:

07:47:04.104977 4822.16 CONN:1400010 Reason:

*07:47:04.104882 4822.12 CONN:140000c 0x0000: 00000000 |.... |

07:47:04.104914 4822.14 CONN:140000e 0x0000: 00002000 |.. . |

*07:47:04.104508 4822.6 CONN:1400006 Reason:

07:47:04.105042 4822.12 CONN:140000c Compcode:

*07:47:04.104994 4822.8 CONN:1400008 0x0000: 00000002 |.... |

07:47:04.105099 4822.6 CONN:1400006 0x0000: 00007811 |..x. |

*07:47:04.105072 4822.14 CONN:140000e Datalength:

07:47:04.105118 4822.12 CONN:140000c 0x0000: 00000002 |.... |

07:47:04.105147 4822.8 CONN:1400008 Reason:

07:47:04.105201 4822.14 CONN:140000e 0x0000: 00000000 |.... |

07:47:04.105223 4822.12 CONN:140000c Reason:

07:47:04.105248 4822.8 CONN:1400008 0x0000: 00007811 |..x. |

07:47:04.105273 4822.14 CONN:140000e Compcode:

07:47:04.105290 4822.12 CONN:140000c 0x0000: 00007811 |..x. |

07:47:04.105331 4822.14 CONN:140000e 0x0000: 00000002 |.... |

07:47:04.105372 4822.14 CONN:140000e Reason:

07:47:04.105396 4822.14 CONN:140000e 0x0000: 00007811 |..x. |

*07:47:04.105019 4822.16 CONN:1400010 0x0000: 00007811 |..x. |

===========================================================

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, September 18, 2013 1:08 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

In order to be useful an MQCTL with MQOP_STOP/MQOP_SUSPEND has to be able to run while the hConn is 'in use' by an async consume thread and so the behavior of MQCTL is slightly different than for other MQI calls.
The snippet of trace provided here is too short for me to be able to see exactly what is going on. I don't believe MQCTL is intended to interact directly with MQGET (as opposed to an 'MQGET' issued on behalf of callback) and the trace is too short for me to see the context of either the MQGET oir the MQCTL calls.

sorry
Andy.

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 18/09/2013 14:58
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

--------------------------------------------------------------------------------

Hi Andy,

I had one follow up on this thread.

For the most part in an API trace of a multi-threaded application, I see the behavior you mentioned below where the API (begins and ends) are serialized and only one API begin or end is running in the trace. However, for the case listed below where managed call backs are being used, I see an MQCTL end and MQGET begin running in what looks like a parallel fashion. I also see this behavior happening consistently in the trace.

Would the MQCTL end and MQGET begin (the MQGET that would run asynchronously on the MQ managed call back thread) be a case where two API calls could run in parallel?

I have listed an example of what I am seeing in the trace below. You can see the MQCTL end running on thread 2 and the MQGET begin running on thread 5 running in what appears to be parallel fashion.

This managed call back was set up so that an MQGET of 2033 would be issued immediately to the consumer function once the managed call back was activated and if no message was available on the queue.

This trace was run on a 7.1.0.2 Solaris 10 queue manager.

08:02:21.402789 554.2 CONN:1400006 __________
08:02:21.402832 554.2 CONN:1400006 MQCTL <<
*08:02:21.402797 554.5 CONN:1400006 __________
08:02:21.402856 554.2 CONN:1400006 Hconn : Input Parm
08:02:21.402882 554.5 CONN:1400006 MQGET >>
08:02:21.402905 554.2 CONN:1400006 Operation : Input Parm
08:02:21.402929 554.5 CONN:1400006 Hconn:
08:02:21.402952 554.2 CONN:1400006 CtlOpts:
08:02:21.402978 554.5 CONN:1400006 0x0000: 01400006 |***@.. |
08:02:21.403025 554.5 CONN:1400006 Msgdesc:
*08:02:21.402999 554.2 CONN:1400006 0x0000: 43544c4f 00000001 00000000 ffffffff |CTLO............|
08:02:21.402999 554.2 CONN:1400006 0x0010: 00000000 00000000 |........ |
08:02:21.403049 554.5 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
08:02:21.403049 554.5 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
08:02:21.403049 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
08:02:21.403049 554.5 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
08:02:21.403049 554.5 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
08:02:21.403071 554.2 CONN:1400006 Compcode:
08:02:21.403093 554.5 CONN:1400006 Bufferlength:
08:02:21.403115 554.2 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403166 554.2 CONN:1400006 Reason:
*08:02:21.403140 554.5 CONN:1400006 0x0000: 00002000 |.. . |
08:02:21.403191 554.2 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403212 554.5 CONN:1400006 Buffer : Output Parm
08:02:21.403259 554.5 CONN:1400006 Datalength : Output Parm
08:02:21.403277 554.5 CONN:1400006 Compcode : Output Parm
08:02:21.403293 554.5 CONN:1400006 Reason : Output Parm
08:02:21.403615 554.5 CONN:1400006 __________
08:02:21.403639 554.5 CONN:1400006 MQGET <<
08:02:21.403656 554.5 CONN:1400006 Hconn : Input Parm
08:02:21.403674 554.5 CONN:1400006 Hconn:
08:02:21.403692 554.5 CONN:1400006 0x0000: 01400006 |***@.. |
08:02:21.403709 554.5 CONN:1400006 CbContext:
08:02:21.403726 554.5 CONN:1400006 0x0000: ffffffff 26c3f221 ffffffff 00000002 |....&..!........|
08:02:21.403726 554.5 CONN:1400006 0x0010: 00000000 00000000 00000000 00000000 |................|
08:02:21.403726 554.5 CONN:1400006 0x0020: 00000001 02b42d50 00000000 00000000 |......-P........|
08:02:21.403726 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403743 554.5 CONN:1400006 Msgdesc:
08:02:21.403762 554.5 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
08:02:21.403762 554.5 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
08:02:21.403762 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
08:02:21.403762 554.5 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
08:02:21.403762 554.5 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
08:02:21.403782 554.5 CONN:1400006 Bufferlength:
08:02:21.403799 554.5 CONN:1400006 0x0000: 00002000 |.. . |
08:02:21.403816 554.5 CONN:1400006 Datalength:
08:02:21.403834 554.5 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403850 554.5 CONN:1400006 Compcode:
08:02:21.403865 554.5 CONN:1400006 0x0000: 00000002 |.... |
08:02:21.403880 554.5 CONN:1400006 Reason:
08:02:21.403897 554.5 CONN:1400006 0x0000: 000007f1 |.... |
08:02:21.426780 554.5 CONN:1400006 __________

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Monday, August 05, 2013 1:22 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

At the MQI level, the MQCONNX verb allows a connect request to create an hConn that can be used under multiple threads.
The MQCNO_HANDLE_SHARE_BLOCK/MQCNO_HANDLE_SHARE_NO_BLOCK/MQCNO_HANDLE_SHARE_NONE options control what type of connection is created, whether the hConn is only valid under the thread that created it, and the behavior when multiple concurrent MQI requests are made on the same hConn. Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel, however the queue manager can serialize multiple concurrent request when MQCNO_HANDLE_SHARE_BLOCK is specified.

From: Brumbaugh Glen <glen.brumbaugh-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 05/08/2013 19:07
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

--------------------------------------------------------------------------------

Tim,

The MQI calls are "Single Threaded" through the one MQConn handle. Thus, there may only be one current API call at a time. There is no requirement, other than common sense and/or good design, that a single WMQ handle cannot be shared between multiple threads. If this were to be done, however, the individual threads would have to implement some kind of locking mechanism to serialize their parallel access of a serial resource. A singleton Java class, for instance, could provide the necessary serialization. From the description of the developer's input, the implementation does not seem to be this sophisticated, but it could be.

HTH.

Regards,

Glen Brumbaugh
Prolifics

On Aug 5, 2013, at 1:44 PM, Raul Acevedo <acevedor-rIXRsD/***@public.gmane.org> wrote:

Tim,

You are correct. Each thread has its own connection.

RaÃºl L. Acevedo
Senior IT Architect
IBM Global Business Services
Application Innovation Services (AIS)
818 599 6626 mobile
acevedor-r/Jw6+rmf7HQT0dZR+***@public.gmane.org email

<graycol.gif>Tim Zielke ---08/05/2013 01:33:33 PM---Hello, Normally, I would try to research this type of question more, but I am pressed for time this

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 08/05/2013 01:33 PM
Subject: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

--------------------------------------------------------------------------------

Hello,

Normally, I would try to research this type of question more, but I am pressed for time this week and hoping someone on the list might know off of the top of their head.

The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java developer who is saying that his multi-threaded java code does a connect and open of a queue under thread 1, and then threads 2-6 come along and do gets from the queue. Threads 2-6 have not done a connect or open on the queue before issuing the get, according to the developer. I was under the impression that each thread would need to separately connect and open the queue, before it could do a get. Am I mistaken?

Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Tim Zielke

2013-10-04 19:45:27 UTC

Hi Paul,

Yes, I am pretty sure those are 5 different connections there doing the MQGET ends. They all have different connections numbers (i.e. 1400000, 140000c, etc.).

"If you have different connections then there would be no serialisation."

So if I understand you correctly, you are saying that if a multi-threaded application has threads that each have unique connections, then MQ could be processing a GET end on thread 1 with connection 1 and a GET end on thread 2 with connection 2 in parallel?

I guess I am getting hung up on this fact, because I don't see this behavior with other multi-threaded applications that have threads with different connections. I just reviewed another java application that had 3 threads (each thread with its own connection) that were simultaneously doing GETs from a request queue and PUTs to a reply queue. However, when I reviewed the trace you would only ever see one MQI call ever running at one time in the trace. The begin or end of the MQI call for one thread would run to completion and then you would see another thread's MQI call start to run. There was no interleaving of MQI calls whatsoever between the three threads. To me, this behavior is consistent with Andy's comment "Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel".

I've only ever seen this type of MQI call interleaving in a trace like was listed below with this managed callback functionality.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Paul Clarke
Sent: Friday, October 04, 2013 2:22 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Java MQ Thread Question

Iâm not that familiar with the Java trace format but is it possible that there are 5 different connections here ? If you have different connections then there would be no serialisation.
Even if you were using one connection then just showing the MQGET functions calls and the return may not be sufficient to show you the serialisation call itself, it depends entirely on where that serialisation takes place. In other words, you could indeed see 5 threads each entering MQGET for the same connection and calling a number of functions before deciding that they do indeed contend with each other. At which point I would expect you to see only one of the threads proceed.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: Tim Zielke<mailto:***@AON.COM>
Sent: Friday, October 04, 2013 7:54 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Java MQ Thread Question

Hello MQLIST,

Here is another example of MQI behavior that is confusing me. This was run on a 7.1.0.2 queue manager on Solaris 10. In this case the application had registered multiple consumer functions. You can see that the MQGET << (GET end) are not being serialized and running in parallel for 5 different threads, at least that is how it looks to me. This seems odd and also seems to contradict the statement previously in this thread "Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel". It looks like these MQGET ends are running in parallel to me.

Am I misunderstanding something here?

Does anyone have any comments to clear up my confusion?

Thanks,
Tim

WebSphere MQ Formatted Trace - Formatter V3

+-----------------------------------------------------------------------+
| |
| WebSphere MQ Formatted Trace V3 |
| =============================== |
| |
| Date/Time :- 09/06/13 07:35:32 CST |
| UTC Time :- 1378470932.076600 |
| UTC Time Offset :- 5 (CST) |
| Host Name :- xxxxxxxx |
| Operating System :- SunOS 5.10 |
| LVLS :- 7.1.0.2 |
| Product Long Name :- WebSphere MQ for Solaris (SPARC platform) |
| CMVC Level :- p710-002-121018 |
| Installation Path :- /opt/mqm |
| Installation Name :- Installation1 (1) |
| Effective UserID :- 101 (wsphere) |
| Real UserID :- 101 (wsphere) |
| Program Name :- java |
| Addressing Mode :- 64-bit |
| Process :- 4822 |
| QueueManager :- |
| Reentrant :- 1 |
| |
+-----------------------------------------------------------------------+

Formatting options: None
Formatter installation path: /opt/mqm
Formatter version: 7.1.0.2

Timestamp Process.Thread Trace Ident Trace Data
===========================================================
*07:47:04.101935 4822.16 CONN:1400010 __________
07:47:04.101935 4822.10 CONN:140000a __________
07:47:04.102778 4822.16 CONN:1400010 MQGET <<
*07:47:04.102302 4822.6 CONN:1400006 __________
*07:47:04.101958 4822.12 CONN:140000c __________
07:47:04.102820 4822.16 CONN:1400010 Hconn : Input Parm
07:47:04.102871 4822.12 CONN:140000c MQGET <<
*07:47:04.102840 4822.6 CONN:1400006 MQGET <<
*07:47:04.102800 4822.10 CONN:140000a MQGET <<
07:47:04.102925 4822.6 CONN:1400006 Hconn : Input Parm
07:47:04.102946 4822.10 CONN:140000a Hconn : Input Parm
*07:47:04.102903 4822.12 CONN:140000c Hconn : Input Parm
07:47:04.102998 4822.8 CONN:1400008 __________
*07:47:04.102884 4822.16 CONN:1400010 Hconn:
07:47:04.102982 4822.10 CONN:140000a Hconn:
07:47:04.103058 4822.16 CONN:1400010 0x0000: 01400010 |***@.. |
*07:47:04.103007 4822.12 CONN:140000c Hconn:
07:47:04.103080 4822.10 CONN:140000a 0x0000: 0140000a |***@. |
*07:47:04.103031 4822.8 CONN:1400008 MQGET <<
07:47:04.103151 4822.10 CONN:140000a CbContext:
*07:47:04.103095 4822.16 CONN:1400010 CbContext:
07:47:04.103207 4822.10 CONN:140000a 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.103207 4822.10 CONN:140000a 0x0010: 00000001 02f02b70 00000000 00000000 |......+p........|
07:47:04.103207 4822.10 CONN:140000a 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.103207 4822.10 CONN:140000a 0x0030: 00000000 00000000 00000000 00000000 |................|
*07:47:04.103127 4822.12 CONN:140000c 0x0000: 0140000c |***@. |
*07:47:04.102961 4822.6 CONN:1400006 Hconn:
07:47:04.103224 4822.16 CONN:1400010 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.103224 4822.16 CONN:1400010 0x0010: 00000001 01263420 00000000 00000000 |.....&4 ........|
07:47:04.103224 4822.16 CONN:1400010 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.103224 4822.16 CONN:1400010 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103225 4822.14 CONN:140000e __________
07:47:04.103255 4822.10 CONN:140000a Msgdesc:
07:47:04.103374 4822.14 CONN:140000e MQGET <<
*07:47:04.103348 4822.16 CONN:1400010 Msgdesc:
*07:47:04.103287 4822.12 CONN:140000c CbContext:
07:47:04.103395 4822.10 CONN:140000a 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.103395 4822.10 CONN:140000a 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.103395 4822.10 CONN:140000a 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.103395 4822.10 CONN:140000a 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103395 4822.10 CONN:140000a 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.103395 4822.10 CONN:140000a 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.103395 4822.10 CONN:140000a 0x0160: 00000000 00000000 ffffffff |............ |
*07:47:04.103326 4822.6 CONN:1400006 0x0000: 01400006 |***@.. |
*07:47:04.103176 4822.8 CONN:1400008 Hconn : Input Parm
07:47:04.103513 4822.6 CONN:1400006 CbContext:
07:47:04.103537 4822.8 CONN:1400008 Hconn:
*07:47:04.103469 4822.12 CONN:140000c 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.103469 4822.12 CONN:140000c 0x0010: 00000001 03808240 00000000 00000000 |***@........|
07:47:04.103469 4822.12 CONN:140000c 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.103469 4822.12 CONN:140000c 0x0030: 00000000 00000000 00000000 00000000 |................|
*07:47:04.103449 4822.16 CONN:1400010 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.103449 4822.16 CONN:1400010 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.103449 4822.16 CONN:1400010 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.103449 4822.16 CONN:1400010 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103449 4822.16 CONN:1400010 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.103449 4822.16 CONN:1400010 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.103449 4822.16 CONN:1400010 0x0160: 00000000 00000000 ffffffff |............ |
*07:47:04.103424 4822.14 CONN:140000e Hconn : Input Parm
07:47:04.103557 4822.6 CONN:1400006 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.103557 4822.6 CONN:1400006 0x0010: 00000001 00f58a20 00000000 00000000 |....... ........|
07:47:04.103557 4822.6 CONN:1400006 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.103557 4822.6 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
*07:47:04.103490 4822.10 CONN:140000a Bufferlength:
07:47:04.103584 4822.8 CONN:1400008 0x0000: 01400008 |***@.. |
07:47:04.103652 4822.16 CONN:1400010 Bufferlength:
07:47:04.103762 4822.8 CONN:1400008 CbContext:
*07:47:04.103711 4822.6 CONN:1400006 Msgdesc:
07:47:04.103817 4822.8 CONN:1400008 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.103817 4822.8 CONN:1400008 0x0010: 00000001 01511c60 00000000 00000000 |.....Q.`........|
07:47:04.103817 4822.8 CONN:1400008 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.103817 4822.8 CONN:1400008 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103838 4822.6 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.103838 4822.6 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.103838 4822.6 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.103838 4822.6 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103838 4822.6 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.103838 4822.6 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.103838 4822.6 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
*07:47:04.103731 4822.10 CONN:140000a 0x0000: 00002000 |.. . |
*07:47:04.103619 4822.12 CONN:140000c Msgdesc:
07:47:04.103901 4822.6 CONN:1400006 Bufferlength:
*07:47:04.103685 4822.14 CONN:140000e Hconn:
07:47:04.103986 4822.6 CONN:1400006 0x0000: 00002000 |.. . |
*07:47:04.103859 4822.8 CONN:1400008 Msgdesc:
07:47:04.104040 4822.6 CONN:1400006 Datalength:
*07:47:04.103929 4822.10 CONN:140000a Datalength:
07:47:04.104008 4822.14 CONN:140000e 0x0000: 0140000e |***@.. |
07:47:04.104078 4822.8 CONN:1400008 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.104078 4822.8 CONN:1400008 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.104078 4822.8 CONN:1400008 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.104078 4822.8 CONN:1400008 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.104078 4822.8 CONN:1400008 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.104078 4822.8 CONN:1400008 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.104078 4822.8 CONN:1400008 0x0160: 00000000 00000000 ffffffff |............ |
07:47:04.104135 4822.10 CONN:140000a 0x0000: 00000000 |.... |
07:47:04.104192 4822.8 CONN:1400008 Bufferlength:
*07:47:04.104103 4822.6 CONN:1400006 0x0000: 00000000 |.... |
07:47:04.104156 4822.14 CONN:140000e CbContext:
*07:47:04.103783 4822.16 CONN:1400010 0x0000: 00002000 |.. . |
07:47:04.104274 4822.6 CONN:1400006 Compcode:
07:47:04.104372 4822.16 CONN:1400010 Datalength:
*07:47:04.104210 4822.10 CONN:140000a Compcode:
*07:47:04.103966 4822.12 CONN:140000c 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.103966 4822.12 CONN:140000c 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.103966 4822.12 CONN:140000c 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.103966 4822.12 CONN:140000c 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.103966 4822.12 CONN:140000c 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.103966 4822.12 CONN:140000c 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.103966 4822.12 CONN:140000c 0x0160: 00000000 00000000 ffffffff |............ |
07:47:04.104397 4822.6 CONN:1400006 0x0000: 00000002 |.... |
07:47:04.104486 4822.12 CONN:140000c Bufferlength:
*07:47:04.104455 4822.10 CONN:140000a 0x0000: 00000002 |.... |
*07:47:04.104427 4822.16 CONN:1400010 0x0000: 00000000 |.... |
*07:47:04.104251 4822.8 CONN:1400008 0x0000: 00002000 |.. . |
07:47:04.104334 4822.14 CONN:140000e 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|
07:47:04.104334 4822.14 CONN:140000e 0x0010: 00000001 01b19d60 00000000 00000000 |.......`........|
07:47:04.104334 4822.14 CONN:140000e 0x0020: 00000002 000007f1 00000000 00000000 |................|
07:47:04.104334 4822.14 CONN:140000e 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.104636 4822.8 CONN:1400008 Datalength:
*07:47:04.104571 4822.10 CONN:140000a Reason:
07:47:04.104657 4822.14 CONN:140000e Msgdesc:
*07:47:04.104536 4822.12 CONN:140000c 0x0000: 00002000 |.. . |
07:47:04.104605 4822.16 CONN:1400010 Compcode:
07:47:04.104750 4822.14 CONN:140000e 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
07:47:04.104750 4822.14 CONN:140000e 0x0010: ffffffff 00000000 00000111 00000000 |................|
07:47:04.104750 4822.14 CONN:140000e 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
07:47:04.104750 4822.14 CONN:140000e 0x0030: 00000000 00000000 00000000 00000000 |................|
07:47:04.104750 4822.14 CONN:140000e 0x0040: === Skipping 17 Duplicate Lines === |................|
07:47:04.104750 4822.14 CONN:140000e 0x0150: 00000000 00000000 00000000 00000001 |................|
07:47:04.104750 4822.14 CONN:140000e 0x0160: 00000000 00000000 ffffffff |............ |
*07:47:04.104680 4822.8 CONN:1400008 0x0000: 00000000 |.... |
07:47:04.104769 4822.12 CONN:140000c Datalength:
07:47:04.104832 4822.14 CONN:140000e Bufferlength:
*07:47:04.104714 4822.10 CONN:140000a 0x0000: 00007811 |..x. |
07:47:04.104801 4822.16 CONN:1400010 0x0000: 00000002 |.... |
07:47:04.104854 4822.8 CONN:1400008 Compcode:
07:47:04.104977 4822.16 CONN:1400010 Reason:
*07:47:04.104882 4822.12 CONN:140000c 0x0000: 00000000 |.... |
07:47:04.104914 4822.14 CONN:140000e 0x0000: 00002000 |.. . |
*07:47:04.104508 4822.6 CONN:1400006 Reason:
07:47:04.105042 4822.12 CONN:140000c Compcode:
*07:47:04.104994 4822.8 CONN:1400008 0x0000: 00000002 |.... |
07:47:04.105099 4822.6 CONN:1400006 0x0000: 00007811 |..x. |
*07:47:04.105072 4822.14 CONN:140000e Datalength:
07:47:04.105118 4822.12 CONN:140000c 0x0000: 00000002 |.... |
07:47:04.105147 4822.8 CONN:1400008 Reason:
07:47:04.105201 4822.14 CONN:140000e 0x0000: 00000000 |.... |
07:47:04.105223 4822.12 CONN:140000c Reason:
07:47:04.105248 4822.8 CONN:1400008 0x0000: 00007811 |..x. |
07:47:04.105273 4822.14 CONN:140000e Compcode:
07:47:04.105290 4822.12 CONN:140000c 0x0000: 00007811 |..x. |
07:47:04.105331 4822.14 CONN:140000e 0x0000: 00000002 |.... |
07:47:04.105372 4822.14 CONN:140000e Reason:
07:47:04.105396 4822.14 CONN:140000e 0x0000: 00007811 |..x. |
*07:47:04.105019 4822.16 CONN:1400010 0x0000: 00007811 |..x. |
===========================================================

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Andrew Hickson
Sent: Wednesday, September 18, 2013 1:08 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Java MQ Thread Question

In order to be useful an MQCTL with MQOP_STOP/MQOP_SUSPEND has to be able to run while the hConn is 'in use' by an async consume thread and so the behavior of MQCTL is slightly different than for other MQI calls.
The snippet of trace provided here is too short for me to be able to see exactly what is going on. I don't believe MQCTL is intended to interact directly with MQGET (as opposed to an 'MQGET' issued on behalf of callback) and the trace is too short for me to see the context of either the MQGET oir the MQCTL calls.

sorry
Andy.

From: Tim Zielke <***@AON.COM>
To: ***@listserv.meduniwien.ac.at
Date: 18/09/2013 14:58
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>
________________________________

Hi Andy,

I had one follow up on this thread.

For the most part in an API trace of a multi-threaded application, I see the behavior you mentioned below where the API (begins and ends) are serialized and only one API begin or end is running in the trace. However, for the case listed below where managed call backs are being used, I see an MQCTL end and MQGET begin running in what looks like a parallel fashion. I also see this behavior happening consistently in the trace.

Would the MQCTL end and MQGET begin (the MQGET that would run asynchronously on the MQ managed call back thread) be a case where two API calls could run in parallel?

I have listed an example of what I am seeing in the trace below. You can see the MQCTL end running on thread 2 and the MQGET begin running on thread 5 running in what appears to be parallel fashion.

This managed call back was set up so that an MQGET of 2033 would be issued immediately to the consumer function once the managed call back was activated and if no message was available on the queue.

This trace was run on a 7.1.0.2 Solaris 10 queue manager.

08:02:21.402789 554.2 CONN:1400006 __________
08:02:21.402832 554.2 CONN:1400006 MQCTL <<
*08:02:21.402797 554.5 CONN:1400006 __________
08:02:21.402856 554.2 CONN:1400006 Hconn : Input Parm
08:02:21.402882 554.5 CONN:1400006 MQGET >>
08:02:21.402905 554.2 CONN:1400006 Operation : Input Parm
08:02:21.402929 554.5 CONN:1400006 Hconn:
08:02:21.402952 554.2 CONN:1400006 CtlOpts:
08:02:21.402978 554.5 CONN:1400006 0x0000: 01400006 |***@.. |
08:02:21.403025 554.5 CONN:1400006 Msgdesc:
*08:02:21.402999 554.2 CONN:1400006 0x0000: 43544c4f 00000001 00000000 ffffffff |CTLO............|
08:02:21.402999 554.2 CONN:1400006 0x0010: 00000000 00000000 |........ |
08:02:21.403049 554.5 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
08:02:21.403049 554.5 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
08:02:21.403049 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
08:02:21.403049 554.5 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
08:02:21.403049 554.5 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
08:02:21.403071 554.2 CONN:1400006 Compcode:
08:02:21.403093 554.5 CONN:1400006 Bufferlength:
08:02:21.403115 554.2 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403166 554.2 CONN:1400006 Reason:
*08:02:21.403140 554.5 CONN:1400006 0x0000: 00002000 |.. . |
08:02:21.403191 554.2 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403212 554.5 CONN:1400006 Buffer : Output Parm
08:02:21.403259 554.5 CONN:1400006 Datalength : Output Parm
08:02:21.403277 554.5 CONN:1400006 Compcode : Output Parm
08:02:21.403293 554.5 CONN:1400006 Reason : Output Parm
08:02:21.403615 554.5 CONN:1400006 __________
08:02:21.403639 554.5 CONN:1400006 MQGET <<
08:02:21.403656 554.5 CONN:1400006 Hconn : Input Parm
08:02:21.403674 554.5 CONN:1400006 Hconn:
08:02:21.403692 554.5 CONN:1400006 0x0000: 01400006 |***@.. |
08:02:21.403709 554.5 CONN:1400006 CbContext:
08:02:21.403726 554.5 CONN:1400006 0x0000: ffffffff 26c3f221 ffffffff 00000002 |....&..!........|
08:02:21.403726 554.5 CONN:1400006 0x0010: 00000000 00000000 00000000 00000000 |................|
08:02:21.403726 554.5 CONN:1400006 0x0020: 00000001 02b42d50 00000000 00000000 |......-P........|
08:02:21.403726 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403743 554.5 CONN:1400006 Msgdesc:
08:02:21.403762 554.5 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
08:02:21.403762 554.5 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
08:02:21.403762 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
08:02:21.403762 554.5 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
08:02:21.403762 554.5 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
08:02:21.403782 554.5 CONN:1400006 Bufferlength:
08:02:21.403799 554.5 CONN:1400006 0x0000: 00002000 |.. . |
08:02:21.403816 554.5 CONN:1400006 Datalength:
08:02:21.403834 554.5 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403850 554.5 CONN:1400006 Compcode:
08:02:21.403865 554.5 CONN:1400006 0x0000: 00000002 |.... |
08:02:21.403880 554.5 CONN:1400006 Reason:
08:02:21.403897 554.5 CONN:1400006 0x0000: 000007f1 |.... |
08:02:21.426780 554.5 CONN:1400006 __________

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Andrew Hickson
Sent: Monday, August 05, 2013 1:22 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Java MQ Thread Question

At the MQI level, the MQCONNX verb allows a connect request to create an hConn that can be used under multiple threads.
The MQCNO_HANDLE_SHARE_BLOCK/MQCNO_HANDLE_SHARE_NO_BLOCK/MQCNO_HANDLE_SHARE_NONE options control what type of connection is created, whether the hConn is only valid under the thread that created it, and the behavior when multiple concurrent MQI requests are made on the same hConn. Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel, however the queue manager can serialize multiple concurrent request when MQCNO_HANDLE_SHARE_BLOCK is specified.

From: Brumbaugh Glen <***@YAHOO.COM>
To: ***@listserv.meduniwien.ac.at
Date: 05/08/2013 19:07
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>

________________________________

Tim,

The MQI calls are "Single Threaded" through the one MQConn handle. Thus, there may only be one current API call at a time. There is no requirement, other than common sense and/or good design, that a single WMQ handle cannot be shared between multiple threads. If this were to be done, however, the individual threads would have to implement some kind of locking mechanism to serialize their parallel access of a serial resource. A singleton Java class, for instance, could provide the necessary serialization. From the description of the developer's input, the implementation does not seem to be this sophisticated, but it could be.

HTH.

Regards,

Glen Brumbaugh
Prolifics

On Aug 5, 2013, at 1:44 PM, Raul Acevedo <***@US.IBM.COM<mailto:***@US.IBM.COM>> wrote:

Tim,

You are correct. Each thread has its own connection.

RaÃºl L. Acevedo
Senior IT Architect
IBM Global Business Services
Application Innovation Services (AIS)
818 599 6626 mobile
***@us.ibm.com<mailto:***@us.ibm.com> email

<graycol.gif>Tim Zielke ---08/05/2013 01:33:33 PM---Hello, Normally, I would try to research this type of question more, but I am pressed for time this

From: Tim Zielke <***@AON.COM<mailto:***@AON.COM>>
To: ***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>,
Date: 08/05/2013 01:33 PM
Subject: Java MQ Thread Question
Sent by: MQSeries List <***@listserv.meduniwien.ac.at<mailto:***@listserv.meduniwien.ac.at>>

________________________________

Hello,

Normally, I would try to research this type of question more, but I am pressed for time this week and hoping someone on the list might know off of the top of their head.

The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java developer who is saying that his multi-threaded java code does a connect and open of a queue under thread 1, and then threads 2-6 come along and do gets from the queue. Threads 2-6 have not done a connect or open on the queue before issuing the get, according to the developer. I was under the impression that each thread would need to separately connect and open the queue, before it could do a get. Am I mistaken?

Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

Paul Clarke

2013-10-04 20:36:33 UTC

Hi,

Yes, if you have different connections then each connection can issue any MQI call they like. There is no âconnection levelâ serialisation. Clearly at the queue level there will be some serialisation, ie. ultimately only one connection can be adding or removing a message at the same instant but this level of serialisation is very short lived. The exact serialisation performed will depend on the environment, client, local, java or C etc and I certainly canât speak for all environments.

It is quite difficult to see things like serialisation or parallelism in a trace file since tracing has such a dramatic effect on the operation of a program, not least of which to slow it down considerably. If you see a particular pattern with tracing on there is no guarantee that the same pattern will exist with tracing off.

One way to demonstrate the fact that MQ supports parallel operation on different connections is to look at the performance reports. You will see that as you increase the number of applications, all doing the same thing, you get increased throughput. There are, of course, many factors for this but one of them is the ability with multiple connections to drive more syncpointed operations to the logger in any given time. Clearly this would not happen if the entire MQI call was serialised.

Cheers,
P.

Paul Clarke
www.mqgem.com

From: Tim Zielke
Sent: Friday, October 04, 2013 8:45 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

Hi Paul,

Yes, I am pretty sure those are 5 different connections there doing the MQGET ends. They all have different connections numbers (i.e. 1400000, 140000c, etc.).

"If you have different connections then there would be no serialisation."

So if I understand you correctly, you are saying that if a multi-threaded application has threads that each have unique connections, then MQ could be processing a GET end on thread 1 with connection 1 and a GET end on thread 2 with connection 2 in parallel?

I guess I am getting hung up on this fact, because I don't see this behavior with other multi-threaded applications that have threads with different connections. I just reviewed another java application that had 3 threads (each thread with its own connection) that were simultaneously doing GETs from a request queue and PUTs to a reply queue. However, when I reviewed the trace you would only ever see one MQI call ever running at one time in the trace. The begin or end of the MQI call for one thread would run to completion and then you would see another thread's MQI call start to run. There was no interleaving of MQI calls whatsoever between the three threads. To me, this behavior is consistent with Andy's comment "Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel".

I've only ever seen this type of MQI call interleaving in a trace like was listed below with this managed callback functionality.

Thanks,

Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Paul Clarke
Sent: Friday, October 04, 2013 2:22 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

Iâm not that familiar with the Java trace format but is it possible that there are 5 different connections here ? If you have different connections then there would be no serialisation.

Even if you were using one connection then just showing the MQGET functions calls and the return may not be sufficient to show you the serialisation call itself, it depends entirely on where that serialisation takes place. In other words, you could indeed see 5 threads each entering MQGET for the same connection and calling a number of functions before deciding that they do indeed contend with each other. At which point I would expect you to see only one of the threads proceed.

Cheers,

Paul.

Paul Clarke
www.mqgem.com

From: Tim Zielke

Sent: Friday, October 04, 2013 7:54 PM

To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org

Subject: Re: Java MQ Thread Question

Hello MQLIST,

Here is another example of MQI behavior that is confusing me. This was run on a 7.1.0.2 queue manager on Solaris 10. In this case the application had registered multiple consumer functions. You can see that the MQGET << (GET end) are not being serialized and running in parallel for 5 different threads, at least that is how it looks to me. This seems odd and also seems to contradict the statement previously in this thread "Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel". It looks like these MQGET ends are running in parallel to me.

Am I misunderstanding something here?

Does anyone have any comments to clear up my confusion?

Thanks,

Tim

WebSphere MQ Formatted Trace - Formatter V3

+-----------------------------------------------------------------------+

| |

| WebSphere MQ Formatted Trace V3 |

| =============================== |

| |

| Date/Time :- 09/06/13 07:35:32 CST |

| UTC Time :- 1378470932.076600 |

| UTC Time Offset :- 5 (CST) |

| Host Name :- xxxxxxxx |

| Operating System :- SunOS 5.10 |

| LVLS :- 7.1.0.2 |

| Product Long Name :- WebSphere MQ for Solaris (SPARC platform) |

| CMVC Level :- p710-002-121018 |

| Installation Path :- /opt/mqm |

| Installation Name :- Installation1 (1) |

| Effective UserID :- 101 (wsphere) |

| Real UserID :- 101 (wsphere) |

| Program Name :- java |

| Addressing Mode :- 64-bit |

| Process :- 4822 |

| QueueManager :- |

| Reentrant :- 1 |

| |

+-----------------------------------------------------------------------+

Formatting options: None

Formatter installation path: /opt/mqm

Formatter version: 7.1.0.2

Timestamp Process.Thread Trace Ident Trace Data

===========================================================

*07:47:04.101935 4822.16 CONN:1400010 __________

07:47:04.101935 4822.10 CONN:140000a __________

07:47:04.102778 4822.16 CONN:1400010 MQGET <<

*07:47:04.102302 4822.6 CONN:1400006 __________

*07:47:04.101958 4822.12 CONN:140000c __________

07:47:04.102820 4822.16 CONN:1400010 Hconn : Input Parm

07:47:04.102871 4822.12 CONN:140000c MQGET <<

*07:47:04.102840 4822.6 CONN:1400006 MQGET <<

*07:47:04.102800 4822.10 CONN:140000a MQGET <<

07:47:04.102925 4822.6 CONN:1400006 Hconn : Input Parm

07:47:04.102946 4822.10 CONN:140000a Hconn : Input Parm

*07:47:04.102903 4822.12 CONN:140000c Hconn : Input Parm

07:47:04.102998 4822.8 CONN:1400008 __________

*07:47:04.102884 4822.16 CONN:1400010 Hconn:

07:47:04.102982 4822.10 CONN:140000a Hconn:

07:47:04.103058 4822.16 CONN:1400010 0x0000: 01400010 |***@.. |

*07:47:04.103007 4822.12 CONN:140000c Hconn:

07:47:04.103080 4822.10 CONN:140000a 0x0000: 0140000a |***@. |

*07:47:04.103031 4822.8 CONN:1400008 MQGET <<

07:47:04.103151 4822.10 CONN:140000a CbContext:

*07:47:04.103095 4822.16 CONN:1400010 CbContext:

07:47:04.103207 4822.10 CONN:140000a 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.103207 4822.10 CONN:140000a 0x0010: 00000001 02f02b70 00000000 00000000 |......+p........|

07:47:04.103207 4822.10 CONN:140000a 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.103207 4822.10 CONN:140000a 0x0030: 00000000 00000000 00000000 00000000 |................|

*07:47:04.103127 4822.12 CONN:140000c 0x0000: 0140000c |***@. |

*07:47:04.102961 4822.6 CONN:1400006 Hconn:

07:47:04.103224 4822.16 CONN:1400010 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.103224 4822.16 CONN:1400010 0x0010: 00000001 01263420 00000000 00000000 |.....&4 ........|

07:47:04.103224 4822.16 CONN:1400010 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.103224 4822.16 CONN:1400010 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103225 4822.14 CONN:140000e __________

07:47:04.103255 4822.10 CONN:140000a Msgdesc:

07:47:04.103374 4822.14 CONN:140000e MQGET <<

*07:47:04.103348 4822.16 CONN:1400010 Msgdesc:

*07:47:04.103287 4822.12 CONN:140000c CbContext:

07:47:04.103395 4822.10 CONN:140000a 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.103395 4822.10 CONN:140000a 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.103395 4822.10 CONN:140000a 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.103395 4822.10 CONN:140000a 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103395 4822.10 CONN:140000a 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.103395 4822.10 CONN:140000a 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.103395 4822.10 CONN:140000a 0x0160: 00000000 00000000 ffffffff |............ |

*07:47:04.103326 4822.6 CONN:1400006 0x0000: 01400006 |***@.. |

*07:47:04.103176 4822.8 CONN:1400008 Hconn : Input Parm

07:47:04.103513 4822.6 CONN:1400006 CbContext:

07:47:04.103537 4822.8 CONN:1400008 Hconn:

*07:47:04.103469 4822.12 CONN:140000c 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.103469 4822.12 CONN:140000c 0x0010: 00000001 03808240 00000000 00000000 |***@........|

07:47:04.103469 4822.12 CONN:140000c 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.103469 4822.12 CONN:140000c 0x0030: 00000000 00000000 00000000 00000000 |................|

*07:47:04.103449 4822.16 CONN:1400010 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.103449 4822.16 CONN:1400010 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.103449 4822.16 CONN:1400010 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.103449 4822.16 CONN:1400010 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103449 4822.16 CONN:1400010 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.103449 4822.16 CONN:1400010 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.103449 4822.16 CONN:1400010 0x0160: 00000000 00000000 ffffffff |............ |

*07:47:04.103424 4822.14 CONN:140000e Hconn : Input Parm

07:47:04.103557 4822.6 CONN:1400006 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.103557 4822.6 CONN:1400006 0x0010: 00000001 00f58a20 00000000 00000000 |....... ........|

07:47:04.103557 4822.6 CONN:1400006 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.103557 4822.6 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|

*07:47:04.103490 4822.10 CONN:140000a Bufferlength:

07:47:04.103584 4822.8 CONN:1400008 0x0000: 01400008 |***@.. |

07:47:04.103652 4822.16 CONN:1400010 Bufferlength:

07:47:04.103762 4822.8 CONN:1400008 CbContext:

*07:47:04.103711 4822.6 CONN:1400006 Msgdesc:

07:47:04.103817 4822.8 CONN:1400008 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.103817 4822.8 CONN:1400008 0x0010: 00000001 01511c60 00000000 00000000 |.....Q.`........|

07:47:04.103817 4822.8 CONN:1400008 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.103817 4822.8 CONN:1400008 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103838 4822.6 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.103838 4822.6 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.103838 4822.6 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.103838 4822.6 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103838 4822.6 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.103838 4822.6 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.103838 4822.6 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |

*07:47:04.103731 4822.10 CONN:140000a 0x0000: 00002000 |.. . |

*07:47:04.103619 4822.12 CONN:140000c Msgdesc:

07:47:04.103901 4822.6 CONN:1400006 Bufferlength:

*07:47:04.103685 4822.14 CONN:140000e Hconn:

07:47:04.103986 4822.6 CONN:1400006 0x0000: 00002000 |.. . |

*07:47:04.103859 4822.8 CONN:1400008 Msgdesc:

07:47:04.104040 4822.6 CONN:1400006 Datalength:

*07:47:04.103929 4822.10 CONN:140000a Datalength:

07:47:04.104008 4822.14 CONN:140000e 0x0000: 0140000e |***@.. |

07:47:04.104078 4822.8 CONN:1400008 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.104078 4822.8 CONN:1400008 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.104078 4822.8 CONN:1400008 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.104078 4822.8 CONN:1400008 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.104078 4822.8 CONN:1400008 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.104078 4822.8 CONN:1400008 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.104078 4822.8 CONN:1400008 0x0160: 00000000 00000000 ffffffff |............ |

07:47:04.104135 4822.10 CONN:140000a 0x0000: 00000000 |.... |

07:47:04.104192 4822.8 CONN:1400008 Bufferlength:

*07:47:04.104103 4822.6 CONN:1400006 0x0000: 00000000 |.... |

07:47:04.104156 4822.14 CONN:140000e CbContext:

*07:47:04.103783 4822.16 CONN:1400010 0x0000: 00002000 |.. . |

07:47:04.104274 4822.6 CONN:1400006 Compcode:

07:47:04.104372 4822.16 CONN:1400010 Datalength:

*07:47:04.104210 4822.10 CONN:140000a Compcode:

*07:47:04.103966 4822.12 CONN:140000c 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.103966 4822.12 CONN:140000c 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.103966 4822.12 CONN:140000c 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.103966 4822.12 CONN:140000c 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.103966 4822.12 CONN:140000c 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.103966 4822.12 CONN:140000c 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.103966 4822.12 CONN:140000c 0x0160: 00000000 00000000 ffffffff |............ |

07:47:04.104397 4822.6 CONN:1400006 0x0000: 00000002 |.... |

07:47:04.104486 4822.12 CONN:140000c Bufferlength:

*07:47:04.104455 4822.10 CONN:140000a 0x0000: 00000002 |.... |

*07:47:04.104427 4822.16 CONN:1400010 0x0000: 00000000 |.... |

*07:47:04.104251 4822.8 CONN:1400008 0x0000: 00002000 |.. . |

07:47:04.104334 4822.14 CONN:140000e 0x0000: 43424320 00000002 00000005 00000000 |CBC ............|

07:47:04.104334 4822.14 CONN:140000e 0x0010: 00000001 01b19d60 00000000 00000000 |.......`........|

07:47:04.104334 4822.14 CONN:140000e 0x0020: 00000002 000007f1 00000000 00000000 |................|

07:47:04.104334 4822.14 CONN:140000e 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.104636 4822.8 CONN:1400008 Datalength:

*07:47:04.104571 4822.10 CONN:140000a Reason:

07:47:04.104657 4822.14 CONN:140000e Msgdesc:

*07:47:04.104536 4822.12 CONN:140000c 0x0000: 00002000 |.. . |

07:47:04.104605 4822.16 CONN:1400010 Compcode:

07:47:04.104750 4822.14 CONN:140000e 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|

07:47:04.104750 4822.14 CONN:140000e 0x0010: ffffffff 00000000 00000111 00000000 |................|

07:47:04.104750 4822.14 CONN:140000e 0x0020: 20202020 20202020 ffffffff 00000002 | ........|

07:47:04.104750 4822.14 CONN:140000e 0x0030: 00000000 00000000 00000000 00000000 |................|

07:47:04.104750 4822.14 CONN:140000e 0x0040: === Skipping 17 Duplicate Lines === |................|

07:47:04.104750 4822.14 CONN:140000e 0x0150: 00000000 00000000 00000000 00000001 |................|

07:47:04.104750 4822.14 CONN:140000e 0x0160: 00000000 00000000 ffffffff |............ |

*07:47:04.104680 4822.8 CONN:1400008 0x0000: 00000000 |.... |

07:47:04.104769 4822.12 CONN:140000c Datalength:

07:47:04.104832 4822.14 CONN:140000e Bufferlength:

*07:47:04.104714 4822.10 CONN:140000a 0x0000: 00007811 |..x. |

07:47:04.104801 4822.16 CONN:1400010 0x0000: 00000002 |.... |

07:47:04.104854 4822.8 CONN:1400008 Compcode:

07:47:04.104977 4822.16 CONN:1400010 Reason:

*07:47:04.104882 4822.12 CONN:140000c 0x0000: 00000000 |.... |

07:47:04.104914 4822.14 CONN:140000e 0x0000: 00002000 |.. . |

*07:47:04.104508 4822.6 CONN:1400006 Reason:

07:47:04.105042 4822.12 CONN:140000c Compcode:

*07:47:04.104994 4822.8 CONN:1400008 0x0000: 00000002 |.... |

07:47:04.105099 4822.6 CONN:1400006 0x0000: 00007811 |..x. |

*07:47:04.105072 4822.14 CONN:140000e Datalength:

07:47:04.105118 4822.12 CONN:140000c 0x0000: 00000002 |.... |

07:47:04.105147 4822.8 CONN:1400008 Reason:

07:47:04.105201 4822.14 CONN:140000e 0x0000: 00000000 |.... |

07:47:04.105223 4822.12 CONN:140000c Reason:

07:47:04.105248 4822.8 CONN:1400008 0x0000: 00007811 |..x. |

07:47:04.105273 4822.14 CONN:140000e Compcode:

07:47:04.105290 4822.12 CONN:140000c 0x0000: 00007811 |..x. |

07:47:04.105331 4822.14 CONN:140000e 0x0000: 00000002 |.... |

07:47:04.105372 4822.14 CONN:140000e Reason:

07:47:04.105396 4822.14 CONN:140000e 0x0000: 00007811 |..x. |

*07:47:04.105019 4822.16 CONN:1400010 0x0000: 00007811 |..x. |

===========================================================

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Wednesday, September 18, 2013 1:08 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

In order to be useful an MQCTL with MQOP_STOP/MQOP_SUSPEND has to be able to run while the hConn is 'in use' by an async consume thread and so the behavior of MQCTL is slightly different than for other MQI calls.
The snippet of trace provided here is too short for me to be able to see exactly what is going on. I don't believe MQCTL is intended to interact directly with MQGET (as opposed to an 'MQGET' issued on behalf of callback) and the trace is too short for me to see the context of either the MQGET oir the MQCTL calls.

sorry
Andy.

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 18/09/2013 14:58
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

--------------------------------------------------------------------------------

Hi Andy,

I had one follow up on this thread.

For the most part in an API trace of a multi-threaded application, I see the behavior you mentioned below where the API (begins and ends) are serialized and only one API begin or end is running in the trace. However, for the case listed below where managed call backs are being used, I see an MQCTL end and MQGET begin running in what looks like a parallel fashion. I also see this behavior happening consistently in the trace.

Would the MQCTL end and MQGET begin (the MQGET that would run asynchronously on the MQ managed call back thread) be a case where two API calls could run in parallel?

I have listed an example of what I am seeing in the trace below. You can see the MQCTL end running on thread 2 and the MQGET begin running on thread 5 running in what appears to be parallel fashion.

This managed call back was set up so that an MQGET of 2033 would be issued immediately to the consumer function once the managed call back was activated and if no message was available on the queue.

This trace was run on a 7.1.0.2 Solaris 10 queue manager.

08:02:21.402789 554.2 CONN:1400006 __________
08:02:21.402832 554.2 CONN:1400006 MQCTL <<
*08:02:21.402797 554.5 CONN:1400006 __________
08:02:21.402856 554.2 CONN:1400006 Hconn : Input Parm
08:02:21.402882 554.5 CONN:1400006 MQGET >>
08:02:21.402905 554.2 CONN:1400006 Operation : Input Parm
08:02:21.402929 554.5 CONN:1400006 Hconn:
08:02:21.402952 554.2 CONN:1400006 CtlOpts:
08:02:21.402978 554.5 CONN:1400006 0x0000: 01400006 |***@.. |
08:02:21.403025 554.5 CONN:1400006 Msgdesc:
*08:02:21.402999 554.2 CONN:1400006 0x0000: 43544c4f 00000001 00000000 ffffffff |CTLO............|
08:02:21.402999 554.2 CONN:1400006 0x0010: 00000000 00000000 |........ |
08:02:21.403049 554.5 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
08:02:21.403049 554.5 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
08:02:21.403049 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403049 554.5 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
08:02:21.403049 554.5 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
08:02:21.403049 554.5 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
08:02:21.403071 554.2 CONN:1400006 Compcode:
08:02:21.403093 554.5 CONN:1400006 Bufferlength:
08:02:21.403115 554.2 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403166 554.2 CONN:1400006 Reason:
*08:02:21.403140 554.5 CONN:1400006 0x0000: 00002000 |.. . |
08:02:21.403191 554.2 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403212 554.5 CONN:1400006 Buffer : Output Parm
08:02:21.403259 554.5 CONN:1400006 Datalength : Output Parm
08:02:21.403277 554.5 CONN:1400006 Compcode : Output Parm
08:02:21.403293 554.5 CONN:1400006 Reason : Output Parm
08:02:21.403615 554.5 CONN:1400006 __________
08:02:21.403639 554.5 CONN:1400006 MQGET <<
08:02:21.403656 554.5 CONN:1400006 Hconn : Input Parm
08:02:21.403674 554.5 CONN:1400006 Hconn:
08:02:21.403692 554.5 CONN:1400006 0x0000: 01400006 |***@.. |
08:02:21.403709 554.5 CONN:1400006 CbContext:
08:02:21.403726 554.5 CONN:1400006 0x0000: ffffffff 26c3f221 ffffffff 00000002 |....&..!........|
08:02:21.403726 554.5 CONN:1400006 0x0010: 00000000 00000000 00000000 00000000 |................|
08:02:21.403726 554.5 CONN:1400006 0x0020: 00000001 02b42d50 00000000 00000000 |......-P........|
08:02:21.403726 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403743 554.5 CONN:1400006 Msgdesc:
08:02:21.403762 554.5 CONN:1400006 0x0000: 4d442020 00000002 00000000 00000008 |MD ............|
08:02:21.403762 554.5 CONN:1400006 0x0010: ffffffff 00000000 00000111 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0020: 20202020 20202020 ffffffff 00000002 | ........|
08:02:21.403762 554.5 CONN:1400006 0x0030: 00000000 00000000 00000000 00000000 |................|
08:02:21.403762 554.5 CONN:1400006 0x0040: === Skipping 17 Duplicate Lines === |................|
08:02:21.403762 554.5 CONN:1400006 0x0150: 00000000 00000000 00000000 00000001 |................|
08:02:21.403762 554.5 CONN:1400006 0x0160: 00000000 00000000 ffffffff |............ |
08:02:21.403782 554.5 CONN:1400006 Bufferlength:
08:02:21.403799 554.5 CONN:1400006 0x0000: 00002000 |.. . |
08:02:21.403816 554.5 CONN:1400006 Datalength:
08:02:21.403834 554.5 CONN:1400006 0x0000: 00000000 |.... |
08:02:21.403850 554.5 CONN:1400006 Compcode:
08:02:21.403865 554.5 CONN:1400006 0x0000: 00000002 |.... |
08:02:21.403880 554.5 CONN:1400006 Reason:
08:02:21.403897 554.5 CONN:1400006 0x0000: 000007f1 |.... |
08:02:21.426780 554.5 CONN:1400006 __________

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Andrew Hickson
Sent: Monday, August 05, 2013 1:22 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Java MQ Thread Question

At the MQI level, the MQCONNX verb allows a connect request to create an hConn that can be used under multiple threads.
The MQCNO_HANDLE_SHARE_BLOCK/MQCNO_HANDLE_SHARE_NO_BLOCK/MQCNO_HANDLE_SHARE_NONE options control what type of connection is created, whether the hConn is only valid under the thread that created it, and the behavior when multiple concurrent MQI requests are made on the same hConn. Under the covers it's not possible for multiple concurrent MQI requests to actually be processed in parallel, however the queue manager can serialize multiple concurrent request when MQCNO_HANDLE_SHARE_BLOCK is specified.

From: Brumbaugh Glen <glen.brumbaugh-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 05/08/2013 19:07
Subject: Re: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

--------------------------------------------------------------------------------

Tim,

The MQI calls are "Single Threaded" through the one MQConn handle. Thus, there may only be one current API call at a time. There is no requirement, other than common sense and/or good design, that a single WMQ handle cannot be shared between multiple threads. If this were to be done, however, the individual threads would have to implement some kind of locking mechanism to serialize their parallel access of a serial resource. A singleton Java class, for instance, could provide the necessary serialization. From the description of the developer's input, the implementation does not seem to be this sophisticated, but it could be.

HTH.

Regards,

Glen Brumbaugh
Prolifics

On Aug 5, 2013, at 1:44 PM, Raul Acevedo <acevedor-rIXRsD/***@public.gmane.org> wrote:

Tim,

You are correct. Each thread has its own connection.

RaÃºl L. Acevedo
Senior IT Architect
IBM Global Business Services
Application Innovation Services (AIS)
818 599 6626 mobile
acevedor-r/Jw6+rmf7HQT0dZR+***@public.gmane.org email

<graycol.gif>Tim Zielke ---08/05/2013 01:33:33 PM---Hello, Normally, I would try to research this type of question more, but I am pressed for time this

From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 08/05/2013 01:33 PM
Subject: Java MQ Thread Question
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

--------------------------------------------------------------------------------

Hello,

Normally, I would try to research this type of question more, but I am pressed for time this week and hoping someone on the list might know off of the top of their head.

The platform here is MQ 7.1.0.2 running on Linux x86. I have a Java developer who is saying that his multi-threaded java code does a connect and open of a queue under thread 1, and then threads 2-6 come along and do gets from the queue. Threads 2-6 have not done a connect or open on the queue before issuing the get, according to the developer. I was under the impression that each thread would need to separately connect and open the queue, before it could do a get. Am I mistaken?

Thanks,
Tim Zielke
CICS/MQ Systems Programmer
Aon Hewitt

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Tim Zielke

2013-10-04 21:40:07 UTC