| Author | Message | 
		
		  | UncleAndy | 
			  
				|  Posted: Thu Sep 15, 2005 3:18 am    Post subject: Urgent: Multithread issue (C#) |   |  | 
		
		  | Newbie
 
 
 Joined: 15 Sep 2005Posts: 7
 
 
 | 
			  
				| (note: this might be a MQ Server config issue, which is the reason I have posted it under this topic.) 
 Hi,
 
 I am experiencing problems when running multiple threads against my MQ Server. WebSphere MQ v.5.3 (with CSD 10) is installed on a Windows 2000 Server (with decent hardware) and my client is located on a separate box (also Windows 2000 Server).  The client is written in C# and communicates over TCP. Each thread creates a new instance of the queue manager, MQ environment and sender/receiver channels. A dummy server is set up to get messages from one queue and place a response on another which is retrieved from the client.
 
 When the traffic load is "high" (10 simultanious threads..) everything works fine until a certain point when things seem to get clogged up. The 10 threads are started simultaniously and perform 1 request each. When all 10 threads have completed, 10 new threads are spawned and does that same operation. The QM object is created successfully, but when I invoke methods (qMgr.Get(), gMgr.MaximumHandles() etc) I get a null pointer exception and it seems like the QM object has lost connection with the server. The server does not recover from this, and I experience more and more threads throwing exceptions until I shut down MQ and restart it to get a fresh start.
 
 I also experience exceptions identified as MQRC_HOBJ_ERROR, which indicates that an object handle is invalid. The corrective action for this is:
 
 
 
   
	| Quote: |  
	| Ensure that a successful  MQOPEN  call is performed for this object |  
 Do I have to put in a check for each time I use the QM object to see if it's still "open"? If so, how can this done?
 
 Single thread works fine, and as mentioned above multiple threads also work fine until a certain point.
 
 This is critical to us right now, and I need to sort this out ASAP. I would appreciate any help!
 
 Thanks!
 
 Andreas[/b]
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | jsware | 
			  
				|  Posted: Thu Sep 15, 2005 3:41 am    Post subject: |   |  | 
		
		  |  Chevalier
 
 
 Joined: 17 May 2001Posts: 455
 
 
 | 
			  
				| I'm no C# expert, but... 
 When you run your program, watch the status of your queue (assuming you're running WMQ 5.3) and the number of readers.  Also check the number of instances of the client channel you are connecting through.
 
 You may not be closing connections/queues when each thread terminates.  Eventually MQ will refuse any more connections and not allow you to open the queue when each new thread starts up.  If you do not explicitly close the connection/queue, then this may not happen until the objects are garbage collected.
 _________________
 Regards
 John
 The pain of low quaility far outlasts the joy of low price.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | UncleAndy | 
			  
				|  Posted: Thu Sep 15, 2005 3:45 am    Post subject: |   |  | 
		
		  | Newbie
 
 
 Joined: 15 Sep 2005Posts: 7
 
 
 | 
			  
				| I checked it out and one queue had 10 open handles (and I have not run the tests for a while). I will investigate this, and make sure everything is closed properly after use. 
 Thank you very much!
 
 Andreas
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | UncleAndy | 
			  
				|  Posted: Thu Sep 15, 2005 4:10 am    Post subject: |   |  | 
		
		  | Newbie
 
 
 Joined: 15 Sep 2005Posts: 7
 
 
 | 
			  
				| OK, it's clear that when I run multiple threads, the handles aren't always released. This might be the problem (even though it should be able to deal with 256 open handles..). 
 After completion of the processing in my client I run the following commands:
 
 receiver_queue.Close()
 sender_queue.Close();
 queue_manager.Disconnect();
 queue_manager.Close();
 
 When this is done, only the first message is procesed and the rest of the threads fail. Seems like this code interferes with all the other threads, so which connections / objects should I close and which should remain open? Is there a command for "cleaning up" after use?
 
 Andreas
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | kevinf2349 | 
			  
				|  Posted: Thu Sep 15, 2005 5:39 am    Post subject: |   |  | 
		
		  |  Grand Master
 
 
 Joined: 28 Feb 2003Posts: 1311
 Location: USA
 
 | 
			  
				| I believe you need to use the Dispose method 
 receiver_queue.Dispose
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | UncleAndy | 
			  
				|  Posted: Mon Sep 19, 2005 5:38 am    Post subject: |   |  | 
		
		  | Newbie
 
 
 Joined: 15 Sep 2005Posts: 7
 
 
 | 
			  
				| I am not able to find the Dispose() method for my objects, but I have changed my tactics. I am now creating one instance of the QM object, which greatly improved the performance and stability. 
 I still have problems when traffic is high. What happens is that I get a null pointer exception when I try to access the queues (either through QueueManager.AccessQueues or QueueManager.Get/Put).
 
 Does anyone know the cause of this? Is the MQ Server dropping connections because the number is too high? I have tried to increase the values for:
 
 MaxChannels (1024)
 MaxActiveChannels (1024)
 MaxInitiators (32)
 ListenerBackLog (512)
 EntryPoints (100)
 
 - all config settings for the QM available through the MQ Services console.
 
 Any other settings I should look at?
 
 Andreas
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | JasonE | 
			  
				|  Posted: Tue Sep 20, 2005 3:56 am    Post subject: |   |  | 
		
		  | Grand Master
 
 
 Joined: 03 Nov 2003Posts: 1220
 Location: Hursley
 
 | 
			  
				| Note: This is also cross posted and I answered the other first... 
 The C# layer happily handles multithreaded applications. Each constructed MQQueueManager object has a connection to the queue manager, and each queue is associated with one of the MQQueueManager objects. Making the application single threaded may avoid a problem in your code, but as far as I am aware (and lots of people use multithreaded .net code) there is nothing wrong with MQ's layer.
 
 However, I will also add that you should try on a recent level of the .net code, just in case...
  |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  |  |