Any suggestions for using TREP for a request/response application where the requests are too complex to encapsulate in a RIC? IE the request should carry arbitrarily large structured payload.
The idea is to build a publisher that can be deployed and operated like any other TREP publisher to handle parameterized analytical queries. Mostly snapshot but streaming may be used for some purposes.
Idea 1: Can an OMM REQUEST message field msgKey.name contain arbitrary content? Is there a size limit?
Idea 2: Can an OMM REQUEST message field “Payload” be used for arbitrary purposes? I see in documentation how to use this for specific purposes such as Batch Request under various RDMs. But with existing domains or if you build your own can you load up the Payload of an RSSL_MC_REQUEST with whatever you want? Any examples?
Idea 3: Are private streams with Generic messages a good way to do this? If used, can the ADH’s load balancing features be used to dole out private stream requests to several identical publishers? Does this effectively provide load balancing? Does it do failover too, i.e. if a consumer is connected to a private stream provider that fails will ADH reconnect it to a different one? This would allow the consumers and infrastructure/operations to be handled in familiar ways.
Any different suggestions?
MsgKey.name type is an RsslBuffer type that allows for a name of up to 255 bytes. Its content should comply with the rule associated with the MsgKey.nameType member, such as RIC.
Another option is using MsgKey.attribContainerType and MsgKey.encAttrib. MsgKey.attribContainerType identifies the content type of the MsgKey.encAttrib information.
This attribute typically allows for further uniqueness in the identification of a stream. It is also an RSSLBuffer that can represent up to 32,767 bytes of information.
Jirapongse's answer is correct. By setting this payload in the encAttrib, it guarantees stream uniqueness.
You can put this in the request payload as well. However, when that happens if two users request the stream with the same msgKey but different payloads, they will get merged into one. Only way to prevent that is to use private streams.
I prefer recommending use of the encAttrib to solve this problem.
You could use GenericMsg too but that is an extra level of complexity that is best to be avoided if you can convey all the necessary information in the request. A GenericMsg should only be used when establishing a private stream to the service. Private streams are really only used for either targeted posting of data OR the need of line of sight from consumer to publisher application whereby source app must then do the fanout and TREP is just a conduit.