I am working with @cedric.nabaa in support ticket 07914617.

The problem is solved after removing the Payload from OMM reissue message.

Hello @cedric.nabaa

Can you enable the RFA trace file to capture incoming/outgoing message between API and TREP when the problem occurs, and give us the trace file?

You can configure the following RFA Java configurations to enable the log file

• <namespace>/Connections/<Connection Name>/ipcTraceFlags = 7
• <namespace>/ Connections/<Connection Name>/mountTrace = True
• <namespace>/ Connections/<Connection Name>/logFileName=<path to log file>

<node name="rsslConnection">
   <map>
      <entry key="connectionType" value="RSSL"/>
      <entry key="serverList" value="localhost"/>
      <entry key="portNumber" value="14002"/>
      <entry key="ipcTraceFlags" value="7"/>
      <entry key="mountTrace" value="True"/>
      <entry key="logFileName" value=".\logs\RSSL_%U.log"/>
   </map>
</node>

Please note that an official RFA Java API package/library is distributed via the API download page only, not via any Maven repositories.

Hello I am adding this and will try to push it to prod asap.

In the meantime, Can you please check what is the latest version of rdm? and why is it different from the rfa one that we are using?

By reading another thread, migrating to 8.1.0.L1 should have resolved the issue

@cedric.nabaa

As far as I remember, the fix for 8.1.0 is for RFA C++/.NET only. Also, from the original issue, it has no problem with RFA java. That why Wasin needs the RSSL Trace from you to review the issue.
Not sure why local infra suggest you to upgrade to RFA java 8.1 while you are using RFA Java, not C++/.NET.

okay i am trrying to add the logs : our project structure is the following: great-rt-feed/logs/
are you sure of the path .\logs\RSSL_%U.log ? we are on a linux server.

.\logs\RSSL_%U.log doesnt seem to add a new file:

<entry key="connectionType" value="RSSL" /> <entry key="serverList" value="server1" /> <entry key="portNumber" value="14002" /> <entry key="downloadDataDict" value="true" /> <entry key="dictionaryRequestTimeout" value="45000" /> <entry key="ipcTraceFlags" value="7"/> <entry key="mountTrace" value="True"/> <entry key="logFileName" value=".\logs\RSSL_%U.log"/>

this is our conf

here's what we have in the log for a closed Item in the RSSL_0.log:

<record> <date>2019-08-02T13:14:12</date> <millis>1564744452439</millis> <sequence>46896</sequence> <logger>com.reuters.rsslc.0</logger> <level>FINER</level> <class>com.reuters.ipc.TraceLogger</class> <method>traceData</method> <thread>38</thread> <message> Thread: _Default::GREAT_RT_FEED_PRD Session EventQueueGroup Connection 0 RSSL Client Message RECEIVE: 119 ---DATA TRACE--- MESSAGE Msg Type: MsgType.STATUS_RESP Msg Model Type: MARKET_PRICE Indication Flags: Hint Flags: HAS_ATTRIB_INFO | HAS_STATE Stream Id: 53 State: CLOSED, SUSPECT, USAGE_ERROR, "Request Rejected: Request message payload not supported on non-private streams." AttribInfo ServiceId: 374 Name: isSE0009496367.CBBT NameType: 1 (RIC) Payload: None </message> </record>

Is this enough @moragodkrit ?

We only had this issue after migrating to Trep3.2.2 previously we were on TREP 2 and did not face this issue

rssl1-0.zip This is a small extract from the big file where we have the issue happening.

Hi @cedric.nabaa

Thanks for posting the small extract file but I suspect my colleague will need a fuller trace - including the actual outgoing Request Message(s) for some of the Rejected requests.

Hello @cedric.nabaa

Based on the given error messages, the problem occurs with the following RICs

• CNYCNHIRS3Y
• EUREIBFIX2M
• isSE0009496367.CBBT
• USDSB3L12Y

Could you please give me the request message log (Msg Type: MsgType.REQUEST) and status response message (Msg Type: MsgType.STATUS_RESP) from above RICs?

The request message log will look like this:

SEND: 28
---DATA TRACE---
MESSAGE
	Msg Type: MsgType.REQUEST
	Msg Model Type: MARKET_PRICE
	Indication Flags: REFRESH
	Hint Flags: HAS_ATTRIB_INFO | HAS_QOS_REQ
	Stream Id: 3
	QosReq: (RT, TbT)
	AttribInfo
		ServiceId: 2114
		Name: USDSB3L12Y

And the status response message is the Msg Type: MsgType.STATUS_RESP with State: CLOSED, SUSPECT, USAGE_ERROR, "Request Rejected: Request message payload not supported on non-private streams." status.

Hello @cedric.nabaa

I did a quick check on the given files. I found that you sent a batch request message without a BATCH_REQ indication flags, then that request received Request Rejected status response message.

