| Author |
Message
|
| hopsala |
 Posted: Wed Jul 28, 2010 2:26 am Post subject: Connection handle thread safety for MQPUTs |
 |
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Hey
So I have a client who uses one connection handle for a whole bunch of threads in a dotnet application. They all continuously issue MQPUT calls. Now, I know by theory and by experience that a connection handle cannot be used concurrently for MQGETs, it can only be used by one thread at a time using MQCNO_HANDLE_SHARE_BLOCK or MQCNO_HANDLE_SHARE_NO_BLOCK, so in the case of MQGETting apps the client has opted to have separate connection handles.
What's interesting here is that they've been sharing hconns between MQPUTing threads concurrently without a hitch. We're talking hundreds of messages per sec in tests, for months. I've checked out the logs and I don't see any problems or even any blocks - either there's no blocking going on or it's too fast to tell (which?). Have they just been particularily lucky and it won't last? Does anyone know how MQPUT works concerning shared hconns? Is sharing hconns between MQPUTting apps discouraged?
Dotnet, client, MQ V7. Cheers. |
|
| Back to top |
|
 |
| hopsala |
| Posted: Thu Jul 29, 2010 12:47 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 29, 2010 12:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| There wouldn't be much point sharing connection handles if you were to recommend not doing so for MQGETs and MQPUTs! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 29, 2010 1:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I don't think there's anything specific about a PUT that has to be synchronized, as long as two puts are going against a different queue.
The file writes behind the scenes are already buffered and synchronized.
You might see a slight delay if you had several threads executing PUTs simultaneously to the same queue, but ... even then I think it's all going to be pretty fast.
You also probably have significantly fewer thread-collisions on your puts than you think you do.... but it'd be interesting data to collect if you could - how often do your threads think they call mqput at the same exact microsecond... ? |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Jul 29, 2010 1:53 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| zpat wrote: |
| There wouldn't be much point sharing connection handles if you were to recommend not doing so for MQGETs and MQPUTs! |
Well, I was under the impression that you can't concurrently share a connection handle between thread no matter what you do. That is, you can't MQPUT or MQGET at the exact same time in two threads on the same hconn. See Shared (thread independent) connections with MQCONNX.
What's odd is that my client uses the dotnet default connection, meaning that he's supposed to be on the default MQCNO_HANDLE_SHARE_NONE, but we've never seen blocking behavior or gotten MQRC_CALL_IN_PROGRESS.
I'm just wondering if this it's officially supported to use hconn concurrently for MQPUTs. If one day messages start going AWAL I'd like to still be eligible for IBM support.. I'm also wondering how MQPUT works 'under the hood'.
| mqjeff wrote: |
| I don't think there's anything specific about a PUT that has to be synchronized, as long as two puts are going against a different queue. |
Good point. Actually there still are many simultaneous MQPUTs on the same queue, but obviously this diminishes the chance of 'collisions' significantly. I've been measuring total calls, not calls per same queue.
| mqjeff wrote: |
| You also probably have significantly fewer thread-collisions on your puts than you think you do.... but it'd be interesting data to collect if you could - how often do your threads think they call mqput at the same exact microsecond... ? |
Yea, I was thinking the same. Most probably the MQPUTs are so quick that it very rarely happens, or maybe there's a very short default blocking period for all calls regardless of sharing type. Anyhow, I'll try and scrounge up some more data. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 29, 2010 2:09 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Keep in mind as well the changes with V7 where you get a full duplex implementation in TCP/IP. I'm sure this too has some influence. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvic |
| Posted: Sat Jul 31, 2010 2:19 pm Post subject: Re: Connection handle thread safety for MQPUTs |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hopsala wrote: |
| So I have a client who uses one connection handle for a whole bunch of threads in a dotnet application. |
I'm guessing the dotnet layers are handling the necessary synchronization to allow one HConn to be used as you say.
This is supposing that everything you have been told is correct, of course.
Try it in C, and it will fail. You will get a bad cc/rc from the MQI call you make while one is currently in progress. It could even be MQRC_CALL_IN_PROGRESS but it's been a while since I looked at this. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sun Aug 01, 2010 9:57 am Post subject: Re: Connection handle thread safety for MQPUTs |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mvic wrote: |
| I'm guessing the dotnet layers are handling the necessary synchronization to allow one HConn to be used as you say. |
Well, that might be the case, but if it is it's completely undocumented and rather unique to dotnet. Have you seen evidence or read anything to indicate this is the way it works?
| mvic wrote: |
| This is supposing that everything you have been told is correct, of course. |
Since I started this thread I've been wading knee-deep in the client's code, and I've re-written a good potion of it. After running a few tests, it seems that like jeff suggested, there are fewer thread-collisions in the sense of concurrent MQPUT than I thought - in fact there are none, none in the same micro-second. It turned out that they make a lot of calls to log4net, which are synchronized, and so the threads ran sequentially de-facto.
Even after I removed the log statements and created a flushed log buffer I couldn't get it to crash. As usual, it's pretty difficult to test for such things, and you can't really prove that it works, only that it hasn't failed so far. Sadly, before I could create the ultimate testing benchmark I had in mind, they pulled the plug on us, as they simply scratched out the thread-safe requirement from the list and chose to roll out as-is. 
Hopefully I'll be able to complete my tests this week when I have some spare time. Otherwise, the way MQPUTs behaves with one hconn in a threaded env shall forever remain a mystery  |
|
| Back to top |
|
|
| mvic |
| Posted: Sun Aug 01, 2010 2:24 pm Post subject: Re: Connection handle thread safety for MQPUTs |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hopsala wrote: |
| mvic wrote: |
| I'm guessing the dotnet layers are handling the necessary synchronization to allow one HConn to be used as you say. |
Well, that might be the case, but if it is it's completely undocumented and rather unique to dotnet. Have you seen evidence or read anything to indicate this is the way it works? |
No, I have no prior experience or knowledge of dotnet.
But I know that in C, if you try to use (eg. in MQPUT calls) the same shared HConn on multiple threads concurrently you are blocked if you created the HConn specifying the relevant "blocking" MQCNO option, or you get an error if you did not.
Actually, reading down your post, you mention some other de facto serialization from the way the app uses a single-threaded library service. So forget my suggestion that MQ's dotnet layers did serialization: it was only a guess, based on what I had read of your situation. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Aug 01, 2010 2:37 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
I don't think there's anything specific about a PUT that has to be synchronized, as long as two puts are going against a different queue.
The file writes behind the scenes are already buffered and synchronized |
.
Internal buffer writes are also synchronized by WMQ internally (lock management).
I would not refer to this as collisions; rather, it's a very, very brief (nsec or usec) delay for subsequent puts to the same write buffer by any application mix.
_________________
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: Mon Aug 02, 2010 11:38 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| bruce2359 wrote: |
| Quote: |
I don't think there's anything specific about a PUT that has to be synchronized, as long as two puts are going against a different queue.
The file writes behind the scenes are already buffered and synchronized |
.
Internal buffer writes are also synchronized by WMQ internally (lock management). |
They are? So in fact, MQ is thread-safe for MQPuts?
Keep in mind this is a dotnet client, with - as fjb_saper mentioned - a full duplex TCPIP implementation, so there might be further complications concerning communication stacks and MQCMITs.
| bruce2359 wrote: |
| I would not refer to this as collisions; rather, it's a very, very brief (nsec or usec) delay for subsequent puts to the same write buffer by any application mix. |
That really depends, I should think. For example you could send two persistent 50MB messages concurrently.. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Aug 03, 2010 5:48 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| For example you could send two persistent 50MB messages concurrently.. |
There is a difference between concurrent and simultaneous.
Yes, multiple MQPUT calls can be issued at the same precise instance; but internal buffer management software will ensure that these apps do not corrupt the buffer (or disk). This behavior is consistent with database updates.
_________________
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: Tue Aug 03, 2010 7:26 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| bruce2359 wrote: |
| Quote: |
| For example you could send two persistent 50MB messages concurrently.. |
There is a difference between concurrent and simultaneous. |
You're right. I was using the term in its colloquial sense. I really meant simultaneous.
| bruce2359 wrote: |
| Yes, multiple MQPUT calls can be issued at the same precise instance; but internal buffer management software will ensure that these apps do not corrupt the buffer (or disk). This behavior is consistent with database updates. |
Well, it's all in the writing really - either IBM wrote it thread-safe or they didn't. According to mvic they didn't in C - that is, the basic MQI isn't thread safe by default (or is, but returns with error msgs) - but possibly the dotnet interface layers it with synchronization. The question is, do we know this is the case? I have not seen any documentation that says anything but 'hconn is not thread-safe by default'; have you seen any different?
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. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Aug 03, 2010 7:45 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hopsala wrote: |
| According to mvic they didn't in C - that is, the basic MQI isn't thread safe by default (or is, but returns with error msgs) |
My comments might have been mis-interpreted, I think.
In fact, I said no different from what is in the MQ manuals. If you want shared HConns with blocking behaviour, it is easy to ask for them by specifying the right MQCNO_ option.
If you want a non-shared HConn - ie. an HConn that is tied to the thread you are running on, then specify the right MQCNO_ option.
| Quote: |
| but possibly the dotnet interface layers it with synchronization. The question is, do we know this is the case? |
I speculated this might be the case, but I have no evidence - it was only a theory that potentially fitted your description. Now that you mentioned (did I understand you correctly?) your app uses libraries that have synchronization side-effects, the theory is no longer a good one to fit your description.
| 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? |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Aug 03, 2010 7:50 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hopsala wrote: |
| They are? So in fact, MQ is thread-safe for MQPuts? |
I would like to suggest that we avoid the phrase "thread safe" as it seems to mean different things to different people.
The MQI has shared and non-shared HConns.
You can make calls specifying shared HConns on any thread. You will get blocking or non-blocking behaviour, depending on what MQCNO_ options were present in the MQCONN/MQCONNX call. |
|
| Back to top |
|
|
|
|
