I have written a COM object for MQ in VB that hides the complexity of MQ from our web developers.
The Com object loads driver data from a file which tells it what Queue manager to connect to and which queues to open and the type of service that should be executed e.g a send and recieve (commonly refered to as a round trip) or a send and forget.
Each driver file record is associated with a business process e.g. get a customer.
The Web pages access a business object which runs on the MTS server and the the business object calls the service on the wrapper.
The client is a web page so I have created the wrapper so that it reloads the driver file or state each time the client changes when it does this it connects to the MQ manager and then opens the queues needed to complete the service and then does a send or a send and receive gets the message back and will close the queues and disconnects.
When it does this there seems to be a large CPU hit on my development machine with 3 concurrent users all hitting submit on a web page at the same time the CPU goes to 100%
I have identified that the CPU hit is generated when connecting and then opening the queues required.
I would like to be able to open a pool of connection and queue objects for each service on the server so that the wrapper service when called will use these exsisting objects to issue the puts and gets I would have properties on these to activate and passivate them.
However I went on a course that suggested that object pooling will not work in VB and MTS due to thread affinity issues.
I then thought of creating my own pooled connection objects using a singleton to control and connect to the service pool of connection objects.
I read some articles and one by Don Box suggested that the MTS programming model discourages this, and you should go down the route of sharing state between multiple com objects in the shared pool manager.
Then I read in the IBM MQ COM programmers manual that using the connection handle with a different threads will cause a
MQRC_HCONN_ERROR because MQ series will not share connection handles accross threads.
I would appreciate any help or suggestions of how I could keep the connections and queues open for a service being used by many clients concurrently, so I dont get the CPU overhead for every client.
I have thought of storing the connections in a collection using the thread id as the key to access them for each client since then the Thread and the connection handle would be the same and so there should not be a problem.
I was not sure that the operating system would allocate the thread to the same process but a different client. Therefore I would end up with lot of open connections and queue handles with no way to close them.
I was also aware that the thread might be the same but the service could be different and so I could use the connectiion but not the queue handles since we are using different queues for different services.
We are runnibg Windows NT, VB 6 and MTS and have no plans to move to .NET
alanmcl
The Com object loads driver data from a file which tells it what Queue manager to connect to and which queues to open and the type of service that should be executed e.g a send and recieve (commonly refered to as a round trip) or a send and forget.
Each driver file record is associated with a business process e.g. get a customer.
The Web pages access a business object which runs on the MTS server and the the business object calls the service on the wrapper.
The client is a web page so I have created the wrapper so that it reloads the driver file or state each time the client changes when it does this it connects to the MQ manager and then opens the queues needed to complete the service and then does a send or a send and receive gets the message back and will close the queues and disconnects.
When it does this there seems to be a large CPU hit on my development machine with 3 concurrent users all hitting submit on a web page at the same time the CPU goes to 100%
I have identified that the CPU hit is generated when connecting and then opening the queues required.
I would like to be able to open a pool of connection and queue objects for each service on the server so that the wrapper service when called will use these exsisting objects to issue the puts and gets I would have properties on these to activate and passivate them.
However I went on a course that suggested that object pooling will not work in VB and MTS due to thread affinity issues.
I then thought of creating my own pooled connection objects using a singleton to control and connect to the service pool of connection objects.
I read some articles and one by Don Box suggested that the MTS programming model discourages this, and you should go down the route of sharing state between multiple com objects in the shared pool manager.
Then I read in the IBM MQ COM programmers manual that using the connection handle with a different threads will cause a
MQRC_HCONN_ERROR because MQ series will not share connection handles accross threads.
I would appreciate any help or suggestions of how I could keep the connections and queues open for a service being used by many clients concurrently, so I dont get the CPU overhead for every client.
I have thought of storing the connections in a collection using the thread id as the key to access them for each client since then the Thread and the connection handle would be the same and so there should not be a problem.
I was not sure that the operating system would allocate the thread to the same process but a different client. Therefore I would end up with lot of open connections and queue handles with no way to close them.
I was also aware that the thread might be the same but the service could be different and so I could use the connectiion but not the queue handles since we are using different queues for different services.
We are runnibg Windows NT, VB 6 and MTS and have no plans to move to .NET
alanmcl