Bridge to MQ (BMQ) - only one Listener on MQ is working

Hi anyone,
we’re running BMQ on host to put messages generated in natural on a MQ (MQseries).
Two listener clients are waiting for work on the MQ.
Putting messages on the mq via the bridge makes one client work - the second client won’t ever get one message.
We could not find a property on client-site to manage a balanced message handling.
Does someone know some BMQ properties to solve the problem?
Any suggestions are welcome … :wink:

To be more detailled:
Initialy I put numerous messages on the MQ - both clients will GET messages and work parallely.
When I put new messages via BMQ on the MQ then - only one client GETs them and works, the other one just won’t GET and work.
After restarting the second client, it will work properly again.
This does not happen when the messages are PUT on the MQ via a JAVA-tool but only when I PUT via BMQ.

Hi,

what kind of listener clients are you using?

we use the classes from com.ibm.mq.jar

a view from the library:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.4.2 (IBM Corporation)
Copyright-Notice: Licensed Materials - Property of IBM <…>
© Copyright IBM Corp. 2008 A
ll Rights Reserved. US Government Users Restricted Rights -
Use,duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Sealed: false
Specification-Title: WebSphere MQ classes for Java
Specification-Version: 7.0.1.5
Specification-Vendor: IBM Corporation
Implementation-Title: WebSphere MQ classes for Java
Implementation-Version: 7.0.1.5 - k701-105-110419
Implementation-Vendor: IBM Corporation
Class-Path: com.ibm.mq.headers.jar com.ibm.mq.pcf.jar com.ibm.mq.jmqi.
jar connector.jar com.ibm.mq.commonservices.jar

My MQ specialist says mqoo_input_shared should be set at the BMQ putting messages to mq.

Does anyone know how to set?

This is a parameter for an input queue. So you have to set this in your listener program.

If I understand your scenario you have a RPC Client which sends “PUT” requests to the EntireX WMQ RPC Server. And then you have a Java application which uses the IBM Java classes to read (“GET”) these messages.

What did you specify for the following parameters in the wmqbridge.properties file:
entirex.server.fixedservers=
entirex.server.maxservers=

Hallo Rolf,
thank your for helping.

Our properties are:
entirex.bridge.verbose: yes
entirex.location.transparency.config:
entirex.location.transparency.ini:
entirex.server.brokerid: name:port
entirex.server.codepage:
entirex.server.compresslevel: 0
entirex.server.customclass:
entirex.server.encryption:
entirex.server.encryptionlevel: 0
entirex.server.environment:
entirex.server.fixedservers: no
entirex.server.logfile: $SAG/logfile
entirex.server.logicalbrokerid:
entirex.server.logicalservice:
entirex.server.logicalsetname: DefaultSet
entirex.server.maxservers: 32
entirex.server.minservers: 1
entirex.server.monitorport: 0
entirex.server.monitorremote: no
entirex.server.name: WebSphere MQ RPC Server 9.5.1.8.434
entirex.server.password: xxx
entirex.server.password.e: yyy
entirex.server.passwordencrypt: yes
entirex.server.restartcycles: 1
entirex.server.security: yes
entirex.server.serverlog:
entirex.server.usecodepage: no
entirex.server.userid: zzz
entirex.server.verbose: yes
entirex.server.waitattach: 600S
entirex.server.waitserver: 300S
entirex.timeout: 0
entirex.trace: 2
entirex.wmqbridge.inputqueue:
entirex.wmqbridge.mqtrace: yes
entirex.wmqbridge.outputqueue:
entirex.wmqbridge.password: xxxx
entirex.wmqbridge.queuemanager: xxxx
entirex.wmqbridge.userid: xxx
entirex.wmqbridge.waittime: 10000

Can you send the logfile ($SAG/logfile) via support?

Are you doing some processing in your listener client(s) after the GET of the message? You can try to add a sleep() or something equivalent to the client processing to slow it down.

My guess at the moment is that the client is processing the messages much faster then the messages are produced. The producer has to go from Natural to the Broker, from the Broker to the WMQ RPC Server and then to MQ.

I think we can exclude the idea that the client is too quick in this situation.
When I put some hundered messages on queue I see them on queue.
The client starts work and one get after the other takes them away - about 1 second each. So it should not be neccessary to slow him down.
On client (1) log I can watch the process. The second client seems to have lost connection to the queue - doesn’t make any get on the queue.

What are the properties about? I don’t have a detailled documentation about entirex.server.parameters.

The server parameters are documented here: http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite9-6/EntireX/9-6_EntireX/wmqBridge/admin.htm

I currently can’t see that the described client behavior is based on the way how the WMQ RPC Server is sending the MQ message.

Did you instantiate the queue in the Java MQ client with “queueManager.accessQueue(name, MQC.MQOO_INPUT_SHARED);” ?
Is the queue defined to allow shared access?

You should replace the logfile parameter in the properties file and specify a “real” location. Variable replacement does not work in the property file.

finally we’ve found the problem.
An old version of MQ Client was installed on listening Server.
IBM-MQ 7.0.1.5 was old
7.0.1.12 is working correctly now.

Thanks for the feedback. Good to hear that it’s working now.