| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Workflow Pure Java API Query |
« View previous topic :: View next topic » |
| Author |
Message
|
| spprash |
 Posted: Mon Sep 19, 2005 4:37 pm Post subject: MQ Workflow Pure Java API Query |
 |
|
Apprentice
Joined: 29 Dec 2002
Posts: 25
|
Our application used Workflow 3.4 and connected using LOC_LOCATOR Policy. We are trying to eliminate JNI calls in our application and hence we have upgraded to Workflow 3.5 with support PAC (WA0C) to use the Pure Java API. The Pure Java API uses JMS mode to communicate with the Workflow Server. I have a few clarifications in this regard.
[We are using Solaris and IBM WebSphere]
1. We have created a Workflow Profile(GICDFMC) for the Workflow Server and another Workflow Profile(FMC2-This profile is a client only profile which points to the GICDFMC Server profile) for the WebClient. Our Application is a seperate J2EE Application and we have configured it to use the same FMC2 Profile to connect to the GICDFMC Server.
The fmcrc file for the FMC2 Profile is below
Configuration/FMC2/FMLConnectName=FMC2.FMCGRP2.FMCSYS2,GICDFMC
Configuration/FMC2/System=FMCSYS2
Configuration/FMC2/SystemGroup=FMCGRP2
Configuration/FMC2/MQQueueManager=GICDFMC
Configuration/DefaultConfigurationID=FMC2
Configuration/FMC2/ConfigurationID=FMC2
Configuration/FMC2/MQPrefix=FMC2
Configuration/LOCALFMC/MQConnectionType=MQClient
Configuration/LOCALFMC/MQPort=5012
Configuration/LOCALFMC/MQCommunicationAddress=localhost
Do we need to create a seperate FMC3 Profile for our application or can we share the FMC2 Profile currently used by the WebClient too. Or should we use only the GICDFMC profile?
2. The Workflow Pure Java API is trying to communicate with MQ using the MQ Bindings mode(using JMS) by default. This causes the MQ DLLs to get loaded into the WebSphere Runtime(We are trying to avoid any Dlls from being used from WebSphere). To prevent this we need the Workflow Pure Java API to communicate with MQ using the Client mode. How do we make this change? We notice that MQConnectionType=MQClient is set in the fmcrc file. However the Workflow API seems to communicate using the Bindings mode and infact fails with an 'unsatisfied link error' if we dont provide the Mq java library path containing the MQ Dlls in the Library Path of the server. Also the pmap command shows that the MQ Library files are getting loaded in Websphere memory due to the bindings mode. How do we try to communicate to Workflow without letting any of the Dlls from getting loaded into WebSphere, that is in the pure Client mode.
3. Should the classpath contain the directory of the fmcrc file or should contain the directory and the fmcrc file name together. That is should it be /var/fmc/cfgs/GICDFMC or should it be /var/fmc/cfgs/GICDFMC/fmcrc
4. Will there be a performance degradation if we use the Client Mode instead of the Bindings mode. In our application we also connect to another MQ Series Queue manager using the MQ Java API's in the client mode. Is it possible to make a connection using Client Mode to Queue Manager A and another connection using Bindings mode to Queue Manager B(Workflow Queue Manager).
_________________
Prash |
|
| Back to top |
|
 |
