RVCM

RVCM provides complete reliability for the subscribers RVCM uses ledger
concept.
Two types of ledgers
1.
File based
2.
Process based
For process based ledger the publisher offers reliability only as long as he is
running
Process based means memory
For File based ledger the publisher offers reliability all the time.
For each out bound message a certified sequence number will be added,
message will be stored in the ledger file and then it will be placed on the
network.
When the subscribed subscriber receives the message he should send
conformation for the received message
The certified subscriber ledger file will be updated with incoming message
subject name, the certified publisher transport name, and the last
acknowledged message sequence number will be updated with conformed
message sequence number.
For each received message the certified subscriber should send conformation to
the publisher. When publishing RVD receives confirmation then only it
understands that message has been delivered successfully.
The certified publisher provides reliability only for agreed subscribers by default
when the certified subscriber receives the first message, that message will be
having same sequence number as "Zero" irrespective of actual sequence
number.
Same sequence number "0" indicates that the message is only reliable message
which means there is no guarantee for the message second there is no certified
delivery agreement has been established
After receiving the first message the certified subscriber internally will send
certified delivery request to the publishing RVD then the list of listeners in the
publisher ledger will be updated with agreed certified subscriber transport
name.
After the agreement only the sublisher will provide offline message delivery to
the agreed certified subscriber
When ever certified subscriber lost message by comparing last acknowledged
message sequence number with the incoming message sequence number.
For the lost message he will send retransmission request for the publishing RVD.

When the publishing receives retransmission request it will check the ledger
and if the agreement exist the message will be retransmitted
1.
2.
3.

In certified
Delivery
Delivery
Delivery

delivery three advisory ___________ and messages will be used

Confirm
complete
no response

Delivery of confirm indicates the publisher is expecting confirmation from the

certified subscriber for a published message
Delivery of complete indicates the certified publisher has received confirmation
from all the certified subscribers for a published message.
Delivery of no response indicates the publisher has not received confirmation
for a published message.
When ever certified publisher receives retransmission request he will retransmit
all the messages who's adversary message status is delivered on no response
The adversary message status will be set for each message and for each
subscriber individually
In order to provide certified message delivery from the first message itself the
certified subscribed should be pre registered the certified subscriber at the
publisher site
For pre registered certified subscriber the message numbers will be non zero
values
There is a chance of duplicate message delivery by the certified publisher
Before receiving confirmation from the certified subscribers if the publisher goes
offline when he is restarted he will retransmit all the messages who's adversary
message status is delivered on no response

RVRAND stands for RV relay agent Demerol

RV follows BUS architecture which means it is pear to pear network thats way the
publisher should be online 24/7 in order to deliver offline messages even if he
doesn't have any messages to publish.
RVRAND will be acting as interface between publisher and subscribers in certified
messaging.
The relay agent will have access to publisher ledger

The relay agent should be running on only on the publisher system if the publisher
is offline and at that time if certified subscribers sends retransmission request the
relay agent will retransmit all the offline messages to the certified subscribers
If relay agent is configured the certified publisher need not to be active in order to
deliver offline messages
If at all the relay agent is configured we should make sure relay agent is online
RVR subscriber can also receive messages that are published by certified publisher
but offline message delivery will be only for certified subscribers but not for RVR
subscribers
If RVR subscriber sends retransmission request with in buffer interval or with in
reliability time then RVR subscriber can receive offline messages
Only if the network link is broken

RVCACHE contains the most recently exchanged message data for any subject.
It will store only one message per subject
In order to get message data from RVCACHE application should send request on to a
subject called "_SNAP.<SUBJECTNAME>"
In RV the load balancing is implemented by RVDQ
RVDQ means its collection of cooperative RV transport objects each having its own
process
The DQ will be implemented only at the subscribers side
All the applications that are part of distributed queue should be listening on the
same subject
In a distributed Queue only one application will be acting as scheduler and all other
applications will be acting as workers
The role of scheduler is delivering messages to the workers in load balanced
manner if all workers are busy then only the scheduler will process messages
All the DQ applications should have same values for
Cmq name
Scheduler activation
Scheduler heartbeat
Based on the requirement and systems configuration each worker can be configured
with same values or different values for
Scheduler weight
Worker weight
Worker task
Worker complete time
If all applications are having same values for these 4 parameters one of the
application will be picked randomly ac scheduler and this scheduler will deliver one
message to one worker at a time

