I have setup the IBM Websphere MQ in my localhost pc and follow the tutorial from here and here
When i run the code it always give me the same error.
Error 2035 : MQRC_NOT_AUTHORIZED
when it reach this line ;
MQQueueManager queueManager = new MQQueueManager("QM_TEST", props);
I already set the MCA UserID in the server-connection channel : mqm and use it in my code
props.Add(MQC.USER_ID_PROPERTY, "mqm");
And from what i read on the internet when we set MCA UserID it should override
what is provided by client.But still the problem occurred.
Not sure if it related, but Im using Websphere Version: 7.5.0.2 and Windows 10 Pro.
Thank you in advance
props.Add(MQC.USER_ID_PROPERTY, "mqm");
Bad idea, absolutely not recommended. That UserId is for the exclusive use of MQ and NOT applications.
ALTER QMGR CHLAUTH(DISABLED)
Really, really bad and stupid idea. You are disabling security in MQ. So, you just want anybody or hackers to get whatever they want from your messaging system.
Solved the issue by disabling chanel authentication
ALTER QMGR CHLAUTH(DISABLED)
Related
I've seen loads post on this forum about exchange API, but I've never found something like I have.
I' m trying to connect to Exchange using Exchange API in order to get all room's meetings.
My problem : Sometimes, it's working, I can connect and get all my informations. And 5m later, impossible to connect. I got Unauthorized.
It's not an error on code because it's working, I think it's a problem with exchange server, but I really don't know what it is...
On the next picture, there are traces.
On the left, when it's working, And the same 30m later (same identification, same room) which is not working.
http://hpics.li/2d9b216
If you have any ideas ? I really don't know what to do.
thanks (and sorry for my english !)
I notice that the working request comes from server A (look at the value of X-FEServer header), and the failing one comes from server B. Perhaps there is a configuration problem on server B.
thx for this.
I've done some tests : I've modified my host file in my computer. when the url is pointing to serveur A, it's working. When it's on the other server, not working. It's the same configuration on both, cannot find what's wrong. So I will conserve my actual host file (pointing always on serveur A).
I have a very simple Jabber client, which connects to Google Talk via our "Google Apps" domain account. The connect code is as simple as it gets:
jc.User = "chatbot#ourdomain.com";
jc.Server = "ourdomain.com";
jc.Password = "password";
jc.OnMessage += new MessageHandler(jc_OnMessage);
jc.OnDisconnect += jc_OnDisconnect;
jc.OnConnect += jc_OnConnect;
jc.Connect();
This has been running fine for a couple of years, but today it's suddenly stopped working: after the Connect(), I get the exception
A first chance exception of type 'netlib.Dns.DnsException' occurred in
netlib.Dns.dll
Additional information: DNS query fails
followed by
A first chance exception of type 'System.FormatException' occurred in
System.dll
Additional information: An invalid IP address was specified.
I know that Google have indicated that XMPP support is perhaps going away, but I can still connect to the account in question using a "proper" XMPP client.
I've tried changing the Server property to different settings, including:
xmpp-server.l.google.com
alt1.xmpp-server.l.google.com
talk.google.com
but all give the same result.
Does anyone know why this error is suddenly biting me, and what I can do to resolve it?
After literally hours of fiddling around, I've figured out that changing
jc.User = "chatbot#ourdomain.com";
to
jc.User = "chatbot";
solves the issue. Quite why it's worked for years, and has now suddenly stopped, is beyond me - I guess Google flipped a switch somewhere. Problem solved anyway, hopefully this will help someone else.
I am working with a program that is meant to publish to and read from an existing TIBCO EMS hosted on a server separate from the program. I have referenced the sample code provided with the TIBCO installation, resulting in a big chunk of the program. Here is the code snippet that I am having troubles with:
1 QueueConnectionFactory factory = new TIBCO.EMS.QueueConnectionFactory(serverUrl);
2 QueueConnection connection = factory.CreateQueueConnection(username,password);
3 QueueSession session = connection.CreateQueueSession(false, Session.AUTO_ACKNOWLEDGE);
When line 1 runs, it goes through alright. When line 2 runs, it goes through alright, however, the connection object is null, resulting in an error during line 3 where a NullReferenceException occurs.
I would have at least expected that line 2 would return some sort of error to show that the request timed out, the credentials were wrong, the url is inaccessible, or at least something to let me know what the issue is, but there is nothing like that, until it hits line 3.
Does it have to do with the configuration of my application? All I have done to get this working is include the TIBCO.EMS.dll as a reference and worked with the code from there.
Could it have something to do with the fact that I am connected to a VPN that requires a proxy? If so, how can I set up that proxy in my code?
Any help would be greatly appreciated. Thank you.
The issue was that I was using the wrong version of the .NET framework to work with the Tibco integration. The version I was using was farther along than the original.
It would think that your server URL is incorrect.
try different urls maybe like tcp://localhost:7222 (where localhost can be the IP/Name of the remote server)
install EMS locally on you workstation and see if you can connect to it. (Default admin with no password)
I am trying to connect to a remote queue using c#.
I tried many ways to connect to the remote queue but it always fails with common errors like: MQRC_CHANNEL_CONFIG_ERROR or MQRC_HOST_NOT_AVAILABLE.
What I am doing is this:
string channel = "QM_TEST.SVRCONN";
string hostname = "<serverIp>";
string queueName = "QM_TEST";
string port = 1414;
props.Add(MQC.HOST_NAME_PROPERTY, hostname);
props.Add(MQC.CHANNEL_PROPERTY, channel);
props.Add(MQC.PORT_PROPERTY, port );
props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);
MQQueueManager mqQueue = new MQQueueManager(queueName, props);
I have tried changing this but all failed.
I think that my problem is the server configurations..
can you point me to a full guide to how to configure a server and connect to it with .net?
My problem is connecting to a REMOTE server using .net and not to a local server.
Thank you!
The problem was that the CCSID between the client and the server were different.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzaf.doc%2Fcs12480_.htm
On the client side I had to put
Environment.SetEnvironmentVariable("MQCCSID", "437");
Thats why I got:
MQRC_CHANNEL_CONFIG_ERROR
I'm guessing the problem (or at least a problem) is here:
MQQueue mqQueue = new MQQueueManager(queueName, props);
This should be
queueManager = new MQQueueManager(queueManagerName, properties);
If you have installed the WebSphere MQ client to the default location, there are many sample programs under the following directory:
C:\Program Files (x86)\IBM\WebSphere MQ\tools\dotnet\samples\cs\base\
There are a number of sample programs there for various tasks. If you have the latest V7.1 client installed then you will see the following programs:
SimpleAsyncPut
SimpleClientAutoReconnectGet
SimpleClientAutoReconnectPut
SimpleGet
SimpleMessageProperties
SimplePublish
SimplePut
SimpleReadAhead
SimpleSharingConversation
SimpleSubscribe
SimpleXAGet
SimpleXAPut
There are also WCF and XMS samples.
If you need the client code, please see my response to another SO question here for links.
Update:
Here's the normal diagnostic process.
If the WMQ components were installed by relocating libraries or classes from somewhere else, perform an install using the full vendor-supplied client media. This includes troubleshooting utilities such as trace, dspmqver, etc. It also resolves any library or class mismatch issues.
Use the pre-compiled client programs to test the connection. The amqsputc, amqsgetc and amqsbcgc programs require the MQSERVER environment variable as described here. The Q program from SupportPac MA01 is a separate download but has the advantage of NOT requiring any environment variables, CCDT files or other dependencies.
If the sample programs fail, check the QMgr's error logs at [WMQ install]/qmgrs/[QMgr name]/errors/AMQERR01.LOG for messages. Also check for FDC files and errors in [WMQ install]/errors.
If no errors on the QMgr side, attempt the connection again while using a client-side trace as described here and here.
Most client problems are resolved through installation of the full WMQ client as supplied by IBM. (Conversely that implies most people are installing by grabbing DLL or JAR files.) If the problem persists, error log inspection on the QMgr and client side usually reveals the underlying cause. If these do not work then tracing usually diagnoses the remaining issues.
UPDATE 2:
Per the error messages posted at MQSeries.net, the channel has a security exit set. A security exit is external code that the channel calls out to when starting a channel. There is no way to know what the exit expects or does without having access to the code or docs of the exit. If the exit is written in-house, you'll need to talk to the programmer to figure out what it requires. If the exit is a commercial product then you will need to get the documentation for it.
Alternatively, alter the channel so that SCYEXIT is blank to disable the exit.
The data posted at MQSeries.net was as follows:
MQ9575: DCE Security: failed to get the user's login name.
EXPLANATION:
System call 192.168.50.55 to get the login name of the user running WebSphere
MQ client application process 5 failed with error value -1. This occurred in
security exit function create_cred. The exit will now attempt to open channel
using the DCE default login context.
ACTION:
If you wish to run using the DCE default login context take no action. If you
wish to run using the user's login name as the DCE security exit principal
examine the documentation for the operating system on which you are running MQ
clients and reconfigure the operating system as necessary to allow the
192.168.50.55 call to succeed.
Note that it states the call is failing in the security exit.
On several occasions I have received the following error from a .Net (C#, 4.0) application out of the blue on sending a message thru a producer:
CWSMQ0082E: Failed to send to CompCode: 2, Reason: 2009. A problem was encountered whilst sending a message. See the linked exception for more information.
Of course, the LinkedException (why not use the InnerException IBM???) is null i.e. no more information available.
Code I'm using (pretty straightforward):
var m = _session.CreateBytesMessage();
m.WriteBytes(mybytearray);
m.JMSReplyTo = myreplytoqueue;
m.SetIntProperty(XMSC.JMS_IBM_MSGTYPE, MQC.MQMT_DATAGRAM);
m.SetIntProperty(XMSC.JMS_IBM_REPORT_COA, MQC.MQRO_COD);
m.SetIntProperty(XMSC.JMS_IBM_REPORT_COD, MQC.MQRO_COA);
myproducer.Send(m, DeliveryMode.Persistent, mypriority, myttl);
(Offtopic: I hate the SetIntProperty way of setting properties. Which <expletive deleted> came up with that idea? It takes ages to look up all sorts of constants all over the place and its allowed values.)
The exception is thrown on the .Send method. I'm using XMS.Net (IA9H / 2.0.0.7). The only Google result that turns up turns out to have a different reason code (and even if it were the same, it should be fixed in my version if I understand correctly). This occurs randomly (though it seems to happen more often when it's been a while since a message has been sent/received) and I have no way to reproduce this.
I have ab-so-lute-ly no idea how to troubleshoot this or even where to start looking. Is this something caused by the server-side? Is it caused by XMS.net or some underlying IBM WebSphere MQ infrastructure?
Some results that I found that seem similar are suggesting to set SHARECNV to any value higher than 0 or to "true" / "yes" but the documentation explicitly tells me the default is 10. Also; I have no idea if this is the cause so changing it to another value feels like a shotgun approach.
Anybody any idea on how to go about solving this? I could of course just catch the exception, tear everything (channels, sessions, whatever) down and restart but that's just plain ugly IMHO.
The 2009 return code means "Connection Broken." Basically, the underlying TCP socket is gone and the client finds out about it at the time of the API call. It is possible to tune the channels using heartbeat and keepalive so that WMQ tries harde to keep the socket alive. However if the socket is timed out by the underlying infrastructure, nothing WMQ can do will help. Examples we've seen are that firewalls and load balancers are often set to detect idle connections and sever them.
Modern versions of WMQ client will attempt to reconnect transparently. The application just blocks a bit longer when this occurs.
Short of using the automatic reconnect, the only solution is in fact to rebuild the connection. Since it will get a new connection handle, all the object handles must be rebuilt as well.
Many of the tuning functions described here are available through the client configuration file, available in v7.0 and greater clients. In particular, the TCP stanza of that file enables keepalive. (The TCP spec says that if keepalive is provided, it must be disabled by default.) The QMgr has a similar ini file with configuration stanzas, including one for keepalive. The latest WMQ client is available as SupportPac MQC71 if you need that.
In cases where the main exception is sufficient enough to indicate the error, the inner exception will be null. In your case it's MQ reason code 2009 which means a connection to queue manager has been broken. The socket through which your application and queue manager were communicating was closed for some reason. The reason for socket close could be a network blip.
Along with suggestions T.Rob noted above, You could also run a XMS and Queue manager trace to understand the problem further. Please see the Troubleshooting chapter in XMS InfoCenter.
HTH