MQSeries.net :: View topic - mqctl suspend/mqctl stop does not return.

Duong Nguyen · Posted: Mon Mar 15, 2010 1:19 am Post subject:

---- I've moved this from "General Discussion" ---
We are first time users of Websphere MQ so please be gentle.
What we are attempting to do is to implement asynchronous callback under .NET. I know that the new XMS does allow this but it would involve a fair amount of new code. This is our plan B.

Our plan A is as follow:

Our first attempt was to search for the hConn member of the .NET CSharp MQQueueManager in order to pass on to the C API, i.e. MQCB and MQCTL. This seems to work well until some mysterious problem occured that we did not know how to fix. I'll describe this system more fully if people are interested.

Our second attempt is to call C API directly from .NET CSharp. Subscriptions and point to point messages are received via a callback from C (and C++) into .NET CSharp. The connection to the queue manager (in client mode) is done via the C-API call MQCONNX. This program, A, sends request (via MQPUT) to another program called B. Before the message is sent, A executes a MQCTL Suspend is called to stop the callback. All of this works well until we starts to receive a lots of published messages from a third program, C. Program A MQCTL suspend (and MQCTL stop) simply do not return and program A hang.

If we get program C to stop publication before program A executes MQCTL suspend/stop then everything works.

The connection from all programs to the queue manager is via TRANSPORT_MQSERIES_CLIENT, MQCNO_HANDLE_SHARE_BLOCK, MQCNO_SHARED_BINDING, the channel is TCP/IP

While investigating this problem, we tried to connect with MQCNO_HANDLE_SHARE_NO_BLOCK, MQCNO_SHARED_STANDARD. The MQCONNX returns no error, however, the DISPLAY CONN indicates that the connection is still MQCNO_HANDLE_SHARE_BLOCK, MQCNO_SHARED_BINDING.

In order to eliminates parameter passing problem from .NET CSharp to we go via an intermediary C++ program. We can put a break point in the C++ program to examine the parameter to make sure they are correct before the C-API is called.

The C++ program also helps with the .NET CSharp callback that is stdcall, not the cdel callback of the C-API message handler.

The queue manager runs on Windows server 2003, Websphere MQ 7.0.
The clients A, B and C runs on Windows XP, Websphere client 7.0.

The questions are:
1) Are some connection parameters for the MQCONNX calls needs to be changed before MQCTL suspend/stop work?
2) What should I do to connect as MQCNO_HANDLE_SHARE_NO_BLOCK, MQCNO_SHARED_STANDARD.

I'm very hesitant to give up and open a second connection for sending/publishing and keep the first connection for receiving point to point and subscription since this is an unknown that weighs heavily on my mind. Our system, when it is finished will manage all the motorways in our city. Any unknown here is simply not welcome.