| Author |
Message
|
| kolban |
 Posted: Mon Sep 16, 2002 4:20 am Post subject: |
 |
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
| What error is returned following a put/get after the timeout? |
|
| Back to top |
|
 |
| Prophet |
| Posted: Thu Sep 19, 2002 11:05 am Post subject: Re: How do I reset Mqseries.net |
|
|
Novice
Joined: 19 Jul 2002
Posts: 16
|
| Glen_T_Dudley wrote: |
I have downloaded your examples.
I created a small test app in VB.NET
with 2 buttons and 2 textboxs
Get button retrieves a message from queue
Put places message in Queue
I can do thisw fore ever until I try to get when there is not
a message in queue. When I get the time out error
I can never put or get again until I close and restart the app.
Is there a method of reseting the mqseries object so I can
continue to put and get?
I can provide source if needed.
Dudley |
We had the same issue. The behavior that we noticed was; if the MQ Assembly throws an error and you try to call the assembly again, it fails. The way we got around this was to wrap the MQ assembly method calls in Try Catch blocks. When an error occurs, we disconnect from the queue manager and rethrow the error to the calling assembly.
_________________
Bobby Ledford
Lead Architect
TSYS |
|
| Back to top |
|
|
| kolban |
| Posted: Thu Sep 19, 2002 11:49 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
You may have noticed that Ive been quiet on this topic/package for a while. IBM development are looking at the implications of picking it up and formally supporting it themselves. Hopefully news will be forthcoming soon. If a full development team of 9-5 folks will be working on the package, my motivation for picking at bugs at this point is quite low allowing me to work on other pet-projects.
If/when IBM development pick it up, it should have the same interfaces, same usage patterns but will have defects/problems addressed formally and be fully supported. I would also assume that this would also imply manuals, performance testing and, above all, true functional and integration testing ... something that y'all have been doing for me. |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Sep 19, 2002 12:49 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Congrats Neil! Hopefully if IBM decides to support the .NET package, your MQJExplorer tool will be soon to follow? 
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| zinkjo |
| Posted: Tue Sep 24, 2002 5:10 am Post subject: 2035 Error |
|
|
Newbie
Joined: 24 Sep 2002
Posts: 1
|
| I just downloaded the assembly and I am in the process of getting the samples up and running. I have MQ Client 5.2 on my machine and have tested it successfully. When I try to run the samples (listqueues or simpleput) I get a 2035 error. I'm not a MQ expert but I believe our queues are protected on the mainframe. When I run the MQ Client I believe it picks up the process id and uses that to connect to the host. Do I have to do anything special (setting userid property ?) to get the .net stuff to work ? |
|
| Back to top |
|
|
| agevans |
| Posted: Tue Sep 24, 2002 8:55 am Post subject: MQ.dll |
|
|
Newbie
Joined: 24 Sep 2002
Posts: 1
|
This is a nice port of the MQ Java base classes. Thanks for doing all the hard work! I am wondering why you did not implement the full interface. Several functions are missing from the MQMessage class for instance:
setPutApplicationName
setPutApplicationType
setApplicationIdentityData
and several other context fields.
I also noticed that not all of the MQPMO_* values were implemented in the MQC class. Will you be implementing MQPMO_SET_ALL_CONTEXT and other context related options?
If not are you going to make the source code available so that others could add these features in themselves?
Thanks for all the hard work! |
|
| Back to top |
|
|
| Prophet |
| Posted: Thu Sep 26, 2002 8:40 am Post subject: BUG ALERT for Neil |
|
|
Novice
Joined: 19 Jul 2002
Posts: 16
|
Neil, we have been using the handler now for a while to test it out. However, when we move it to our QA environment we run into a very serious issue.
Your objects do not implement the IDispose interface. This is a standard technique in .NET when you have to access unmanaged resources(Like MQ Handles)
Basically by implementing IDispose you guarantee that the resources are cleaned up after themselves when an object goes out of scope. The CLR will automatically call Dispose for you. Otherwise, when heavy loads start occuring, you start getting 2002- MQRC_ALREADY_CONNECTED errors and there is nothing you can do but shut down the calling services and bring them back up.(Another way around this is to guarantee the calling applications always call disconnect but it is very dangerouse to depend on other developers to know to do this as evident by some of the errors we are getting.
I have an example of using IDispose when we built a socket class that used TCP sockets for some other process:
\\simply implements the IDisposable interface
public class TcpPacketizer : IDisposable
\\create a destructor that will call Dispose
~TcpPacketizer()
{
//
// dispose this object
//
Dispose(true);
}
\\The dispose method as must be implemented because of the interface
public void Dispose()
{
//
// dispose this object
//
Dispose(true);
}
\\The private Dispose called by the public method
void Dispose(bool disposing)
{
//
// if we are being disposed then suppress finalization
//
if (disposing)
{
GC.SuppressFinalize(this);
}
//
// Dispose of the unmanaged resources
//
Disconnect();
This is pretty much the exact method that is used in the .NET help under "Implementing a Dispose Method"
Anyway you could get this implemented within MQSeries.NET? Or possibly send us the source and we would gladly help you out(obviously send you back the changed source). We are sort of in a time crunch as we wanted to use it in a preliminary production build to evaluate the use even further.
If you want to contact me directly, BLedford@TSYSTSOL.COM
_________________
Bobby Ledford
Lead Architect
TSYS |
|
| Back to top |
|
|
| kolban |
| Posted: Sat Sep 28, 2002 7:06 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
I think that the idea here is to explicitly close an object that is no longer needed. This will release any resources in a timely manner.
In the example you gave, the error you got was
MQRC_ALREADY_CONNECTED
What this seems to say to me is that you had an MQQueueManager object that was connected to a queue manager, the reference count to the object reached zero and you then created a new instance of it. Unfortunately, the old instance, although out of scope, had NOT been garbage collected and hence had not had its internal resources freed.
If you had called Close() on the object prior to letting its reference count reach zero, all would have been well. |
|
| Back to top |
|
|
| Prophet |
| Posted: Sat Sep 28, 2002 7:50 am Post subject: |
|
|
Novice
Joined: 19 Jul 2002
Posts: 16
|
The object that referenced the MQHandle does get garbage collected. However the handle does not. Because it is an unmanaged resource, unless IDispose is implemented the CLR does not know what to do with it. IDispose is designed to allow you to tell the CLR how to gracefully get rid of unmanaged resources. The handle thusly becomes a memory leak and more importantly in this case, it becomes an application failure because MQ still thinks the handle is valid.
If an untrapped error occurs anywhere in anyones code that utilzies MQ.dll on that server while an MQObject is open, all other applications come to a grinding halt because the resources were not released and no other request can open a connection to the queue manager.
In a web or client server application this would effectively shut everything down. The only way to correct the error is to wait for the Queue Manager connection to time out. The corrsponding code that has a reference to the MQObject would have to understand how to shut down the connection. Applications that call a wrapper really should have to know nothing about how MQ works under the covers.
This is pretty scary to me. Knowing that another unbehaved application that is installed on this server at an ISP for instance can effectively lock up my application as well and there is nothing I can do about it.
IDispose was designed so that this would not be allowed to happen. All unmanaged wrappers(ODBC, Sockects, Screen scrapers, drivers, etc) are supposed to implement IDispose. It is impossible for any resource to remain in an open state if IDispose is implemented because the CLR takes care of calling Dispose when the object reference goes out of scope.
If necessesary, we would be willing to pay for the MQ wrapper and your time. We just don't want to have to do it ourselves and set our time tables back a 2-3 weeks.
.
_________________
Bobby Ledford
Lead Architect
TSYS |
|
| Back to top |
|
|
| kolban |
| Posted: Mon Sep 30, 2002 5:25 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Bobby,
Am with you .. am also doing research.
I am still a little confused. If an object documents that its Close(), Dispose(), or Terminate() method should be called when no longer needed and the implementation of that method explicitly deletes or frees un-managed resources, then wouldn't letting an object go out of scope before calling that method be considered a bad practice and, worse, an explicit application coding bug?
If an object implements a finalizer that internally releases the resource, then "eventually" the object will release the resource when it is garbage collected.
If an object implements Dispose() (IDisposable) then I see that interface/method as an architected way to dispose of resources. i.e. forcing the cleanup name to be Dispose() as opposed to Close() or Terminate() etc etc but still doesn't say when it will be called if not explicitly called in the application.
-----------------
Please be aware, IBM is looking at this code base as a potential component of MQ itself. As such, I can't simply release as open source (which I now think I would personally like to do .... go figure).
IBM development is watching this forum/topic.
Neil |
|
| Back to top |
|
|
| Prophet |
| Posted: Mon Sep 30, 2002 7:16 am Post subject: |
|
|
Novice
Joined: 19 Jul 2002
Posts: 16
|
It would definately be bad practice to not follow a documented close procedure before an object went out of scope. But it does happen. So it would be beneficial to implement a deconstructor to automatically release the resources.
I went ahead and implemented the IDispose design pattern in our code so it isn't that big of an issue for us. We also are disconnecting everywhere where an error could occur so I think we have pretty much covered ourself.
This is a problem however with any MQ Implementation using .NET. Maybe the IBM gurus could figure something out. Basically if someone does not call a method that disconnects from the Queue Manager, and they are not using a shared handle, they will have to wait for the garbage collector to run before the resources are freed up.
This would freeze their application until the garbage collector runs. I don't know if their is a good answer to the problem. The best thing is to probably implement IDIspose, do code reviews to make sure that the applications are all disconnecting before the MQ component goes out of scope.
_________________
Bobby Ledford
Lead Architect
TSYS |
|
| Back to top |
|
|
| BrentW |
| Posted: Mon Sep 30, 2002 10:14 am Post subject: Build problem? |
|
|
Newbie
Joined: 30 Sep 2002
Posts: 1
|
I know this is probably something simple, but anyway I am new to .net, I created a small test pgm to test the mq .net api's how do I reference the MQ.dll so as to eliminate my build errors.
By the way thanks for creating the MQ .net api's.
Brent |
|
| Back to top |
|
|
| Prophet |
| Posted: Mon Sep 30, 2002 10:24 am Post subject: Re: Build problem? |
|
|
Novice
Joined: 19 Jul 2002
Posts: 16
|
In the solution explorer for your assembly, right click on References and choose Add Reference. Pick the .NET tab and browse to the MQ.DLL choose it, then click Select and Ok.
For c#,
In your class add a using statement:
using MQ;
_________________
Bobby Ledford
Lead Architect
TSYS |
|
| Back to top |
|
|
| Thomasb |
| Posted: Mon Nov 11, 2002 9:03 am Post subject: |
|
|
Novice
Joined: 07 Oct 2002
Posts: 15
Location: Sundsvall, Sweden
|
Can anyone confirm that it is possible to connect to a remote MQSeries server with only MQSeries client software installed on the developer workstation. I have tried but get an exception when MQ.DLL tries to find mqm.dll.
I know this question have been debated before but I can't remember (or find) the answer. I'm stuck for the moment.
Thanks in advance! |
|
| Back to top |
|
|
| MartyD |
| Posted: Mon Nov 11, 2002 11:48 am Post subject: Remote connection using MQSeries client sw only |
|
|
Newbie
Joined: 21 Aug 2002
Posts: 7
|
| It is possible. Make a copy of ..\Program Files\MQSeries Client\bin\mqic32.dll and rename it to mqm.dll. I had to do this on the advice of Kolban and it worked for me. |
|
| Back to top |
|
|
|
|