Which ever allocation has highest scheduler weighr that application will be initial
scheduler. The worker weight specifies the prerority of the worker . Worker stasks
specifies number of messages a worker can process simultaneously
Worker complete time specifies the amount of time a worker requires to complete
given message processing.
Worker tasks is also referred as worker queue
When ever scheduler recives messages he will deliver all the messages to the high
prority owrker ans schedular will continioue to do so till the high prority worker
becomes busy
A worker will be treated as busy if he is worker queue is full or if he unable to
complete message processing with in specific amount of time.
When the high prority worker becomes busy then the schedular will delever
messages to the second high proroty worker
In this manner the schedular will distribute meesage amoung workers for load
balenced message processing
At reqular intervels wich is ssecified by schedular heart beat the schedilar will be
sending hard beat messages to all the workers indecating that he is active
If the schedular stops sending hear beadschedular weightw messages
The worker who has second highest schedular weight will beome or will be
activated as new schedular after the intervel which is specified by ______________
And the initial
s__________________________________________________________________________
Internelly all the dq appliccations are certified messaging applications the DQ is
implemented with the help of RF FT
RVFT --- RV fault tolerance
RVFT is responcible for _________________
Making sure that the DQ applicatiosn are communicating properly and it is also
responcible for activating working as schecular and deactivating schedular
The dq group should contain min 3 applications
For load balance functionality
CMQ-certified message queue
Using cmq name applications will be logically grouped under a named distributed
queue
All the DQ applications should have same business logic
If the publisher to DQ is certified publisher the DQ application should send
confirmation other wise the dont need to send confirmation
RVRD stands for RV Routing De_____

RVRD ________ message routing between networks

If a system is configured with RVRD we dont need to use RVD because RVRD
contais the functionality of RVD
In each network RVRD should be configured the communication protocol between
RVRD is TCP
While routing messages across network RVRD can compress and de-compress
messages
While configuring RVRD the network information should be exported and should be
imported in both RVRD configurations and the subject names also should be
configured
We need to configure the network and the neibering networks in router
RVA
RVA stands for RV agent
RVA will be acting as firewall between browser applications and RVD
The browser application can connect to RVA either using TCP protocol or as http
application using "http tunneling" mechanism this restriction is imposed dud to
security issues.
The subjects which will be used in browser communication should be configured
VC
VC stands for Virtual Circuits
VC enables point to point communication between RV applications
In both the RV applications Virtual circuit transport objects should be created
Each virtual circuit transport object is call as a terminal
Terminals guarantees that messages are always travel between the terminal
Virtual circuits can be configured programmatically only
Broadcast means delivering messages to unknown number of applications (used in
RVR)
Multi casting means delivering messages to known applications (used in RVCM)
Uni-cast means delivering messages to only one application (used in VC)
In RV synchronous communication if the reply subject is not specified RV will
automatically create a reply subject who's name starts with "_inbox"
If a system has multiple network interfaces then for each interface we are suppose
to configure service with different port number so that system can receive

messages from multiple UDP interfaces, for this the system should have multicast
address
Multicast address range is 224.0.0.0 to 239.255.255.255
C:\Users\sundeep>RVD -listen 7575 - reliability 500 -http 7676 logfile C:\RVLOGG
ER.LOG
To test the network
rvperfm -messages 20000 -size 1500 -interval 5000 -batch 5000 -subject PERF
RVPERFS - SUBJECT PERF
For subscriber(slave )
EMS stands for Enterprise message service
EMS is based on JMS specification
JMS--- Java message service
EMS is based on TCP protocol
EMS follows Hub and spoke architecture
EMS supports 3 types of communication models
Synchronous
Asynchronous
Asynchronous with reply
EMS synchronos and asynchronous with reply are flexible than RV synchronos and
asynchronous with reply
EMS supposts 2 messing models
Point to point
Publish subscribe
EMS point to point is more flexible than RV point to point
RV publish subscribe is faster and flexible than EMS publish subscribe
Point to point messaging modal works under a domain called queue
Publish subscribe under a domain called TOPIC
In order to connect to a EMS server for point to point communication application
should specify new connection factory and for message exchange they should
specify the destination as QUEUE
For publish subscribe communication application should specify topic connection
factory for connecting to EMS server and they should specify topic for message
exchange

