| Author |
Message
|
| maneshgurav |
 Posted: Tue Apr 25, 2006 1:47 pm Post subject: MQ 5.3 .Net APIs in multithreaded environment or web service |
 |
|
Novice
Joined: 20 Apr 2006
Posts: 12
|
Hi All,
We have 5 different .Net applications talking to MQ. So we planned to develop a VB.Net Class Library with the common functionality (Connect, Disconnect, PutMessage, GetMessage, etc). All the 5 applications will later use this library (DLL). Each application will use its own copy of the library. Now we are planning to implement it through a .Net Web Service, instead of the Class Library, with the same interface. But I have heard that all the calls to the Queue Manager through .Net APIs are serialized.
1. Does it mean that when my web service receives 100 requests (connect, get, put) at a time, it will process them one-by-one?
2. Are there any reported issues/problems, when the MQ 5.3 .Net APIs are used in a multithreaded environment or a web service?
Any help will be appreciated...
Thank you,
Manesh |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Apr 25, 2006 4:20 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So let's be clear.
You are going to use MQ to connect applications across the network.
But you are going to use WebServices to connect across the network in order to connect across the network?
One or the other, please.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| maneshgurav |
| Posted: Tue Apr 25, 2006 6:13 pm Post subject: |
|
|
Novice
Joined: 20 Apr 2006
Posts: 12
|
I am sorry. I think, I could not explain the problem clearly.
We have 5 different VB.Net applications that need to communicate with a mainframe system through MQ Series. Since they will be having some functionality common among them (Connect, Disconnect, PutMessage, GetMessage, etc), we thought of putting the common functionality into a library (DLL). But now we are planning to implement the common functionality through a .Net Web Service. All the 5 applications will invoke this common web service for MQ-related functions. But since all the calls to the Queue Manager through .Net APIs are serialized, I have those 2 questions.
Thanks Again,
Manesh |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 25, 2006 7:13 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You connect to a WebService by establishing a network connection. That is what 'web' means, right? "http", which is a network protocol.
You then propose to have the other end of that Web Service connection use MQSeries to establish a different kind of network connection.
Why not just put Apache Tomcat on the mainframe, and just use Web Services in the first place?
Or go back to the other way, of using a shared class library.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| questro |
| Posted: Tue Apr 25, 2006 11:41 pm Post subject: Re: MQ 5.3 .Net APIs in multithreaded environment or web ser |
|
|
Newbie
Joined: 07 Mar 2006
Posts: 9
Location: Magic Land
|
| maneshgurav wrote: |
| ...I have heard that all the calls to the Queue Manager through .Net APIs are serialized. |
The calls are not serialized. There may be some implicit serialization caused by the MQ trace calls on 5.3 - even this implicit serialization should be removed in 6.0.
If you have multiple threads each connecting to a queue manager, none of the methods are explicitly serialized - obviously, serializations may occur as shared resources are locked to one or other MQI call inside the queue manager. |
|
| Back to top |
|
|
| maneshgurav |
| Posted: Wed Apr 26, 2006 4:55 am Post subject: |
|
|
Novice
Joined: 20 Apr 2006
Posts: 12
|
Thank you, jefflowrey. The mainframe is not in our environment. We do not have any control on it. The only way to communicate with it is through MQ Series. So we are planning to have a Web Service for MQ Communications. All the applications that need to communicate with MQ will in turn communicate with this Web Service. Since it will be like a generic online library, any future applications can also use it.
Thank you, questro. The online book, 'Websphere MQ Using .Net (5.3)' says, 'The .NET runtime environment is inherently multithreaded. Therefore, your application initialization occurs in one thread, and the code that executes in response to the button press executes in a separate thread (the user interface thread). The implementation of WebSphere MQ .NET ensures that, for a given connection (MQQueueManager object instance), all access to the target WebSphere MQ queue manager is synchronized. The default behaviour is that a thread that wants to issue a call to a queue manager is blocked until all other calls in progress for that connection are complete. If you require simultaneous access to the same queue manager from multiple threads within your program, create a new MQQueueManager object for each thread that requires concurrent access. (This is equivalent to issuing a separate MQCONN call for each thread.) If the default connection options are overridden by MQC.MQCNO_HANDLE_SHARE_NONE or MQC.MQCNO_SHARE_NO_BLOCK then the queue manager is no longer synchronized.' That means, I should create a separate instance of the Queue Manager in each thread. Can I create an instance of the Queue Manager on starting a session in the Web Service and use it through out the session? Has anybody implemented it before? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 26, 2006 5:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| maneshgurav wrote: |
| Thank you, jefflowrey. The mainframe is not in our environment. We do not have any control on it. The only way to communicate with it is through MQ Series. So we are planning to have a Web Service for MQ Communications. All the applications that need to communicate with MQ will in turn communicate with this Web Service. Since it will be like a generic online library, any future applications can also use it. |
I wasn't seriously suggesting putting Tomcat on your mainframe. (You'd need Geronimo or WebSphere Community Edition anyway).
If you persist in using Web Services for this, you have eliminated in one single stroke all of the possible benefits that your applications can derive from using MQ in the first place, and shackled them all with the limitations of the HTTP transport. Among other things, you will have significant difficulties driving an MQ request/reply across Web Services. Web Services(HTTP) is synchronous, you must wait until the reply has come in before the client can receive it's data. MQ is asynchronous, even in request/reply, and it could easily (and be perfectly acceptable) exceed the HTTP timeout before you get the MQ reply.
Using a webservice like this is a bad idea and will cause you problems. It is not an architectural best practice, it is not a design best practice.
What you should consider instead, perhaps, is building Web Services that provide interfaces to specific business functions on the mainframe. So, for example, your mainframe has a specific business transaction ('process an order', or etc.) that is accessed by an MQ queue. Then you can re-expose that TRANSACTION as a Web Service, and put the MQ logic behind the web service interface.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| maneshgurav |
| Posted: Wed Apr 26, 2006 9:05 am Post subject: |
|
|
Novice
Joined: 20 Apr 2006
Posts: 12
|
| Thank you for the suggestions, jefflowrey. |
|
| Back to top |
|
|
| Leigh Kendall |
| Posted: Wed Apr 26, 2006 11:32 am Post subject: |
|
|
Acolyte
Joined: 10 Apr 2003
Posts: 66
Location: Hartford, CT
|
Just sign your assembly and let each server install a copy in it's GAC. When a new version is released, everyone installs a new copy. Simple.
_________________
Leigh Kendall |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 26, 2006 3:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Leigh Kendall wrote: |
| Just sign your assembly and let each server install a copy in it's GAC. When a new version is released, everyone installs a new copy. Simple. |
Remember you need to have at least an MQClient on each of the machines you are pushing that code to.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| maneshgurav |
| Posted: Thu Apr 27, 2006 4:37 am Post subject: |
|
|
Novice
Joined: 20 Apr 2006
Posts: 12
|
Thank you, Leigh Kendall.
Thank you, fjb_saper.
Yes, I have to install the MQ Client on all the machines running these applications. That is one of the reasons why we wanted to go for the Web Service. But now I have started building the Assmbly!  |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Sep 23, 2007 11:49 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I am interested in reducing the number of MQ client connections from our web servers to MQ.
Using MQCNO_SHARE_NO_BLOCK (or BLOCK) is one way to re-use (share) connection handles amongst threads.
I think I understand the issues with doing this but would be interested in hearing from anyone who is sharing handles using .NET and how they do allocate and assign the handles to the threads? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Sep 24, 2007 12:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It would have been nice if you'd started a new thread, zpat...
You should never plan for fewer client connections than you have GET with WAITs.
More generically, you can never have fewer client connections than you have simultaneous MQ client operations. MQCNO_SHARE_NO_BLOCK only allows one connection handle to be used across all threads in a single application - i.e. it allows you to build a connection pool. It doesn't allow you to use a connection to PUT a message at the same time that another thread is GETTING a message.
Connection pools are always a good idea. It may or may not be worth the analysis necessary to figure out the absolute minimum number of connections that a specific application has to have.
In general, connection handles are allocated from a pool on request - and the request determines if there's a free connection to hand out, or if it has to create a new one. A thread will getConnection(), for example, do work with the connection, and then releaseConnection().
The pool implementation handles everything else, including deciding how many connections to keep open at a time.
There's some built-in connection pooling in the Java API. There may or may not be the same in the .NET API.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
