rvcm
DESCRIPTION
rv certified messagingTRANSCRIPT
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
In certified delivery three advisory ___________ and messages will be used
3. Delivery Confirm
4. Delivery complete
5. Delivery 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."
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.
Two types of queue's
1. Exclusive
2. 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
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
1. Bridge.config----------------
[:]
=
2. EMS ADMIN TOOL
a. CREATE BRIDGE SOURCE=:
Target==
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
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=
2. EMS admin tool
i. Create route [route-name] url=
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