Decoded login message has wrong OMMMsg.MsgType

Anton.Crona

I'm using a RFA Java client to log into a Interactive provider.

On the login request message I send, I explicitly set the message type to REQUEST (4) :

msg.setMsgType(OMMMsg.MsgType.REQUEST);

However, when the message arrives at the provider, after the message is decoded back into OMM from RWF, the message type has switched to OMMMsg.MsgType.STREAMING_REQ (1)

Has anyone any idea on how to trouble shoot this?

zoya faberov

Hello @Anton.Crona,

As the RFA example StarterConsumer is not exhibiting the issue, the two approaches I see are: comparing the custom consumer and with the Starter Consumer to see how it differs so that it may result in this issue, the other approach is starting with StarterConsumer working code and adding your cusom fucntionality to it, till it does what you require.

Please let us know how this works for you.

pimchaya.wongrukun01

Hello @Anton.Crona

Have you tried with the latest RFA version(8.1.0.E2) yet?

I have tested RFA version 8.1.0.E2 by running StarterProvider_Interactive and StarterConsumer shipped with RFA package. StarterConsumer set setMsgType(OMMMsg.MsgType.REQUEST) and StarterProvider_Interactive received OMMMsg.MsgType.REQUEST(4) which is the same MsgType as StarterConsumer set.

You can check Msg Type sent by the Consumer and received by the Interactive Provider by enabling RFA trace log. To enable the trace log file, please set ipcTraceFlags = 7, traceMsgTypes =ALL, traceMsgDomains=NORMAL, mountTrace=true and specify logFileName parameter of the RSSL and RSSL_Prov connection node. Then start the applications, the default location of each log file is in the application run directory.

The example RFA trace log of login request message sent by StarterConsumer:

The example RFA trace log of login request message received by StarterProvider_Interactive:

You will see that MsgType of the login request is still MsgType.REQUEST(4). I also modified StarterProvider_Interactive source code to print MsgType of each login request and it showed 4(MsgType.REQUEST).

If the problem still occurs with RFA version 8.1.0.E2, you should review your application source code comparing to StarterConsumer.

Hope this help.

Jirapongse

@Anton.Crona

I assume that the RFA version used by the interactive provider is older than RFA Java 7.2.1.L1. Refer to the RFA Java reference guide, OMMMsg.MsgType.STREAMING_REQ has been deprecated in RFA Java 7.2.1 and it uses OMMMsg.MsgType.REQUEST instead.

Therefore, the RFA version used by the consumer may be newer than the RFA version used by the interactive provider.

Please verify the RFA version used by the interactive provider.

Anton.Crona

Hi.

I am using RFA version(8.1.0.E2). Both ADH and Interactive provider are on 8.1.0.E2.

This is not a question of the client sending the wrong message. The client is indeed sending a REQUEST(4), this has been verified. The problem here is that the message, for some reason is not correctly decoded when it arrives from the RFA code into the callback.

I have run the examples provided in the RFA package. These examples does not suffer from this problem. The login message, when I run the example, holds REQUEST (4).

I have turned on the tracing as adviced, the tracing shows that the incoming message is indeed REQUEST (4). However, when the public void processEvent(Event event) method is called in the receiving client session. The message type is STREAMING_REQ(1).

I.e.

msg.getMsgType() == OMMMsg.MsgType.STREAMING_REQ

So for some reason, the bit has switched from what is written in the trace, to what the call back receiver is getting.

Since the code for the message encoding / decoding is not available. I cannot isolate what is causing this.

All I see is that the message received on the callback is wrong.