EMA C++: Setting service name in AckMsg on provider leads to time-out on consumer

[miczuc]

Hello.

I tested a little with Post messages. I had the phenomenon, that acknoledgement messages sent from my provider
did not arrive at the consumer. The consumer runs into a time-out, and after that elapses, generates an AckMsg with properties:
"Nack Code: NoResponse"
"Text: Acknowledgement timed out."

Therefore I tested your examples "IProvider/300_Series/340_MP_Posting", "Consumer/300_Series/340_MP_OnStreamPost", "Consumer/300_Series/341_MP_OffStreamPost".
There the acknoledgement message is received in the consumer (both in the on-stream and in the off-stream example), so it works as expected.
I wondered, what the difference was to my own programs. Finally I found out, that the problem arises, when a service name is set in the acknoledgement message. To proof that, I changed your example code in IProvider/300_Series/340_MP_Posting/IProvider.cpp slightly, as follows:

void AppClient::onPostMsg( const PostMsg& postMsg, const OmmProviderEvent& event )
{
// if the post is on the login stream, then it's an off-stream post, else it's an on-stream post
cout << "Received an " << (event.getHandle() == loginStreamHandle ? "off-stream" : "on-stream") << endl;

cout << postMsg << endl;

if (postMsg.getSolicitAck())
{
	AckMsg ackMsg;

	ackMsg.domainType(postMsg.getDomainType());
	ackMsg.ackId(postMsg.getPostId());
	if (postMsg.hasSeqNum())
	{
		ackMsg.seqNum(postMsg.getSeqNum());
	}
	
	ackMsg.serviceName( "DIRECT_FEED" ); // leads to time-out on consumer
	//ackMsg.serviceId( 1 ); // does not do harm

	event.getProvider().submit(ackMsg, event.getHandle());
}

}

After this change, both the consumer 340 and the consumer 341 run into the time-out for receiving the expected acknoledgement.

E.g. the consumer 340 outputs after some time:

Received: AckMsg
Item Handle: 20870816
Closure: 0x1
Item Name: IBM.N
Service Name: DIRECT_FEED
Ack Id: 1
Nack Code: NoResponse
Text: Acknowledgement timed out.

while, if the instruction 'ackMsg.serviceName( "DIRECT_FEED" );' is removed in the provider, it outputs immediately:
Received: AckMsg
Item Handle: 33900192
Closure: 0x1
Item Name: IBM.N
Service Name: DIRECT_FEED
Ack Id: 1

So there is something wrong. The version is 2.2.2 .

Regards, Michael Zuck

[ViktorYelizarov]

@miczuc
Thank you for bringing this issue to our attention! We created an internal Jira to investigate it.

[vlevendel]

@miczuc The issue is that when you specify a serviceName, we're using the wrong flag on the outgoing Ack and sending out a sequenceNumber (in this case the Cons340 application does not specify a sequenceNumber on the post and this is un-expected). This results in the consuming side dropping the received Ack as an invalid message, and, later timing out and manufacturing a local Ack to fanout to application for the Post.

This is a minor fix to the flag. Thank you for finding this issue. It will be made available in an upcoming release.

Regarding serviceName: EMA associates a serviceName with a serviceID (done in source directory refresh message) and serviceID is used over the wire. The EMA application can either specify a service name using, "ackMsg.serviceName("DIRECT_FEED");" or use serviceId, "ackMsg.serviceId(postMsg.getServiceId());" when creating an AckMsg.

[vlevendel]

@miczuc This is addressed with version Real-Time-SDK-2.2.3.L1.