SEND: 70
---DATA TRACE---
MESSAGE
	Msg Type: MsgType.REQUEST
	Msg Model Type: MARKET_PRICE
	Indication Flags: ATTRIB_INFO_IN_UPDATES | REFRESH
	Hint Flags: HAS_ATTRIB_INFO | HAS_QOS_REQ
	Stream Id: 59
	QosReq: (RT, TbT)
	AttribInfo
		ServiceId: 204
		Name: USDSB3L12Y
		NameType: 1 (RIC)
	Payload: 44 bytes
		ELEMENT_LIST
			ELEMENT_ENTRY :ItemList: 
				ARRAY
					ARRAY_ENTRY: CNYCNHIRS3Y
					ARRAY_ENTRY: USDSB3L12Y

Based on RFA Java Developer guide, a batch request message requires BATCH_REQ indication flag (OMMMsg.Indication.BATCH_REQ) in the message. Can you set it in your batch request message and see if the problem still persist?

Example code is following:

int indicationFlags = OMMMsg.Indication.REFRESH| OMMMsg.Indication.ATTRIB_INFO_IN_UPDATES|OMMMsg.Indication.BATCH_REQ;
ommmsg.setIndicationFlags(indicationFlags);

This is my example RSSL trace message for a batch request that works fine.

SEND: 58
---DATA TRACE---
MESSAGE
	Msg Type: MsgType.REQUEST
	Msg Model Type: MARKET_PRICE
	Indication Flags: ATTRIB_INFO_IN_UPDATES | REFRESH | BATCH_REQ
	Hint Flags: HAS_ATTRIB_INFO | HAS_QOS_REQ
	QosReq: (RT, TbT)
	AttribInfo
		ServiceId: 2114
		Name: TRI.N
		NameType: 1 (RIC)
	Payload: 34 bytes
		ELEMENT_LIST
			ELEMENT_ENTRY :ItemList: 
				ARRAY
					ARRAY_ENTRY: GOOG.O
					ARRAY_ENTRY: TRI.N

@cedric.nabaa

If the problem still persist after setting a OMMMsg.Indication.BATCH_REQ indication flags in a batch request message, please give me a snippet code of the application that constructs a batch request message.

Hello we do set the flag to : OMMMsg.Indication.BATCH_REQ explicitely on every request:

setIndicationMask(RequestIndicationMask.BATCH_REQ);

I have checked every possible code branching and in all of them we do set this Indication Flag.

Hello, On the client application BATCH_REQ flag is always set, nevertheless when we encounter the bug we dont see this flag on the RFA log:

RFA Log:

<record> <date>2019-08-12T16:07:37</date> <millis>1565618857002</millis> <sequence>5516151</sequence> <logger>com.reuters.rsslc.0</logger> <level>FINER</level> <class>com.reuters.ipc.TraceLogger</class> <method>traceData</method> <thread>38</thread> <message> Thread: _Default::GREAT_RT_FEED_UAT Session EventQueueGroup Connection 0 RSSL Client Message SEND: 75 ---DATA TRACE--- MESSAGE Msg Type: MsgType.REQUEST Msg Model Type: MARKET_PRICE Indication Flags: ATTRIB_INFO_IN_UPDATES | REFRESH Hint Flags: HAS_ATTRIB_INFO | HAS_QOS_REQ Stream Id: 25804 QosReq: (RT, TbT) AttribInfo ServiceId: 202 Name: DE0001141711 NameType: 1 (RIC) Payload: 47 bytes ELEMENT_LIST ELEMENT_ENTRY :ItemList: ARRAY ARRAY_ENTRY: DE0001135424 ARRAY_ENTRY: DE0001141711 </message> </record>

Client log:

16:07:37.000 [RT_FEED_UAT-ItemRequestQueueDispatch-LoopThread-5] INFO c.s.g.r.f.r.SingleRequestReplyDispatch - serviceName: DTS_BONDS , batchName: BATCH_REQ1565618857000

The logs on the client side clearly states that we are setting the BATCH_REQ flag this log is beeing logged just before calling the register method.

As you can see from the logs above on the client app we can see that we create a batchName: BATCH_REQ1565618857000, this batch is never logged in the RFA Log and instead is replaced by Name: DE0001141711.

Maybe the encoding between our rfa version and the TREP 3 ADS contains bug:

this is our version in pom.xml :

dependency> <groupId>com.reuters</groupId> <artifactId>rfa-rdm-ext</artifactId> <version>8.0.0.L2</version> </dependency>

is this the latest version?

Antg else that might be causing this discrepency?

This is the code we use to encode:

