| Author |
Message
|
| codemonkey |
 Posted: Fri Aug 27, 2010 12:52 pm Post subject: Help With C# 4 Parallel Prog. and MQ Async Connection Archit |
 |
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
Sorry ran out of room in the subject line. The last word is “Architecture”.
I’m working on a prototype for a very high volume application that does around 5 million transactions in a 15 hour time period. Each transaction ranges from 10KB to 15KB in size. I’m not interested in discussing MQ server setup or hardware. That’s all taken care of. What I need help with is architecting an abstract wrapper for the latest IA9H: IBM Message Service Client for .NET v2.0.0.2. We have the latest MQ server setup.
I’m looking for some resources (books, articles, blogs etc.) that will help me make the right choices when building the solution to handle a high and growing transaction volume. The most important piece is the actual send message throughput. For example, when connecting asynchronously, do I want to spawn a dynamic number of new tasks (threads) inside a single connection state, or do I want to create a new IConnection for each task? Also has anyone implemented anything like this using best practices parallel programming patterns?
The application that will be posting to the queue, will be sending messages to a WCF service, and the service will manage the publish. The connection between the app and the service is critical and should be less than a 2 digit millisecond. The connection between the WCF service and MQ will be equally critical. The queue subscription is not as critical and will be managed by a polling windows service.
If there’s a book or blog or article that you can recommend that would be great. If you can provide some code samples, or have some knowledge, wisdom to share that would be great as well. If you need additional details, please feel free to ask. Thanks for your help. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Aug 27, 2010 1:58 pm Post subject: Re: Help With C# 4 Parallel Prog. and MQ Async Connection Ar |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| codemonkey wrote: |
Sorry ran out of room in the subject line. The last word is “Architecture”.
I’m working on a prototype for a very high volume application that does around 5 million transactions in a 15 hour time period. Each transaction ranges from 10KB to 15KB in size. I’m not interested in discussing MQ server setup or hardware. That’s all taken care of. What I need help with is architecting an abstract wrapper for the latest IA9H: IBM Message Service Client for .NET v2.0.0.2. We have the latest MQ server setup. |
If you have the latest server set up (and presumably the latest client) you should know that the IA9H pack is going to screw things up. It has been incorporated into the product with V7 and if you installed the support pack you may not have a working version. Make sure you ask also for the latest fixes as there are a few concerning the .NET area...
| codemonkey wrote: |
| I’m looking for some resources (books, articles, blogs etc.) that will help me make the right choices when building the solution to handle a high and growing transaction volume. The most important piece is the actual send message throughput. For example, when connecting asynchronously, do I want to spawn a dynamic number of new tasks (threads) inside a single connection state, or do I want to create a new IConnection for each task? Also has anyone implemented anything like this using best practices parallel programming patterns? |
You are free to do as you wish. However be aware that the connection is serializing your messages. So if you wish true parallelism you will need multiple connections. You might also want to turn off conversation sharing.
| codemonkey wrote: |
The application that will be posting to the queue, will be sending messages to a WCF service, and the service will manage the publish. The connection between the app and the service is critical and should be less than a 2 digit millisecond. The connection between the WCF service and MQ will be equally critical. The queue subscription is not as critical and will be managed by a polling windows service.
If there’s a book or blog or article that you can recommend that would be great. If you can provide some code samples, or have some knowledge, wisdom to share that would be great as well. If you need additional details, please feel free to ask. Thanks for your help. |
There was a post earlier (in the last 2 days that mentioned technical delay) that you want to check out for the links and information. You may also want to check out the link at the top of the page to best practices.
I trust you have already found the links to the manuals. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Aug 28, 2010 6:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You might also consider the WCF channel into MQ instead of using an app as a bridge.
I do not make any claims on it's performance, but it is in your best interest to evaluate it as a potential solution. |
|
| Back to top |
|
|
| codemonkey |
| Posted: Sat Aug 28, 2010 9:58 am Post subject: |
|
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
Thanks for the replies.
@fjb_saper: Well, we're using version 7. Thought that was the latest version. Interesting I didn't know that MQ serializes. I downloaded IA9H from IBM's site, so I'm assuming I have the latest updates?
So, can MQ handle multiple threads inside a single connection assuming it's configured to handle this?
Yes I do have the documentation and code samples that came with the IA9H download. None of their examples illustrate any mention of parallel options.
@mqjeff: Can you elaborate on the WCF channel into MQ? or know where I can find some additional reading on this? I agree, I definitely want to evaluate as many options as I can to ensure that I've covered all the bases. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Aug 28, 2010 10:22 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| codemonkey wrote: |
Thanks for the replies.
@fjb_saper: Well, we're using version 7. Thought that was the latest version. Interesting I didn't know that MQ serializes. I downloaded IA9H from IBM's site, so I'm assuming I have the latest updates?
So, can MQ handle multiple threads inside a single connection assuming it's configured to handle this?
Yes I do have the documentation and code samples that came with the IA9H download. None of their examples illustrate any mention of parallel options.
|
My point was that with the latest version of V7 you corrupted your installation downloading IA9H (XMS) as this functionality is now part of the product (since V7).
MQ will handle multiple threads just fine. They will still be serialized through the single connection... (this has performance implication if the volume is sufficient for it to matter).
Nothing mentioned parallel options in your download because it is not geared towards V7. The download is for prior versions or early version of V7 when it was a support pack that was not part of the product.
Read up on V7, on channel behavior and conversation sharing and be aware that if you want to go the conversation sharing route you should be at a minimum of V7.0.1.4....
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Aug 28, 2010 11:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| codemonkey |
| Posted: Mon Aug 30, 2010 6:52 am Post subject: |
|
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
| fjb_saper wrote: |
| codemonkey wrote: |
Thanks for the replies.
@fjb_saper: Well, we're using version 7. Thought that was the latest version. Interesting I didn't know that MQ serializes. I downloaded IA9H from IBM's site, so I'm assuming I have the latest updates?
So, can MQ handle multiple threads inside a single connection assuming it's configured to handle this?
Yes I do have the documentation and code samples that came with the IA9H download. None of their examples illustrate any mention of parallel options.
|
My point was that with the latest version of V7 you corrupted your installation downloading IA9H (XMS) as this functionality is now part of the product (since V7).
MQ will handle multiple threads just fine. They will still be serialized through the single connection... (this has performance implication if the volume is sufficient for it to matter).
Nothing mentioned parallel options in your download because it is not geared towards V7. The download is for prior versions or early version of V7 when it was a support pack that was not part of the product.
Read up on V7, on channel behavior and conversation sharing and be aware that if you want to go the conversation sharing route you should be at a minimum of V7.0.1.4....
Have fun |
Great. What do I need to do to remedy the corruption? Do I need to uninstall the client and re-install? It would have been nice if IBM would have put a note about that on the download site. I'll check out the options on conversation sharing. Or better yet, which IBM MQ assembly should I be referencing inside my .NET projects?
Thanks for the tip.
@mqjeff, Thanks for the link. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 30, 2010 7:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| codemonkey wrote: |
| Great. What do I need to do to remedy the corruption? Do I need to uninstall the client and re-install? |
| codemonkey wrote: |
| It would have been nice if IBM would have put a note about that on the download site. |
The page here does say that the support pac is only for 5.0 & 6.0 and not 7.0 (document information box on the right) though I do agree something a bit more definative (like including the words "not 7.0") might be clearer.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| codemonkey |
| Posted: Mon Aug 30, 2010 11:57 am Post subject: |
|
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
| Vitor wrote: |
| codemonkey wrote: |
| Great. What do I need to do to remedy the corruption? Do I need to uninstall the client and re-install? |
| codemonkey wrote: |
| It would have been nice if IBM would have put a note about that on the download site. |
The page here does say that the support pac is only for 5.0 & 6.0 and not 7.0 (document information box on the right) though I do agree something a bit more definative (like including the words "not 7.0") might be clearer. |
Well there's a note below the prereqs section:
"NOTE 1: If using WebSphere MQ, the machine used to run the XMS application must be installed with the WebSphere MQ Client V7.0.1.0 or later (these libraries are pre-installed on machines with a local queue manager of an appropriate level). These support 'client' mode connections to V5.3,V6.0 and V7.0 queue managers or 'bindings' mode connection to a local queue manager of an appropriate level."
Regardless, I just need to know which assembly and assembly version I need to reference from my code to connect to the queue properly for V. 7 and above. Does anyone know?
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 30, 2010 12:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| codemonkey wrote: |
| Regardless, I just need to know which assembly and assembly version I need to reference from my code to connect to the queue properly for V. 7 and above. Does anyone know? |
Well .NET is not my strongest suit, but all I've ever done is follow the instructions in the manual mqjeff posted the link to; installed the client, referenced amqmdnet and specified "Using".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 30, 2010 12:30 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| referenced amqmdnet and specified "Using". |
Alas, that's for .NET API, not XMS for .NET.
Regardless, it should be the assembly that comes with the client install, and not referencing any files that comes with the SupportPac download. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 30, 2010 12:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Alas, that's for .NET API, not XMS for .NET. |
I said .NET wasn't my strongest language. Sight better than my Java though... 
| mqjeff wrote: |
| Regardless, it should be the assembly that comes with the client install, and not referencing any files that comes with the SupportPac download. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| codemonkey |
| Posted: Tue Aug 31, 2010 1:10 pm Post subject: |
|
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
| mqjeff wrote: |
| Vitor wrote: |
| referenced amqmdnet and specified "Using". |
Alas, that's for .NET API, not XMS for .NET.
Regardless, it should be the assembly that comes with the client install, and not referencing any files that comes with the SupportPac download. |
I'm sorry guys. Forgive me, I'm not following. Is this the "SupportPac" download? http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24011756
I'm presently referencing "IBM.XMS.dll". So you're saying I should reference this guy "amqmdnet" instead? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 31, 2010 1:27 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| codemonkey wrote: |
| mqjeff wrote: |
| Vitor wrote: |
| referenced amqmdnet and specified "Using". |
Alas, that's for .NET API, not XMS for .NET.
Regardless, it should be the assembly that comes with the client install, and not referencing any files that comes with the SupportPac download. |
I'm sorry guys. Forgive me, I'm not following. Is this the "SupportPac" download? http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg24011756
I'm presently referencing "IBM.XMS.dll". So you're saying I should reference this guy "amqmdnet" instead? |
You should reference the IBM.XMS.dll that is installed by the base product, and not by the IBM.XMS.dll that is in the supportPac download that you have linked to.
That is, you should find a copy of IBM.XMS.dll under c:\program files\IBM\WebSphere MQ\bin\ (or otherwise under <mq_install_root>\bin), and you should be using that one. You should NOT be using any copy of IBM.XMS.dll that you downloaded from the link you have posted.
Neither should you be using amqmdnet either, as that is the regular .NET API for WebSphere MQ, and not the XMS API for .NET for WebSphere MQ. It's an entirely different API, VisualStudio would immediately claim that half your code was referencing things that didn't exist. |
|
| Back to top |
|
|
| codemonkey |
| Posted: Wed Sep 01, 2010 6:57 am Post subject: |
|
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
@mqjeff
Thank you for the clear explanation. Can you tell me why I should be using the XMS assembly from the client install rather than the supportpac?
I did a BitDiffer on the 2 assemblies to compare them and identify any differences that may exist. BitDiffer revealed that the assemblies are identical and contain no differences between them. The version numbers on these assemblies are identical also. It's not that I'm doubting you, I'm just trying to understand what the differences are between them, so that when someone from my team asks, I'll have a logical answer. At the present moment, I can't see any differences and I have no explanation.
Thanks. |
|
| Back to top |
|
|
|
|
