{{Quickfixn}} MemoryMessageStore only holds outgoing messages
Grant Birchmeier
gbirchmeier at connamara.com
Wed Jun 26 08:09:26 PDT 2019
There are plans in motion to reduce the public API.
But at the same time, the docs and examples are pretty clear on what a
basic QF application should look like. It sometimes astounds me how some
developers can get so far off the mark, as if they've accepted a personal
challenge to avoid reading the instructions that are *right. there.*
On Wed, Jun 26, 2019 at 9:57 AM Matthias Güntert <
matthias.guentert at raiffeisen.ch> wrote:
> 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> 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
> 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
> _______________________________________________
> Quickfixn mailing list
> 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/a722fa52/attachment.htm>
More information about the Quickfixn
mailing list