| hos |
| Posted: Tue Sep 20, 2005 12:27 am Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
Prash,
a lot of questions at the same time 
Allright, let's see:
1.
| Quote: |
| Do we need to create a seperate FMC3 Profile for our application or can we share the FMC2 Profile currently used by the WebClient too. Or should we use only the GICDFMC profile? |
Reusing FMC2 configuration is perfectly fine. It will cause the MQWF server to listen to both client applications on the same port.
2.
| Quote: |
| How do we try to communicate to Workflow without letting any of the Dlls from getting loaded into WebSphere, that is in the pure Client mode. |
It is my opinion that you already use the MQ client mode! Which DLL's are you talking about? mqjbnd05? MQ JMS still uses JNI under the covers (see JMS documentation).
3.
| Quote: |
| Should the classpath contain the directory of the fmcrc file or should contain the directory and the fmcrc file name together |
It should be the directory name, i.e. /var/fmc/cfgs/FMC2. In addition it is a good practice to place the fmcjapi.jar file into the WebInf/lib directory of your J2EE application instead of setting the CLASSPATH to it.
4. The MQ client mode does not have a performance degradation. I would not recommend to use MQ Binding (Server) interface in your environment.
You can find all these answers in the MQWF 3.6 Installation Guide, Appendix K, where the native Java API is fully integrated into the product. |
|
| Back to top |
|
|
| spprash |
| Posted: Tue Sep 20, 2005 1:39 pm Post subject: |
|
|
Apprentice
Joined: 29 Dec 2002
Posts: 25
|
Thanks a lot...
However I stil have one nagging doubt..
Quote:
How do we try to communicate to Workflow without letting any of the Dlls from getting loaded into WebSphere, that is in the pure Client mode.
>>It is my opinion that you already use the MQ client mode! Which DLL's are you talking about? mqjbnd05? MQ JMS still uses JNI under the covers (see JMS documentation).
MQ JMS Supports Bindings mode and Client mode. Bindings mode uses the mqjbnd05 dll and the client mode is a pure java mode(no JNI). I was wondering if it is possible to force the use of JMS Client mode to completely eliminate JNI calls. Also what is the significance of Configuration/LOCALFMC/MQConnectionType=MQClient in the fmcrc file. I assumed the MQClient setting in fmcrc will allow it to operate in a machine with only MQ and MQ JMS jars installed (without the need for any dlls) but invariably it loads the mqjbnd05 dll files.
_________________
Prash |
|
| Back to top |
|
|
| spprash |
| Posted: Wed Sep 21, 2005 6:22 pm Post subject: |
|
|
Apprentice
Joined: 29 Dec 2002
Posts: 25
|
We figured out the issue.
The dlls were getting loaded since the original fmcrc file had a wrong key in its configuration. This had forced the Workflow Java API to contact Workflow in JMS Bindings mode instead of in client mode. After making the correction no dlls are getting loaded.
Our original Workflow3.5 fmcrc file had a wrong key value as shown in bold below.
Configuration/FMC2/FMLConnectName=FMC2.FMCGRP2.FMCSYS2,GICDFMC
Configuration/FMC2/System=FMCSYS2
Configuration/FMC2/SystemGroup=FMCGRP2
Configuration/FMC2/MQQueueManager=GICDFMC
Configuration/DefaultConfigurationID=FMC2
Configuration/FMC2/ConfigurationID=FMC2
Configuration/FMC2/MQPrefix=FMC2
Configuration/LOCALFMC/MQConnectionType=MQClient
Configuration/LOCALFMC/MQPort=5012
Configuration/LOCALFMC/MQCommunicationAddress=localhost
We corrected the file as below
Configuration/FMC2/FMLConnectName=FMC2.FMCGRP2.FMCSYS2,GICDFMC
Configuration/FMC2/System=FMCSYS2
Configuration/FMC2/SystemGroup=FMCGRP2
Configuration/FMC2/MQQueueManager=GICDFMC
Configuration/DefaultConfigurationID=FMC2
Configuration/FMC2/ConfigurationID=FMC2
Configuration/FMC2/MQPrefix=FMC2
Configuration/FMC2/MQConnectionType=MQClient
Configuration/FMC2/MQPort=5012
Configuration/FMC2/MQCommunicationAddress=localhost
The erroneous entry LOCALFMC/MQConnectionType had caused Workflow to default to the MQServer bindings mode. After making the correction as FMC2/MQConnectionType=MQClient the JMS connections are connecting using the MQ client mode and none of the Dll files are getting loaded.
_________________
Prash |
|
| Back to top |
|
|
| hos |
| Posted: Wed Sep 21, 2005 11:40 pm Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
Good for you - a pain for support people.
THOU SHALL NOT EDIT PROFILE FILES!!!  |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
