Losing packets with implicit ACK

[Antonio Fermiano]

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

[Antonio Fermiano]

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.