Stack Exchange
Unable to connect to Websphere MQ Manager using XMS
This code reproduces the issue:
#include <iostream>
#include <xms.hpp>

int main()
{
    try
    {
        xms::ConnectionFactory factory;

        factory.setIntProperty(XMSC_CONNECTION_TYPE,      XMSC_CT_WMQ);
        factory.setIntProperty(XMSC_WMQ_CONNECTION_MODE,  XMSC_WMQ_CM_CLIENT);
        factory.setStringProperty(XMSC_WMQ_QUEUE_MANAGER, "my.queue.manager");
        factory.setStringProperty(XMSC_WMQ_HOST_NAME,     "my.dev.mq");
        factory.setStringProperty(XMSC_WMQ_CHANNEL,       "my.channel");
        factory.setIntProperty(XMSC_WMQ_PORT,              1414);

         std::cout << "Is Factory Null? => " << factory.isNull() << std::endl;
         xms::Connection conn = factory.createConnection(); //THIS THROWS EXCEPTION
         std::cout << "Is Factory Null? => " << factory.isNull() << std::endl;
    }
    catch(xms::Exception const & e)
    {
         e.dump(std::cout);
    }
}

It throws exception, dumping the following message:
Is Factory Null? => 0
Exception:
ErrorData =
ErrorCode = 26 (XMS_E_CONNECT_FAILED)
JMS Type  = 1 (XMS_X_GENERAL_EXCEPTION)
Linked Exception:
ErrorData = libmqic_r.so
ErrorCode = 0 (XMS_E_NONE)
JMS Type  = 1 (XMS_X_GENERAL_EXCEPTION)

Any idea what is wrong with the code?  
Note that devpmmq is just an alias to the actual IP address (host). If I put any random/nonsense value for it, I get the same error, which is bad because the API should have given a better error message such as "host not found" or something alone that line. Is there any way to enable more verbose diagnostics?

XMS C/C++ internally loads WebSphere MQ client libraries. The problem here is that XMS is unable to find WebSphere MQ client library libmqm_r.so. 
What is puzzling me is that the code has set XMSC_WMQ_CONNECTION_MODE as XMSC_WMQ_CM_CLIENT but XMS is attempting to load libmqm_r.so. It should have attempted to load libmqic_r.so.
Have you installed WebSphere MQ client? Also what is the version of XMSClients can be downloaded from here.

Thanks a lot. Now its working (all I had to set the LD_LIBRARY_PATH pointing to the directory which contains libmqic_r.so). And you're right, it should have been libmqic_r.so. It was a typo (I was experimenting with different values, and in that process I posted mismatched error).

Could you please provide me with a link to online doc which explains which *.so are for what purpose. I mean, how would I know whether I need libmqm.so or libmqm_r.so  or any other .so for that matter. What is the difference between them? and so on.

Have a look at this link: http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q028460_.htm

I've written a distributed application using XMS. When I run this, using valgrind, it reports Invalid free()/delete/delete[]. So I wrote tiny producer-consumer program to reproduce this error, and I found that when this tiny program is linked against libmqic_r.so, only then it reports Invalid free()/delete/delete[]. My tiny program does NOT use anything or call any function from XMS. Just linking against libmqic_r.so is enough to produce the error. Could you please give me some pointers/guesses what might have gone wrong?

... the stacktrace reported by valgrind contains these two interesting functions: exit from libc and _vgnU_freeres from vg_preloaded.so. It seems when the program exits and the library unloads, it tries to deallocate some memory, this Invalid free... error appears.

Does your program terminates with an error or is it that Valgrind is showing that and application does not end with an error? If the case is former, then I would suggest a PMR/Ticket with IBM.

The tiny program doesn't  terminates an error. It is just that Valgrind says there is Invalid free showing the stacktrace. However, the real program ends up with a mutex-lock failure, with the error code EINVAL which, as per the doc, means either 1) the calling thread's priority is higher than the mutex's current priority ceiling, or 2) "mutex does not refer to an initialised mutex object." .

.... The latter case could mean there is memory-corruption, as per this answer, which also suggests to use valgrind. And valgrind indeed shows Invalid free.