final OMMEncoder encoder = ommPool.acquireEncoder(); try { encoder.initialize(OMMTypes.MSG, totalSize); encoder.encodeMsgInit(ommMsg, OMMTypes.NO_DATA, OMMTypes.ELEMENT_LIST); encoder.encodeElementListInit(OMMElementList.HAS_STANDARD_DATA, (short) 0, (short) 0); encoder.encodeElementEntryInit(RDMUser.Feature.ItemList, OMMTypes.ARRAY); encoder.encodeArrayInit(OMMTypes.ASCII_STRING, 0); for (int i = from; i < to; ++i) { encoder.encodeArrayEntryInit(); encoder.encodeString(itemNames[i], OMMTypes.ASCII_STRING); } encoder.encodeAggregateComplete(); // completes the array encoder.encodeAggregateComplete(); // completes the element list final OMMMsg finalMsg = (OMMMsg) encoder.acquireEncodedObject(); return finalMsg;

this is the code we use to set the flag:

ommMsg.setIndicationFlags(indicationFlag.convertToIntMask() | indicationMask.convertToIntMask()); ommMsg.setPriority(getPriorityClass().convertToByteMask(), getPriorityCount()); if (!indicationMask.isFlagSet(RequestIndicationMask.BATCH_REQ) && !getMarketPriceRequestAttrib().hasItemName()) { throw new GreatRtFeedDomainException("GreatMarketPriceRequest#GreatMarketPriceRequestAttrib", "OMMAttribInfo#Name", "REQUIRED Name when not a batch request"); }

and we never also get the Exception which confirms even more that the flag is set.

@cedric.nabaa

From the tracing, the request message doesn't have the batch request flag but it has the attribute name (DE0001141711).

---DATA TRACE--- 
MESSAGE Msg Type: MsgType.REQUEST 
Msg Model Type: MARKET_PRICE 
Indication Flags: ATTRIB_INFO_IN_UPDATES | REFRESH 
Hint Flags: HAS_ATTRIB_INFO | HAS_QOS_REQ 
Stream Id: 25804 
QosReq: (RT, TbT) 
AttribInfo ServiceId: 202 Name: DE0001141711 NameType: 1 (RIC) 
Payload: 47 bytes ELEMENT_LIST ELEMENT_ENTRY :ItemList: ARRAY ARRAY_ENTRY: DE0001135424 ARRAY_ENTRY: DE0001141711 

From the code, it will throw an exception when the batch request is not set and there is no attribute name.

 if (!indicationMask.isFlagSet(RequestIndicationMask.BATCH_REQ) && !getMarketPriceRequestAttrib().hasItemName()) {    

throw new GreatRtFeedDomainException("GreatMarketPriceRequest#GreatMarketPriceRequestAttrib", "OMMAttribInfo#Name", "REQUIRED Name when not a batch request"); 

}

With this code, it is possible for the application to send the request message without the batch request flag when the attribute name is set.

Hello,

We continue to investigate with Cedric and we saw that this issue only happens in case of reissue.

When we comment the line which allows the reissue we don't have the issue anymore.

From what we can see in the RfaDoc the BATCH_REQ is not needed during a reissue because handle are used. And it explains why it is not set in our case.

13.2.5.3 Batch Reissue

A consumer application can modify multiple event streams through one reissue operation. To use batch reissue, the consumer application does the following:

- Builds an OMMItemIntSpec with updated stream information (priority, pause or resume, view, refresh).

- Builds a List of Handles of the event streams to be modified.

- Calls OMMConsumer.reissueClient(), passing the OMMItemIntSpec and the List of Handles, as input parameters.

- The indication flag OMMMsg.Indication.BATCH_REQ does not need to be set, since the List of Handles signify to reissueClient() that this is a batch type operation.

Do you know if there is any change on the reissue behavior on TREP3 ?

We don't have the issue with the same code in TREP2.

Regards,

Benjamin

Hello @benjamin.farcy @cedric.nabaa

Please be informed that the latest version of RFA Java API 8 is 8.1.0E2.

I did a quick check with the OMMCosumer.reissueClient() function. If application inputs a List of item handles to the function, the API automatic adds BATCH_REQ indication flag for the application and sends reissue message with a List of item streams that want to be reissued.

I did a quick test with RFA Java StarterConsumer_BatchView example connects to both ADS 2.6.12 and 3.2.1. The example can send a reissue request message for multiple items without the BATCH_REQ indication flag successfully.

My reissue trace:

SEND: 42
---DATA TRACE---
MESSAGE
	Msg Type: MsgType.REQUEST
	Msg Model Type: MARKET_PRICE
	Indication Flags: ATTRIB_INFO_IN_UPDATES | REFRESH | BATCH_REQ
	Hint Flags: HAS_ATTRIB_INFO
	AttribInfo
	Payload: 29 bytes
		ELEMENT_LIST
			ELEMENT_ENTRY :StreamIdList: 
				ARRAY
					ARRAY_ENTRY: 4
					ARRAY_ENTRY: 5

Comparing my reissue trace message with your reissue trace message. I found that your reissue message payload contains the Element List of item names, not existing stream id(s). The message looks like a normal request message for multiple items more than a reissue message.

Your reissue trace message:

SEND: 71
---DATA TRACE---
MESSAGE
	Msg Type: MsgType.REQUEST
	Msg Model Type: MARKET_PRICE
	Indication Flags: ATTRIB_INFO_IN_UPDATES | REFRESH
	Hint Flags: HAS_ATTRIB_INFO | HAS_QOS_REQ
	Stream Id: 58
	QosReq: (RT, TbT)
	AttribInfo
		ServiceId: 204
		Name: CNYCNHIRS3Y
		NameType: 1 (RIC)
	Payload: 44 bytes
		ELEMENT_LIST
			ELEMENT_ENTRY :ItemList: 
				ARRAY
					ARRAY_ENTRY: CNYCNHIRS3Y
					ARRAY_ENTRY: USDSB3L12Y

Does the application use OMMConsumer.reissueClient(java.util.List<Handle> aHandleList,InterestSpec anInterest) function to reissue the item subscriptions? Could you please give me the application source code that creates OMM message and sends the reissue message?

Hello,

I did a test with the 8.1.0E2 and I still have the same issue.

Here is our code which allows the reissue :

final List<Handle> previousHandles = ctx.findPreviousHandle();
for (Handle previousHandle : previousHandles) {
    if (previousHandle.isActive()) {
        try {
            SingleRequestReplyDispatch.this.ommConsumer.reissueClient(previousHandle, ommItemIntSpec);
        } catch (Exception propagate) {
            ctx.notifyRequestFailed(RequestFailure.REISSUE_FAILED, propagate);
        }
    }
}

I modified it a bit in order to use a List<Handle> instead of an Handle, but I still have the same issue and no BATCH_REQ flag.

final List<Handle> activePreviousHandles = ctx.findPreviousHandle().stream().filter(x -> x.isActive()).collect(Collectors.toList());
if (!activePreviousHandles.isEmpty())
{
    try {
        SingleRequestReplyDispatch.this.ommConsumer.reissueClient(activePreviousHandles, ommItemIntSpec);
    } catch (Exception propagate) {
        ctx.notifyRequestFailed(RequestFailure.REISSUE_FAILED, propagate);
    }                        
}

We use the same logic for all message, simple request or reissue.

// Always force the BATCH_REQ flag
setIndicationMask(RequestIndicationMask.BATCH_REQ);
...
ommMsg.setIndicationFlags(indicationFlag.convertToIntMask() | indicationMask.convertToIntMask());
ommMsg.setPriority(getPriorityClass().convertToByteMask(), getPriorityCount());
if (!indicationMask.isFlagSet(RequestIndicationMask.BATCH_REQ) && !getMarketPriceRequestAttrib().hasItemName()) {
    throw new GreatRtFeedDomainException("GreatMarketPriceRequest#GreatMarketPriceRequestAttrib", "OMMAttribInfo#Name",
            "REQUIRED Name when not a batch request");
}
final OMMAttribInfo attribInfo = getMarketPriceRequestAttrib().getAttribInfo(ommPool);
ommMsg.setAttribInfo(attribInfo);
...
final OMMEncoder encoder = ommPool.acquireEncoder();
try {
    encoder.initialize(OMMTypes.MSG, totalSize);
    encoder.encodeMsgInit(ommMsg, OMMTypes.NO_DATA, OMMTypes.ELEMENT_LIST);
    encoder.encodeElementListInit(OMMElementList.HAS_STANDARD_DATA, (short) 0, (short) 0);
    encoder.encodeElementEntryInit(RDMUser.Feature.ItemList, OMMTypes.ARRAY);
    encoder.encodeArrayInit(OMMTypes.ASCII_STRING, 0);
    for (int i = from; i < to; ++i) {
        encoder.encodeArrayEntryInit();
        encoder.encodeString(itemNames[i], OMMTypes.ASCII_STRING);
    }
    encoder.encodeAggregateComplete(); // completes the array
    encoder.encodeAggregateComplete(); // completes the element list
    final OMMMsg finalMsg = (OMMMsg) encoder.acquireEncodedObject();
    return finalMsg;
} finally {
    ommPool.releaseEncoder(encoder);
}

We get the handle directly from com.reuters.rfa.common.Event.getHandle() that we put in a cache and we get it during the ctx.findPreviousHandle() operation.

Concerning the OMMItemIntSpec object we just do a new OMMItemIntSpec() and a setMsg(message) on it, the message was created with the code that I shared above.

Regards,

Benjamin

Bug Fixed by removing payload when Reissue.

Thank you for your help,

Cedric