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

Losing packets with implicit ACK


Recommended Posts

We are evaluating TIBCO FTL solution for our product, however I'm having some issues.

Scenario:

1) Application A (publisher) sending packages to application B (subscriber).

2) Multicast transport.

3) Prefetch != 0, therefore using durable as message broker.

4) Windows server 2012, everything in the same machine, including FTL server.

5) Packet size: 1024 bytes.

6) Data rate: 12mb/s (~12200 packets per second).

7) Managed format.

8) Using C library.

I'm playing with message delivery reliability, so application B:

1) Closes itself each 2 seconds - first time closing gracefully return 0 after finishing a callback, second time with a segfault inside the callback function. This simulates a complete disaster situation.

2) Application B handles duplicated packets properly, as far as I can see.

3) Both application A and application B logthe content they sendand receive, so I can compare if the durable delivered everything to application B, even with all the carnage.

If I use "implicit ACK", or in other words, if I use TIBCO API in application B as:

tibProperties_SetBoolean(ex, props, TIB_SUBSCRIBER_PROPERTY_BOOL_EXPLICIT_ACK, 0);

(or just omit it)

Then I receivemost of the packages in application B, but I still lose a few parts:sometimes I lose a single packet, sometimes a whole block.

If I use "explicit ACK", meaning:

tibProperties_SetBoolean(ex, props, TIB_SUBSCRIBER_PROPERTY_BOOL_EXPLICIT_ACK, 1);

and acknowledge each packet individually:

tibMessage_Acknowledge(ex, msgs);

I don't miss anything in Application B.

I have attached the configuration JSON I'm using (Application: rvftlconverterapp, Application A = endpoint1, Application B = endpoint2).

Does it make sense to miss packets when using explicit ACK Am I misusing the API Am I configuring it wrong Is it a bug

Link to comment
Share on other sites

  • 1 month later...

In my original questions, I said: "Prefetch != 0, therefore using durable as message broker".

 

Revisiting the manual, I understand that it's recommended that prefetch is zero in case of direct connection, but this value does not decide  if FTL is going to make a direct connection or message broker pattern.

 

If that's true, it's not clear to me how to configure a direct connection or message broker pattern...

 

Can explain me better please If both endpoints in a application have compatible transports (e.g: shared memory transports pointing to the same memory segment) then is direct connection between both guaranteed

 

Thank you.

Link to comment
Share on other sites

×
×
  • Create New...