Queues and Topics are logical destination for information

Queue connection factory Topic connection factory Queues and topics will be
created by EMS administrator and thy will be assigned with JNDI names and will be
stored in JNDI location of EMS server
JNDI is a directory in which resources will be stored as name object pairs
The EMS client applications should perform JNDI look up by specifying names of
connection factory object and the destination when the look up si success they will
be return with connection and reference to destination
One connection factory object can generate multiple connections
One connection factory object can be used by multiple client applications
In EMS for each message there will be at least 2 acknowledgments
1 accknoledge will be from EMS server to the message sender after EMS server
receives message successfully
2nd acknoledgment will be from message receiver to the EMS server after
receiver receive the message successfully
For each received message the receiver should send confirmation to the EMS
server
When EMS server receives acknowledgmenet fro m the receiver then only it
assumes that message has been delivered successfully and then it will delete
the message from the destination.
If the receiver dose not ackledge the message the EMS server assumes
message has not been delivered and it will continuously redeliver the message
to the receiver
We can explicitly specify the number of times EMS server should redelever
unacknowledge message using a property called maxredelivery"
After Maxredelivery occurs the message will be deleted this property can be
specified only for queues.
Fig
In point to point each message there will be exactly one receiver
Point to point provides one to one message delivery
When sender sends message to EMS server and when EMS server receives the
message successfully it will put the message on to queue and then it will send
acklodment to the sender
If the receiver is active it will deliver the message to the receiver and when EMS
server receives acklodment from the receiver it will delete the message from
the queue

By default it is not necessary for the receiver to be online in order to receive

messages
EMS server will store all the messages that are sent by sender during receivers
absence and when ever receiver becomes online it will deliver the messages to
the receiver
By default the queue can receive online messages and offline messages also.
1.
2.

Two types of queue's

Exclusive
Non exclusive
The default is non exclusive queue
Exclusive and non exclusive will be considered only if queue is configured with
multiple receivers or multiple receivers are listening on the same queue.
The advantage of non exclusive queue with multiple receivers is EMS server
provides load balanced message delivery for the queue receivers
When ever sender sends messages to non exclusive queue if multiple receivers
are active EMS server will deliver one message to one receiver at a time in
round robin. If non exclusive queue has pending or offline messages when
multiple receivers becomes online based on PRE-Fetch property it will deliver
the messages to the receivers in round robin.
By default the pre-fetch value is 5 for topic 64.
The advantage of exclusive queue with multiple queue receivers is EMS server
provides fault tolerant based message delivery for the queue receivers
If a queue has exclusive property that queue is called exclusive queue
For exclusive queue and for online messages and for offline messages EMS
server will deliver all the messages to the receiver who ever connects first
Start EMS server
7222 default port number
Go to tibco ems and select start ems adminstraator
Connect tcp://localhost:7222(enter)
UN:(enter)
PW:(enter)
We need to create factory object
CREATE FACTORY SENDER.QCF QUEUE(ENTER)
TO SEE THE PROPERTIES OF THE FACTORY OBJECT

SHOW FACTORY SENDER.QCF

TO ADD PROPERTIES
ADDPROP FACTORY SENDER .QCF URL=tcp://localost:7222
CLIENTID=SENDERNODE
IF WE CROSS CHECK IT WILL SHOW THE NEW UPDATES
CREAT E ONE MORE FACTORY
CREATE FACTORY RECEIVER.QCF QUEUE URL=tcp://localhost:7222
clientid=receiver
SHOW FACTORIES
SHOW FACTORIES QUEUE
CREATE QUEUE POLICIES.QUEUE
TO SEE THE PROPERTIES
SHOW QUE POLICIES.QUEUE
SHOW STACK QUEUE POLICIES.QUEUE
To fine out how many clients are connected
SHOW CONNECTIONS
To fine out complete details
SHOW CONNECTIONS FULL
To find out how many subscribers are connected
SHOW CONSUMERS
SHOW CONSUMER <id>
Ex: SHOW CONSUMER 1
Select the queue Polocy queue
Select input specify Policy. Request-101
Configure the receiver
Specify JMS Queue receiver
Connection specify the receiver
Message type text
Acknowledge mode auto
Destination que browse "policies.queue"
ADDPROP QUEUE POLICIES.QUEUE EXCLUSIVE
What if the receiver is not sending acknowledgment

