I get the follow message for RIC(AMS.S) - StatusText : Request Rejected: Request message payload not supported on non-private streams. I've requested the data via a bulk request. I'm pretty sure I used to get data for this when I was requesting just one instrument at a time. I'm working with 2,000 RICs now and need to bulk for performance reasons.
5
●3 ●1 ●9
Updating to the appropriate RFA dll in 8.1.0.L1 resolved my issue. If anyone else runs into the same issue and haven't yet updated the dll, check if the number of items your requesting is one more than a multiple of 10. The API auto-batches in groups of 10. The remaining one item is treated as a batch and will always fail. The new dll didn't have this bug.
7.6k
●15 ●6 ●9
Based on your description I understand that you are you using RFA C++/.NET with batch request which contains around 2000 items per batch request. And you get the status text when you send batch request to TREP. Is this correct?
-What version of RFA C++ or .NET you are using?
In the old version of RFA(7.6.1.x, 8.0.0 etc) we have known issue relate to number of item per batch request which causing the same status text. But it should fix in the new version (7.6.2.E3 and 8.0.1) and latest version of RFA C++ and .NET(8.1.0.L1) which just release on 29 Jun 2017 should fix the issue as well.
-Can you test your scenario again with RFA 8.1.0.L1?
If the problem persists, can you please provide the following additional information?
- List of items you test the issue. Or How many item per batch reqeust we can use to replicate the issue? Sample Config from StarterConsumer_BatchView would be great.
- TREP version.
- Please turn on RSSL tracing log so that we can review the outgoing and incoming RSSL messages. You can use RFA configuration from the following post to turn on the log Activate full message logs for rssl connections
@moragodkrit
1.) By items, do you mean RICs? I was using 71 RICs and received the error above. Interestingly, I limited the request 70 RICs as was able to capture a valid snapshot for AMS.S . Perhaps the RIC isn't the problem, but instead it's the batch size.
2.) I do not know how to identify my TREP version. My Elektron service was installed from ezd1.2.1.L1 .
3.) I have added the additional config lines provided in your link.
5
●3 ●1 ●9
Hello -
I will soon be batching 2000 RICs. This request only had 71.
AMS.S is the only RIC that received this response.
I have only ever used RFA8. I'll respond with logs after I generate those.
Is there an API support phone number?
32.2k
●40 ●11 ●19
Hello @tradingTech ,
1) Do you receive valid (data?) responses for the first 70 subscribed RICs?
What response if any (status?) do you see for the 71st+ subscription?
2) You are not connecting to TREP directly, you are connecting over the internet, over Elektron Connect, EZD 1.2, so bandwidth may be a limiting factor, worth looking at the RFA trace.
As a temporary, additional investigative measure, consider enabling tracing on EZD, in EZD config, via:
!! Tracing information
*ezd*debugTrace : True
*ezd*dumpIncoming : True
*ezd*dumpOutgoing : True
3) Have you been able to enable tracing and to request again, please attach the RFA log? if you have enabled the tracing on EZD, please share EZD log too?
BTW, over EZD, the open request limit is at 1000, so you will not be able to open 2000 requests simultaneously, but this is not what's stopping you at 70, currently, just may be good to know and plan.
Hi @tradingTech
I saw your logs, it looks like a known issue that has already been fixed.
-------- 8.0.1.L1 -------- [RFACPP-853] - RFA sets the batchFlag but encodes a regular item Request when there is one item in the batch list (related to CaseId: 04132340)
What version of RFA C++ or .NET you are using?
Can you test again with RFA 8.1.0.L1?
