{{Quickfixn}} MemoryMessageStore only holds outgoing messages

Wed Jun 26 07:57:11 PDT 2019

Hello Grant

Thanks for replying and clarifying. I will get in contact with the counterparty regarding the multipart market data or come up with my own solution.

One more thing. If user code is not intended to work with the message store please mark it as internal or private, also if user code shouldn’t subclass from SocketInitiator please mark it as sealed and reduce the API surface.

Thanks again and best regards, Matthias

Von: Quickfixn [mailto:quickfixn-bounces at lists.quickfixn.com] Im Auftrag von Grant Birchmeier
Gesendet: Mittwoch, 26. Juni 2019 16:36
An: Mailing list for QuickFIX/n <quickfixn at lists.quickfixn.com>
Betreff: Re: {{Quickfixn}} MemoryMessageStore only holds outgoing messages

Ok, let's start with the most important point:  The message store is for internal use only.  User code is not intended to read from, write to, or interact with the message store at any time.

I don't believe the docs ever indicate or instruct that developers ever do anything with the message store (please correct me if I'm wrong), but every so often someone gets it in their head to do that.  Don't do it.  The store is for the engine to remember its internal state and respond to session-level resend requests.  It's not meant for application-code interaction.

Next:  Why are you subclassing from SocketInitiator?  I guarantee that there are no official docs or examples instructing you to do that.

Have you looked at the examples?  I really recommend looking at the examples.
https://github.com/connamara/quickfixn/tree/master/Examples

Regarding the MarketDataRefresh data flow: I think you are looking for a feature that QF does not provide.  FIX just specifies a message-transmission platform and a set of suggested message definitions.  How those messages are used, abused, or redefined strongly depends on the counterparty.  Their docs should supercede anything you know or think you know about how things should work.

If the MarketData is multipart, it is on you to create the storage structures to hold that data and compute it when the reception is complete. I myself have done that before.  In my case, the counterparty's message definition contained fields telling how many messages should be expected and an index field to identify each message's place in the sequence.  I had to code my own logic to recognize when a data set was complete, and I think I had a worker thread monitoring the storage to identify when a data set was incomplete after a timeout period.

-Grant

On Wed, Jun 26, 2019 at 2:15 AM Matthias Güntert <matthias.guentert at raiffeisen.ch<mailto:matthias.guentert at raiffeisen.ch>> wrote:
Hello

I am building a C# solution based on QuickFix/ 1.8.0.

Below is the basic structure of my application. I see replies coming in from our counterparty, but unfortunately they don’t show up in the message store type, which in this case is a MemoryStore. However I do see all outgoing messages, like logon, heartbeat and the market data request messages.

The challenge behind this issue is that one market data request results in many replies (of type: MarketDataSnapshotFullRefresh) on which I have to do some calculations upon.

Following a couple of questions:

1.    Why is quickfix behaving this way? Do I have to explicitly add the replies to the store?

2.    What is the intended way to synchronize / control the request/reply dataflow?

3.    How do I know, at which point all requested replies have been received?

4.    What is the best way to await a logon to complete?

Thanks and Best regards,
Matthias Güntert

public class FixMessageHandler : MessageCracker, IApplication
{
       private Session _session;

       [...]

       public void OnCreate(SessionID sessionID)
       {
             this._session = Session.LookupSession(sessionID);
       }

       public void FromApp(Message message, SessionID sessionID)
       {
             try
             {
                    Crack(message, sessionID);
             }
             catch (UnsupportedMessageType ex)
             {
                    [...]
             }
       }

       public void OnMessage(MarketDataSnapshotFullRefresh message, SessionID sessionId)
{
       this._logger.Info(“MarketDataSnapshotFullRefresh received”);
}

       […]
}

public class FixClient : SocketInitiator
{
       [...]

       public void SendRequest(MarketDataRequest request)
       {
             Session.SendToTarget(request, this._sessionId);
       }

       public void ReadReplies()
       {
             var session = Session.LookupSession(this._sessionId);
             var messages = List<string>();
             session.MessageStore.Get(0,100, messages)

             [...]
       }
}

*****************************************************
This e-mail may contain confidential material. It is intended only for the person or entity which it is addressed to. In case you should not be supposed to get this e-mail we ask you to delete it without taking notice of its content. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of The Swiss Raiffeisen Group. Therefore this e-mail does not represent a binding agreement nor an offer to deal. E-Mail transmission can be insecure and can contain errors. Information could be intercepted, corrupted, lost, destroyed, incomplete or may contain viruses. Neither The Swiss Raiffeisen Group nor the sender can accept any liability for any kind of damage as the result of viruses or transmission errors.
*****************************************************
_______________________________________________
Quickfixn mailing list
Quickfixn at lists.quickfixn.com<mailto:Quickfixn at lists.quickfixn.com>
http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com

--
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.
http://connamara.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20190626/db016562/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5096 bytes
Desc: not available
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20190626/db016562/attachment-0002.bin>