0

how do you catch lower level exceptions from quickfix which appear in the messages log but aren't caught by fromAdmin

rupweb
  • 3,052
  • 1
  • 30
  • 57

2 Answers2

1

You don't. This is by design.

If the message is rejected by the transport layer, it's because there is something fundamentally wrong with it. Maybe it's garbled and can't be decoded, maybe the sequence numbers are wrong, or maybe something else crazy happened.

Whatever the case, your application logic can not fix it, and should not attempt to. If the problem is in your app, it'll be something that requires code-fixes.

"But I want to log the error!"

You don't need to log it at the application layer. Choose a log monitor tool and set it to watch your message log for 35=3.

Grant Birchmeier
  • 17,809
  • 11
  • 63
  • 98
  • what do you recommend for a log monitor tool? – rupweb Jun 23 '15 at 11:25
  • I would say that the issue here is knowing there's a problem, not fixing it. I'd like to be able to monitor everything from the Application layer FromApp and FromAdmin. – rupweb Jun 23 '15 at 12:17
  • To be honest, I haven't had to install a log monitor myself, though our clients' have. Usually when we have a reject, we notice it quickly by other means. I wish I could offer you a good recommendation, but I'm sure Google can hook you up. – Grant Birchmeier Jun 23 '15 at 15:24
  • In reply to original question, it may be the provider is using the wrong message type for rejections, due to platform changes, etc... I'd really like to catch AG in the Application somehow. Guess I have to rebuild quickFIX ?! – rupweb Jun 23 '15 at 17:51
  • 1
    That's the wrong approach. You should set up a FileLogFactory, which will record all messages that are sent and received by your application. You can see exactly what your counterparty is sending you and what you are sending in response. I swear to you, the message log is your most valuable resource for diagnosing problems. – Grant Birchmeier Jun 24 '15 at 18:49
  • Grant, you shouldn't swear, lol ! This was a data dictionary issue between provider, engine and client. Got to get them all in sync. I comment now because it just happened with 35=j as well. – rupweb Aug 25 '15 at 11:55
0

The answer is the 35=AG message is getting to fromAdmin() but the data dictionary was inconsistent with the provider data dictionary, which generated a further 35=3 reject message, and prevented the processing of the 35=AG. Once the data dictionary is consistent removing the 35=3 reject message then you can handle the 35=AG message using fromAdmin() if you want to.

I think that's good...

rupweb
  • 3,052
  • 1
  • 30
  • 57
  • `you can handle the 35=AG message using fromAdmin()` - ugh, that would be terrible. The correct action is to fix your DataDictionary to match what your provider expects to send/receive. – Grant Birchmeier Jul 20 '15 at 13:22
  • (Also, this "answer" doesn't have much to do with the question that you actually asked.) – Grant Birchmeier Jul 20 '15 at 13:25
  • the problem is, it's not my error! It's from a provider that my initiator passes to my acceptor which is passed to my client's initiator... – rupweb Jul 21 '15 at 14:03
  • What's not your error? If your DD doesn't match what your counterparty specifies, then it is your error. – Grant Birchmeier Jul 21 '15 at 14:17
  • hmm, exactly, but it's the client's initiator DD that doesn't match my provider DD... I just pass messages thru... – rupweb Jul 23 '15 at 14:28