Select receiver 1
Go to queue receiver
Change the acknowledge mode to client
Run the sender and send one message
Lets set the property max redelivery
ADDPROP QUEUE POLICIES.QUEUE MAXREDELIVERY=10
Undelivered queue if queue has max-redelivery property when redelivery limit
exceeds the message will be deleted from source queue. If the sender specify a
JMS property called "JMS_TIBCO_PRESERVE_UNDELIVERED". Them
unacknowledged messages after max redeliver limit will be redirected to
undelivered queue.
Undelivered queue will contain unacknowledged messages and expired
messages for the destinations which has the properties max redelivery and the
undelivered queue is "$sys.undelivered "
To set the JMS_TIBCO_PRESERVE_UNDELIVERED at the sender
Get JMS application
Properties
Select sender go to advanced
Go to JMS application properties a
D specify the jms application properties
Select input
Specify "true" at jms tibco preserve undelivered
By default the message will be on the destination till EMS receives
acknoledgment from the receiver we can explicitly specify the life time of
message by using the property JMS Expiration
Select que sender---> input ---> jms expiration----> specify 60
Select receiver and change the acknowledge mode to auto
Create one jms connection------------> name-----> JMS_admin_conn
Get a process
Name---> DELIVERY_NACK_AND)EXPIRED_MSGS(ADMINTASK)
SPECIFY ONE jms RECEIVER AND ONE jms Que sender

Connection-> select jms admin conn

Destination que ---> $sys.undelivered
Select que sender
HMS connection---> jms_Admin_conn
Sestination que----> polacie queue
Select input
Map body to body
Run only admin and receiver
GET JMS QUEUE Message
By default the queue receiver will receive all the messages from the queue in
order to receive specific message at a time we can use "Get JMS Queue
Message Activity"
For this activity we need to specify a message selector which specifies the
message that needs to be received.
First select JMS application properties
Go to properties and specify
REQUEST_ID
Set the type to string
Have one process
Message_Picker
Jms connection
Name---> JMS_conn_message_picker
Select the process message picker
Specify JMS que message
Start--->get jms ue message ---> end
Select the Get Jms Que message
Jms connect JMS message picker
Que Polacie queue
Advanced
JMS application property ---> JMS application property
Message selector----->REQUEST_ID='REQ-202'
Select the sender process

Name-->101
Input
Request_id --> "REQ-101"
Body---> "REQ-101"
Copy past the sender
Change all the 101's to 202
Also create more 303,404 etc
Select 202
Create a group
Repeat un till true
h(Index)
$h >= 2(condition)
First run the sender
Run the message picker
PUBLIC subscribe
In public subscribe each message can be received by multiple subscribers thats
why the public subscribe offers one to many message delivery.
When ever publisher publish message to EMS server EMS server will deliver that
message to all active subscribers.
By default all the subscribers should be active in order to receive messages
while publisher is publishing messages other wise they can not receive
messages
Thats my the default topic subscribers are called non durable subscribers
A non durable subscriber is a subscriber who can receive messages only when
he is online
EMS server dose not provide offline messages for non durable subscribers
If a topic has only non durable subscribers EMS server dose not store pending
messages for that topic
A durable subscriber is a subscriber who can receive online messages and
offline messages
EMS server will hold the messages which were published during durable
subscriber absence and when ever durable subscriber becomes online EMS
server will deliver all the offline messages to the durable subscriber the EMS
server will store the messages on to the topic only if the topic has at least one
durable subscriber
There are two ways of creating Durable subscriber
1.
By EMS administrator
2.
Dynamically by applications
For EACH SUBSCRIBER THE EMS SERVER WILL MAKE COPY OF MESSAGE AND
WILL BE DELEVERED
But where as in the case of RV broadcasting irrespective of number of
subscribers the message will be traveled on the network only once.

Even though at messaging level the public subscribe of EMS provides one to
many message delivery internally the EMS server will treat each subscriber as a
point to point messaging
We are not suppose to make all the applications as durable subscribers
When ever a durable subscriber is created a mirror image for the actual
subscriber will be created even though the message will be received by actual
subscriber and send conformation still EMS server will store the messages.
The EMS administrator should carefully check and delete the messages from
durable subscribers
Fig
New project --- > ems.topics
JMS
JMS connection
Name: JMS_CONN_PUB
Go to advanced
PUB.TCF
One more JMS connection
Advanced topic--- SUB.TCF
Copy past JMS connection
That makes one publisher and two subscribers
Get a process
Name PUB
One more process
Name Sub1
Go to Publisher process
Get a JMS topic publisher
JMS connection select JMS Conn PUB
Topic select the topic---- policies.request.topic
Select Input in Body--- "vehicle policy"
Select sub one
JMS topic subscriber
Connection JMS connection sub1
Topic policies.request.topic
Copy past that process

