Http Interface of Tibco RV

In this post I am sharing you great tool to solve TIBCO RV related problems and a great interface to anaylze RVD activities. U can check netstat command to figure out which topics are subscribed by RVD but after since U know about this I had helped me a lot.

Every host where tibco rvd is running expose on HTTP interface using that we can get many useful information e.g

— How many clients are connecting to a particular service

— Which services has been subscribed by rvd with multicast address

— Which hosts are connected to this rvd (using Remote RVD).

— How much data has been sent to received

— Viewing tibco log to figure out any tibco issue.

— Hwo many subject a particular service is using and what are those etc.

to check on which Http port your rvd is publishing information do this in your linux/windows host where rvd is running

ps -ef | grep rvd

this will show rvd process with parameters used for starting “-http 7582” shows that http interface is on port 7582

now just type this in your browser.

http://hostname:7582/

[TIBCO] RVD (Rendezeous daemon) vs RVRD (Rendezeous Routig Daemon)

Hi Folks,

Coming back after long gap with a very useful information!!

RVRD (Rendezvous Routing Daemon) are simply process owned by middleware or network teams which listens multicast traffic locally and transmit it to another RVRD counter part (another host) using TCP. This remote host than re multicast this traffic to there own network. So essentially it used to bridge two different regional network e.g. London and Newyork etc.

RVRD is multicast in one end and unicast on other end so it receives messages from multiple RVD (Rendezvous Daemon) and send via TCP to another RVRD which distributes messages on different RVD (Rendezvous Daemon) on there own network e.g. say on NY network.

Control of RVRD (Rendezvous Routing Daemon) resides on middleware/network team and they decide which topics/subject is allowed for RVRD (Rendezvous Routing Daemon) traffic. So if you send message on a topic which is not configured on RVRD and subscriber for that service is on some another physical network it will not receive those messages until that topic is enabled on RVRD (Rendezvous Routing Daemon) front.

On the other hand RVD (Rendezvous Daemon) is a background process runs on every host which wants to send or receive message from tibco multicast network. Your process depends upon this for reliable and efficient network communication. all messages goes via rvd before it enters or leaves host on a multicast network and RVD (Rendezvous Daemon) is responsible for creating packets or assembling packets to and from the network.

If you want to send messages from Asia to Europe using Tibco RV, it will be much faster by using local daemon rather than connecting to a remote daemon situating on that region.
On points
— RVD transmit outbound message from your program to network.
— RVD delivers inbound message from network to your process.
— RVD takes care of Operating system specifics and encapsulates those leaving your process independent of such low level details.
— RVD daemon can be start automatically if its not running already ,may exit after some specified period of inactivity.

TIBCO: Enterprise Message Service™ 8 exam – TB0-126 Exam -certification

You may have heard the recent news of TIBCO retiring its Enterprise Message Service™ 7 exam (TB0-125) on May 15, 2014. Its replacement was released 2 days later, on May 16, branded as TIBCO Enterprise Message Service™ 8 exam (TB0-126). Before we look into the details of the new exam, let’s have a quick overview of TIBCO and its certification program, since we’ve received a few questions about it recently.

Light on TIBCO

TIBCO is an American software company, based in Palo Alto, California (yes, another one from the Silicon Valley). TIBCO provides software for companies to use on-premises or as part of cloud computing environments to manage information, decisions, processes and applications, and the company’s market capitalization reportedly exceeds $5 billion.

Founded in 1997, TIBCO specializes in infrastructure software that primarily focuses on real-time communication for B2B, B2C and B2E data transfers, including facilitation of communication between otherwise incompatible software. TIBCO’s most popular products are TIBCO ActiveMatrix, TIBCO ActiveSpaces Datagrid, TIBCO BusinessEvents, TIBCO Enterprise Message Service ,TIBCO FTL, TIBCO LogLogic, TIBCO MDM, TIBCO Rendezvous, TIBCO Silver, TIBCO Spotfire, TIBCO tibbr, TIBCO TopLink.

TIBCO Certification Program

TIBCO Certifications validate holders’ competency in design, development, deployment, and administration of TIBCO’s application and infrastructure technologies. TIBCO certification path consists of three levels:

TTP – TIBCO Trained Professional
TCP – TIBCO Certified Professional
TCA – TIBCO Certified Architect

To become TTP, a candidate needs to meet relatively simple requirements:

To have attended TIBCO training
Passed online Knowledge Assessment
Available for most TIBCO courses

The next credential, TCP (TIBCO Certified Professional) has a number of corresponding exams:

NEW: TIBCO Enterprise Message Service™ 8 exam (NEW)
Architecting Complex-Event Processing Solutions with TIBCO
Architecting Composite Applications and Services with TIBCO
TIBCO ActiveMatrix BusinessWorks™ 5
TIBCO Rendezvous® 8
TIBCO ActiveMatrix® BPM Solution Design
TIBCO BusinessEvents® 5
TIBCO® MDM 8

NEW: TIBCO Enterprise Message Service™ 8 Exam

The New TB0-126 exam consists of 64 questions which candidates need to answer within 90 minutes. To pass it, the minimum passing score of 62% has to be reached. TIBCO Enterprise Message Service™ 8 exam validates the skills necessary to develop and administer a TIBCO Enterprise Message Service 8 messaging solution of average complexity with minimal supervision or assistance. Successful candidates should be able to identify the key architectural features and the role Enterprise Message Service fills in a messaging solution. Supplied with the required configuration details, a qualified candidate will be able to develop simple Enterprise Message Service applications, manage an Enterprise Message Service installation and understand its capabilities.

