| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Connection handle thread safety for MQPUTs |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Tue Aug 03, 2010 8:22 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
Now, I know by theory and by experience that a connection handle cannot be used concurrently for MQGETs...
|
hopsala: I went back to your original post (OP). Was the purpose of your OP to ask if there is a difference between MQGET and MQPUT behavior with regard to connection and/or object handle sharing? Was the purpose of your OP to state that you have observed differences in this behavior between MQGET and MQPUT?
The MQCNO doc in the APR is doesn't make such a distinction.
In general, the destination of MQI calls is the qmgr agent. Like its database cousin, the agents job is to validate the call, return it to the caller if invalid, or to schedule its execution if valid.
If developers don't want to use the native MQI calls, there are wrappers that can be used. These can hide the underlying complexity of the the MQI calls, or provide other services. Java, JMS, .net, AMI, Python, are examples of wrappers. There are others.
The wrapped MAI call must be unwrapped as it arrives at the qmgr agent.
Using AMI as an example, it is likely that wrapped code can/might/will behave differently had the application were written using the native MQI calls.
One of my clients was lamenting how painfully slow his request/reply model AMI app was running as the number of transactions increased. AMI did MQPUT1 calls, which work wonderfully at low message rates; but not so good at higher message rates because of the overhead of the implied MQOPEN and MQCLOSE for each put, .
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
 |
| hopsala |
| Posted: Wed Aug 04, 2010 10:59 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mvic wrote: |
| I would like to suggest that we avoid the phrase "thread safe" as it seems to mean different things to different people. |
Agreed. The term is not specific enough.
| mvic wrote: |
| Quote: |
| Essentially we're saying that in dotnet the default is BLOCK, rather than NONE as is stated in the lit. Either that or something else is going on. |
You did say that your libraries/apps are doing their own synchronization, as a side-effect of some library code they are using. Did I misunderstand that point? |
No, you got it. But it's not exactly a complete synchronization effect, it only drastically reduces the chances of simultaneous MQPUTs. The only thing I'm relatively sure of is that the system has been running in high-throughput tests for years without error messages.
I have since then run some heavy-duty testing, without logs (so no synchronization effect), >30 threads and 5MB persistent messages. I still don't crash. For the moment I can't log it properly or get MQ traces so I can't tell if two MQPUTs actually occur simultaneously, nor if there's blocking. But at least it would seem that by default there's no RC 2129, as in other languages. |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Aug 05, 2010 9:36 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| bruce2359 wrote: |
| The MQCNO doc in the APR is doesn't make such a distinction. |
That's exactly my point.
| bruce2359 wrote: |
| Quote: |
| Now, I know by theory and by experience that a connection handle cannot be used concurrently for MQGETs... |
hopsala: I went back to your original post (OP). Was the purpose of your OP to ask if there is a difference between MQGET and MQPUT behavior with regard to connection and/or object handle sharing? Was the purpose of your OP to state that you have observed differences in this behavior between MQGET and MQPUT? |
Yes. That and I thought a discussion about the internal workings of MQPUT (and a bit more complex - MQPUT on a client chl) will ensue, as it did, both here and in my head.
These are the components involved in a client scenario, unless I missed something:
- client agent
- comm stack
- socket
- send buff
- svrconn agent
- receive buff
- queue buffer
- queue file
- log buffer
- log file
All these are shared for a few concurrent threads working on the same queue with the same hconn and hqueue. All simultaneous MQPUTs compete for these when issued. Some are also vied for in regular multi-handle processing.
There are many ways in which this could be made to work. Let's assume blocking functionality (it doesn't really matter if it blocks or yields RC2129, the point is that there's synchronization logic involved). If it's the same thread, I imagine the client agent is shared, and it's probably safe to assume it's synchronized, which might have a pretty big performance impact as opposed to working with seperate processes. But what about the comm stack, the socket, the send buffer? All these may be synchronized, or alternatively they may be thread/process specific. I think it's a valid question to ask which.
Now, consider the fact that client is not assured delivery (unless something has changed in the past few years, http://www.mqseries.net/phpBB2/viewtopic.php?p=164433). Will simultaneous MQPUTs increase the chance message loss up to an unacceptable rate? Maybe, since I did not specify either BLOCK or NO_BLOCK, but still simultaneous MQPUTs work, I'm working in some limbo state in which every call returns RC0 but messages are occasionally lost? Maybe this is, pure and simple, a dotnet bug and I should be getting CALL_IN_PROGRESS RCs or something to denote sharing is not allowed by default? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 05, 2010 10:00 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| All these are shared for a few concurrent threads working on the same queue with the same hconn and hqueue. All simultaneous MQPUTs compete for these when issued. Some are also vied for in regular multi-handle processing. |
No. A queue is a single resource. It has no relationship to items 1-6, and 9-10.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