Change the connection to JMS connection sub2

Load all the 3 process in the test
To make one subscriber as durable subscriber
Create durable POLICIES.REQUESR.TOPIC ds
SHOW Durable
SHOW Durable ds
Select topic subscriber
Check the potion durable subscriber
Subcriber name ds
To register run the subscriber which we have changed to durable
To see the actual storage the command is
SHOW DB ASYNC
Show consumers
How can the ems adminstrator can delete the messages form the mirror image
Command is-----> purge durable ds
Durable subscription dynamically
Sub2 process
Select durable subscription
Sub name dyn-ds
Run the sub2 once
Message select
Using message selectors a subscriber can explicitly specify the type of
messages that he want to receive
The message selector will be applied on the EMS server while delivering
messages to the subscribers
Message selectors follows SQL 92 syntax
Message selectors can not be applied on message body elements we should use
only header properties which are also referred as JMS application properties
Sub1 want to receive only vehicle policies
Sub2 wants to receive only health and properties policies
Specify one JMS application properties
Define one property "+"
Policy_Type
Type--->string

vehicle policies_type='VEHICLE'
vehicle policies_type='VEHICLE'
Select Sub1
Topic subscriber
Go to advanced
Go to jms application properties and specify JMS application properties
Message selector---> policies_type='VEHICLE'
Select Sub2
Topic subscriber
Go to advanced
Go to jms application properties and specify JMS application properties
Message selector---> policies_type in =('HEALTH','PROPERTY')
Select publisher
Select topics publisher
Advanced
JMS application properties--- JMS application pro
Copy past the topic subscriber
Change the names to vehicle, health and properties
Select property input
Other properties---- policy type---- "PROPERTY'
Do mapper check and repair
Health
Policy type --- "HEALTH'
Do mapper check and repair
Select vehicle
Policy type --- "velicle"
Destination Bridge
Using destination bridging a message can be redirected to multiple destinations
which exist in the same server.
A bride can be created between topic to topic
Topic to queue
Que to toipc
And queue to queue
Bride direction should be uni directional only we are not suppose to create
bridge which results in bi-directional

The advantage of bridge is with out resending same message multiple times
and with out reconfiguring the applications messages can be delivered to or
redirected to multiple destinations
There are 2 ways of creating bridges
Bridge.config---------------[<TYPE OF DESTINATION>:<NAMEOF DESTINATION>]
<TYPE OF DESTINATION>=<NAMEOF DESTINATION>
2.
EMS ADMIN TOOL
a.
CREATE BRIDGE SOURCE=<TYPEOF DESTINATION>:<NAMEOF
DESTINATION>
Target=<TYPE OF DESTINATION>=<NAMEOF DESTINATION>
From ems admin tool we can bridge only one destination with another
destination but from bridges.configaration file we can bridge one destination
with one or more destinations
1.

Create queue POLICIES.MONITOR.QUEUE

Create bridge source=TOPIC:POLICIES.REQUESTS.TOPIC Target= QUEUE=
POLICIES.MONTOR.QUEUE
Show topic policies.request.topic
TO test lets have a JMS connection ----- JMS_CONN_MONITOR
Have a process ---- POLICIES_MONITOR
Specify one QUEUE receiver
Go to connection and select a connection
Specify the queue ----POLICIES.MONTOR.QUEUE
If we delete the bridge
Queue receiver will not receive any messages
Delete bride command
Delete bridge source=TOPIC:POLICIES.REQUESTS.TOPIC Target= QUEUE=
POLICIES.MONTOR.QUEUE
Create bridge source=TOPIC:POLICIES.REQUESTS.TOPIC
TARGET=QUEUE=POLICIES.MONITOR.QUEUE SELECTOT="POLICY_TYPE IN
('VEHICLE','HEALTH')"
Ems Route
Am EMS route enables message routing across EMS servers the destinations
that are part of message routing should have the property global
Topic names should be same in all the routed servers
In the routed servers the QUE name should be name of the QUEUE in the
routing server @name of routing server

