Introducing the all-new TIBCO Community site!

For current users, please click "Sign In" to reset your password and access the enhanced features. If you're a first-time visitor, we extend a warm welcome—click "Sign Up" to become a part of the TIBCO Community!

If you're seeking alternative community sites, explore ibi, Jaspersoft, and Spotfire.

Jump to content

HA issues with "TIBCO RV Adapter for TIBCO FTL"

Recommended Posts

I'm executing the following scenario:

Sender RV (custom) -> "TIBCO RV Adapter for TIBCO FTL" -> "FTL Cluster" (3 nodes, same machine for testing purposes)-> Receiver FTL (custom)

I'm logging everything I send and receive to be able to verify integrity. Sender is sending ~3mb/s using ~1024 bytes packages. I am using "Shared Memory" transport for the endpoints and "Auto" for communication among clusters/stores.

1) If nothing is restarted in this scenario, integrity check is OK.

2) If I keep restarting "Receiver FTL" and handle duplicated packages properly, integrity check is OK. Durable does its job.

3) If I keep restarting cluster elements to test HAusing these steps:

- Kill cluster element 1, wait 4 seconds, start cluster element 1, wait 15 seconds, kill cluster element 2, etc.

I can see little pauses (a backup node takes leadership, clients reconnect), and everything keeps working. However, my integrity check FAILS, because I lose about 13% of the packages in "Receiver FTL" during several points of the transmission.

4) If instead of "publisher_settings": "store_send_noconfirm" I switch to "publisher_settings": "store_confirm_send", integrity check is OK, however in this configuration I experience severe performance issues (I'm unable to keep receiver rate at 3mb/s in a very powerful physical server).

So my questions are:

a) Is this behavior OK 100% of delivered packages is only possible in "store_confirm_send"

b) Is it expected to not be able to handle 3mb/s in "store_confirm_send" or I'mconfiguring something wrong

I can provide more information about the scenario if necessary.

Thank you in advance.

Link to comment
Share on other sites

  • Create New...