TIBCO recommends that candidates have one year of Enterprise Application Integration development experience with solid working knowledge of Windows or Unix, Networking (TCP/IP, Multicast), SSL, JNDI, exposure to Message Oriented Middleware, C, C# or Java coding ability, Oracle JMS Specification 1.1, and general experience with databases.

According to TIBCO official website, TB0-126 exam topics and objectives are as follows (please visit TIBCO official website for details):

Architecture and Design
Messaging
Destination Bridging
Naming Services
Routing
Load Balancing
Performance Tuning
Security
Transactions
Inheritance
Data Store
Application Development
Programming Model
Administration

As part of exam preparation, TIBCO recommends the following reading and reference resources:

TIBCO Enterprise Message Service: User’s Guide, Central Administration, and Installation and Configuration
TIBCO Enterprise Message Service Appliance Standard Edition: Installation and Reference
TIBCO Enterprise Message Service Central Administration: Concepts, Configuration and Deployment, and Installation
Documentation for TIBCO products available through the TIBCO Product Documention site.

More details can also found on http://www.kr.tibco.com/services/educational/certification/TB0-126.jsp

I really hate EMS version 8 & jason file concept – many bugs with routes functionality

Hi friends,

I really hate EMS version 8 & jason file concept – many bugs with routes functionality

I faced many routes issues with version 8 & raised SR# with TIBCO team to find resolution . Does anyone else faced similar problems?

TIBCO EMS Pre-fetch Property in EMS

Pre-fetch Property in EMS :-

Increasing pre-fetch value definitely improves performance while processing large volume of messages. However below are two factors to consider.(as per EMS users guide).

1)If both prefetch and maxRedelivery are set to a non-zero value, then cthere is a potential to lose prefetched messages if one of the messages cexceeds the maxRedelivery limit. For example, prefetch=5 and maxRedelivery=4.
The first message is redelivered 4 times, hits the maxRedelivery limit and is sent to the undelivered queue (as expected). However, the other 4 pre-fetched messages are also sent to the undelivered queue and are not processed by the receiving application.

2) When a queue consumer prefetches a group of messages, the server does not deliver them to other queue consumers (unless the first queue consumer’s connection to the server is broken)

However, we can ignore 2nd point while processing large volumes of messages

EMS Connections status -Troubleshooting

Just adding a useful info about EMS connection troubleshooting. When we get TIBCO EMS connectivity issue, first thing that we generally check which connection was not closed gracefully. EMS logs provides this information by ‘reason’ field. Whenever a client disconnect it connection or connection is disconnected due to any reason, EMS server will log this event in its log file and specify the reason for disconnection. A closure of connection will have reason as reason:connection closed.

If this is the case you can close the unused connection or will have to bounce if application owners are okay.

You can have monitoring to trace connection status to find from where its coming as well
EMS logs:-

A good connection log is below. This indicates that connection was closed properly.
2014-09-20 11:16:18.843 [tibco@DTC2100CC3B24C2]: Disconnected, connection
id=22923192, reason: connection closed (iothr.c:162)

A bad connection termination log is below. This indicate that connection was not closed gracely.
2014-09-20 23:37:51.923 [tibco@DTCJPR8BLAFN]: Disconnected, connection
id=383967, reason: connection terminated (iothr.c:162)

BLOG NAME CHANGE on Sunday (Aug 31,2014) :- Please update book mark with NEW one (TIBCOWITHSIVA.WORDPRESS.COM)

TIBCO EMS JSON Configuration Files -No more multiple cfg’s.

When Central Administration is used, TIBCO Enterprise Message Service stores server configuration settings in a single JSON-based configuration file. This file holds the entire configuration of the server without the need of sub-files. Furthermore, a single JSON configuration file holds the configuration settings for a pair of fault tolerant servers. The default name of the JSON-based configuration file is tibemsd.json.

The JSON configuration standard was introduced in TIBCO Enterprise Message Service software release 7.0. With TIBCO Enterprise Message Service software release 6.x and earlier, the configuration of the EMS server was stored in a set of text-based configuration files with names ending in .conf. The main configuration file name defaults to tibemsd.conf and a set of sub-files such as queues.conf hold information on specific types of configuration items.

A 8.x EMS server can be started either with a set of .conf files or with a single .json file. However, the EMS server can be managed through the Central Administration feature only if it has been started with the JSON file. EMS servers started with a set of .conf files cannot be managed using the Central Administration server.

Question this time :- RVD cpu affinity and Ring Buffer

This time it’s question and let’s share our thoughts here ..
Q:- Does anyone have more details about cpu affinity and Ring Buffer for RV.

How does the setup works and where exactly it makes difference?

Tibco EMS queue properties .. Good to know

SNFGXIBCT : –> Prints information on the topic properties in the order
(S)ecure
(N)sender_name or sender_name_enforced
(F)ailsafe
(G)lobale
(X)clusive
(I)mport
(B)ridge
(C)flowControl
(T)race

The characters in the value section show:
– Property not present
+ Property is present, and was set on the topic itself
* Property is present, and was inherited from another queue
Note that inherited properties cannot be removed.

IMAGE