This queue is called Remot queue or routed que

In which ever server publisher exists route should be created in that server
Two types of routers
1.
Active routeh
2.
Pasive routers
Active route is the one in which publisher exists the messages will be published
connections will be initeated and the routhe information will be in local routes
configuration file
Pasive route is the one which accrpts qiuted connections receives messages
and whos routes configuraton will be dynamically created by remote host by
default all the routs belongs to zone
A ZONE defines or restrits the functionality of EMS server routing
There are 2 types of zones
1 hop
Mhop
Default is mhop
In mhop zone topic messages can be routed to one or more servers queue
messages will be routed to only one server
In 1 hop zone topic messages and queue messages can be routed to only one
server
The subscriber which is in the routed server is not supposed to be configured
with no acknowledge acknowledgment mode
For providing _______________ at the server level internally the EMS server
maintains temporary durable
We are not supposed to create route which results in cycle
Copy past the ems folder 2 times
Past it in other server in tibco folder
The syntax for creating route is
1.
Routes.config
i.
[route=name]
ii.
Url=<route ems server location>
2.
EMS admin tool
i.
Create route [route-name] url=<routed ems server location>
Go to broadcasting server go to bin folder
We need to enable routing
For that open the configuration file tibemsg
Server = broadcasting_ems_ server
GO to listen and specify some port number 10000(for 7222)

Go to routing set to enabled

Open routs configuration file
Subscribers-ems-server
Localhost:20000
Zone_name=SEATTLE------------ optional
Open Queues configuration file
SERVICES.WIMAX.LTE GLOBAL
Open topics configuration file
SERVICES.WIMAX.LTE.DISTRIBUTION GLOBAL
Open factories config file
[ROUTE.QCF]
Type=queue
URL=tcp://localhost:10000
[ROUTE.TCF]
Type=TOPIC
URL=tcp://localhost:10000
Go to second server subscribers _server
Go to bin
Go to tibemsd
Specify the server name ---- SUBSCRIBERS-EMS-SERVER
Listen port----- 20000
Ser the routing to ----- enabled
Open queues config file
SERVICES.WIMAX.LTE@BROADCASTING-EMS-SERVER GLOBAL
Open topics
Services.wimax.lte.distribution global
Open factories config file
[ROUTE.QCF]
Type=queue
URL=tcp://localhost:20000
[ROUTE.TCF]
Type=TOPIC
URL=tcp://localhost:20000

To start the server

Go to the server location from command prompt
c:/> cd d:\adv_ems\broadcasting_Server\bin
And run the command
Tibemsd
Start admin tool for that
Go the the bin location
And run the command
tibemsadmin
Connect to the server command
Connect tcp://localhost:10000
Start the second server
Go to the location fo seond server
d:\adv_ems\subscriber_Server\bin
Run the command ----- tibemsd
Start admin tool for that
Go to the bin location
Run the command--- tibemsadmin
Check the routs
SHOW ROUTES
SHOW ROUTES BROADCASTING -EMS-SERVERS
To test the routers if they work or not
Got a JMS connection
In the new project
Name jms conn 10000
Jmdi context url change 7222 to 10000
Go to advanced
Sepcify the factortdetails
Route.tcf
Route.qcf
Specify another connection
Got a JMS connection
In the new project
Name jms conn 20000

Jmdi context url change 7222 to 20000

Go to advanced
Sepcify the factortdetails
Route.tcf
Route.qcf
Specify two process definitions
PUBLICSHERS_10000
Open the process
Specify one queue sender and one topic publisher
Select quesender
Got the jms connection --- jms conn 10000
Specify the queue
Input specify some message in the body--- "route testing"
Select topic publisher got the connection --- jms conn 10000
Specify the topic
Go to input specify message "route testing"
Start to jms que sender to end
Start to topic publisher to end
Select second process
Name subscribers_20000
Go in to the process
Select wait for jms topic message
Wait for jms queue message
Select jms wait for topic select the connection 20000
Specify the topic
Go to wait for jms queue message
Select jms connection
Specify the queue
Run the test on bot the servers
First start the subscribers
Then publish the message
Start to wait for jms topic message to end
Start to wait for jms que message