Request Rejected: Request message payload not supported on non-private streams

cedric.nabaa

Hello,

We are using two RFA consumers with the following rfa libs:

<groupId>com.reuters</groupId>

</dependency>

<groupId>com.reuters</groupId>

</dependency>

After the Infrastructure migration to TREP3 this saturday we started receiving this message on our consumers randomly:

DataStatus: CLOSED; Message: Request Rejected: Request message payload not supported on non-private streams.

For a single item one consumer receives a closed state whereas the other consumer recevies an open state.

we checked with our local infra and they told us it is a client side bug and they advised us to migrate our rfa libs

so we tested with this new conf:

<groupId>com.reuters</groupId>

</dependency>

<groupId>com.reuters</groupId>

</dependency>

Notice the difference between the rfa and rfa-rdm-ext lib. Is this a good setup? (we couldnt find the 8.1.0.L1 for rdm). More importantly we still have the issue and migrating only to 8.1.0.L1 did not resolve the issue.

Please advise.

Cedric

Find more posts tagged with

java

trep

rfa

rfa-api

Accepted answers

wasin.w

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

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

All comments

wasin.w

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.

cedric.nabaa

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

moragodkrit.chumsri_1

@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.

cedric.nabaa

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:

this is our conf

wasin.w

Hello @cedric.nabaa

That ".\logs\RSSL_%U.log" is just an example. You need to change the value to match your local machine.

If your machine folder structure is ./great-rt-feed/logs/, then the parameter should be <entry key="logFileName" value="./great-rt-feed/logs/RSSL_%U.log"/>

cedric.nabaa

if the repository is not present would it create it?

I tried with those two configs:

~/great-rt-feed/current/logs/RSSL_%U.log

and

./great-rt-feed/current/logs/RSSL_%U.log

no file is beeing generated.

this is the full path of the projects:

/home/rnedev10/great-rt-feed/current/logs

please advise

cedric.nabaa

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.chumsri_1 ?

cedric.nabaa

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

wasin.w

Hello @cedric.nabaa

Can you share the zipped trace file in this tread (please remove any credential such as username, ip address, etc) from the log file first. The trace file is a txt file so it should be able to reduce size by zipping it.

Based on the given message, the item request stream id 53 received status message. The full trace message will let me check this stream (and other requests) in detail.

cedric.nabaa

the attachment limit is 500 kb but the log file zipped is 240 MB. How do i send it? it wont be practical to send 458 packets of 500 kb.

cedric.nabaa

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

umer.nalla

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.

cedric.nabaa

I have the full logs but i cannot upload more than 500k the full logs are 240 MB. how do you suggest I upload them? for a single item i can give you all the logs that we have. but you have to tell me what item you want to investigate

wasin.w

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.

cedric.nabaa

cnycnhirs3y.txt eureibfix2m.txt

cedric.nabaa

isse0009496367cbbt.txt usdsb3l12y.txt

cedric.nabaa

Here you go

wasin.w

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

wasin.w

@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.

cedric.nabaa

Hello,

We are working on a fix we will update you as soon as we have something.

Thank you

cedric.nabaa

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.

Jirapongse

@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.

benjamin.farcy

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

wasin.w

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?

benjamin.farcy

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

wasin.w

Hello @cedric.nabaa @benjamin.farcy

This issue seems to require more technical investigation from TRDC. Please submit this API query for this issue via Contact Premium Support on this page: https://developers.thomsonreuters.com/thomson-reuters-enterprise-platform/apis-in-this-family

Note: @cedric.nabaa is TRDC named user, so he can submit the query via above link.

wasin.w

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

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

cedric.nabaa

Bug Fixed by removing payload when Reissue.

Thank you for your help,

Cedric

Quick Links

All Forums
Recent Questions

EXPLORE OUR SITES