| Author |
Message
|
| victor1998 |
 Posted: Thu Jan 20, 2005 2:42 pm Post subject: The link between WLS and MQ: MQ Client or local connection |
 |
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
I am designing an architecture to integrate the J2EE applications with Mainframes System using Weblogic Server and Websphere MQ. The following is my draft:
WLS Applications -->MQ QM1 --> MQ QM2 --> Mainframe Applications
The WLS applications and MQ QM1 stay in the same Solaris machine. The Mainframe Applications and MQ QM2 stay in the same machine. The connection between WLS Applications and MQ QM1 is local connection. The connection between Mainframework Applications and MQ QM2 is also local connection.
I was told that this draft was wrong. The connection between WLS Applications and MQ QM1 should use MQ Client Channel.
The reason is:
MQ QM1 uses IPC (inter-Process Communication) for local connection. MQ could not handle the memory leak. So, particularly, in high volumn production enviorment, MQ will quickly use out the resource and make the WLS die.
I feel a little confuse because I think that MQ Client will only be used in the following scenario:
1) The applications on Desktop and Laptop use MQClient to link to MQ QM running on a Unix server
2) Simplify the administration
3) Free
Could you please answer the following questions:
1) What kind of link should be used for WLS and MQ, MQ Client or local connection in my draft?
2) The reason I mentioned above is right or not?
3) Does the MQ Server have the memory leak problem? How to solve it?
4) In what scenario should use MQClient or MQServer? In what scenario can use either of them?
5) I suppose the local connection + server-to-server channel can handle the high volumn messages. Is this correct?
Thank you very much for your help.
Regards, |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Jan 20, 2005 2:52 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Whoever told you that doesn't know what they are talking about.
An app running on the same server as the QM can and should connect to the QM in bindings mode. Why introduce the risks and latency that a client model does? If you are going to be a clinet, just client connect to the MF QM already!
If you are going to connect in bindings mode, you should not use FASTPATH bindings mode, which causes you to run in the same address space as the QM. If your app takes a dirt nap so does the QM. Just use STANDARD bindings mode.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| victor1998 |
| Posted: Thu Jan 20, 2005 3:49 pm Post subject: |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
Hi, Peter:
Thanks for your message. First, could you please let me know which Websphere MQ document has these information. Secondly, If WLS and MQ coexist in same machine and the MQ uses the IPC communicate(local connection) with WLS, how do you solve the problem of memory leak caused by MQ (MQ is really bad at cleaning up shared memory).
Thank you very much for your help.
Regards, |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 20, 2005 4:12 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The application programming guide and applicatio referance manual have info on the different bindings option. Look in the chapters on the MQCONNX call.
I don't know anything about MQ being such a problem with memory leaks. We have lots of apps running on dozens of QMs, sending millions of messages each month, and have never had a problem with this memory leak you are worried about. If MQ did have a leak, I don't see how MQClient would be better than MQ Bindings. But I defer to the experts at IBM about this topic.
In general though, I think your fears are completly unfounded. Use Bindings mode, or eliminate the distributed QM and just client connect to the destination QM directly (unless there are reasons they won't allow that, or the network is really flakey).
Client connecting to a local MQ is like going from your living room, out the front door, around the back of the house, while it is raining, thru the back door and into the kitchen to get your muffin. Wouldn't it be easier, smarter, safer, faster to go directly from the living room to the kitchen?
Same with your app. Its smarter, faster, easier and safer to connect directly to the QM to get your muffin...I mean your message.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 20, 2005 6:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter is absolutely right.
The reason why a lot of people think there is a memory leak is because once the qmgr is down it takes a while for ipc to free all the qmgr related space. This is why on Unix machines MQ provides you with the amqiclen utility. Check it out.
The truth is the ipc space would be freed over time. I believe there is some efficiency components involved in not freeing up the space right away, but this is for the OS people to determine.
As Peter mentioned the mode that truely should be used is Standard Bindings mode. It will support your 2 phase commit with the Web Application Server. I understand that your configuration will save you quite some money as the Client Attachment Facility needed to do MF client connections will cost you more than a full MQ Server on Unix.
We use up to 5 qmgrs on a Solaris box and run 4 Oracle instances with the Messaging Gateway (MQ <=> AQ) and have not noticed any of the memory leaks you are talking about (All in the same box). Are you sure that the people who are talking about those memory leaks are not causing them through poorly coded apps, or have no ulterior motive(sales rep $$$) ?
Enjoy  |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Jan 20, 2005 10:22 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
amqiclen is not supplied for routine use after a qmgr has ended normally. WMQ cleans up all the shared memory and semaphores it needs to when a qmgr ends. Memory and semaphores are deliberately left to speed up the start of the next qmgr.
amqiclen is only really of use after a qmgr has ended abnormally or been killed, and when restarted it comes up with AM8101 (I think) which says that apps are still running. In that case, the shared memory needs to be cleaned. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 21, 2005 2:53 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
amqiclen is not supplied for routine use after a qmgr has ended normally. WMQ cleans up all the shared memory and semaphores it needs to when a qmgr ends. Memory and semaphores are deliberately left to speed up the start of the next qmgr.
amqiclen is only really of use after a qmgr has ended abnormally or been killed, and when restarted it comes up with AM8101 (I think) which says that apps are still running. In that case, the shared memory needs to be cleaned. |
Thanks a lot for the clarification Nigel. We only use it before a CSD Upgrade to make sure our space is clean.
F.J. |
|
| Back to top |
|
|
| victor1998 |
| Posted: Fri Jan 21, 2005 8:06 am Post subject: |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
Thanks everyone for your help.
Actually, I am not worry about the normal or abnormal end of QM. My consideration is : when the QM is running, whether each communication between MQ QM and WLS has memory leak. fjb_saper asked a very good question. The memory leak may come from apps rather than MQ. I need to confirm it.
But I want to confirm:
1) when you decide the communication link between Weblogic Server and MQ QM, what reason make you choose MQ Client Channel?
From my understand, the communication link between WLS and MQ QM should be local connection. The collaboration between WLS and MQ are server-side behavior. It needs a high reliability and high performance connection. Local connection is in-memory call type and Client channel is RPC type.
2) when you decide the communication link between Weblogic Server and MQ QM, have you been worry about the memory leak of QM.
3) What kind of link (local connection or MQ Client channel ) you are using for connecting the WLS and MQ ? How many messages per second? How about the response time?
Thanks a lot again
victor |
|
| Back to top |
|
|
| bbburson |
| Posted: Fri Jan 21, 2005 8:48 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| victor1998 wrote: |
| 1) when you decide the communication link between Weblogic Server and MQ QM, what reason make you choose MQ Client Channel? |
One thing that might influence your decision is high-availability failover capability. For instance, we have an application and a WMQ queue manager that run on a pair of servers, and they can failover between the servers independently of each other. We have to use client connections so that everything will work if the queue manager is running on server A while the application is running on server B.
So, like most design decisions, the correct answer is what makes sense for your particular environment. |
|
| Back to top |
|
|
| victor1998 |
| Posted: Fri Jan 21, 2005 11:39 am Post subject: |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
Hello, bbburson
Thanks for your message.
I do not think it should be the reason for using MQ Client Channel. Actually, My draft is
WLS1 --> QM1
WLS2 --> QM2
--> QM5 --> Mainframe
WLS3 --> QM3
WLS4 --> QM4
WLS1, WLS2, WLS3 and WL4 in one Weblogic Cluster. QM1, QM2, QM3, QM4 and QM5 in another MQ Cluster.
Because the link between WLS and MQ is local connection, and the link between Mainframe and MQ is local connection, there is not additional network problem. The Server-to-Server channel among QMs guaratee the delivery.
I want to confirm what special reasons make many designers choose MQ Client Channel as the link between WLS and MQ. This actually against the features of client channel, local connection +server-to-server channel.
Thanks a lot |
|
| Back to top |
|
|
| victor1998 |
| Posted: Thu Feb 03, 2005 8:20 am Post subject: |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
Hi,
I completed the testing. Did not find the memory leak problem. I have decided to use the local connection to link the WLS and MQ QM.
Thanks for everyone. |
|
| Back to top |
|
|
|
|
