{{Quickfixn}} We sent a New Order Single request which was approximately 12K in size and it was "dropped" by our counter party

[Grant Birchmeier]

This is a new one.

Off the top of my head: You could add a check inside ToApp() which could
examine the length of each outgoing message.  If the message is too long,
you could throw a DoNotSend exception and the engine will not send it.
That would be the natural place to send or log an alert via your own
mechanism so that you can learn of it and decide what to do.

-Grant

On Mon, Jul 13, 2015 at 10:06 AM, Mark Cooke <mc.developer at verizon.net>
wrote:

> We constructed this Message which, in this case had 252 allocations in the
> order, and the Message ended up having a Body Length of 11730. We sent the
> message but did not receive an Acknowledgment or a Reject. It was if it
> just fell off the wire somewhere.
>
> We contacted our Counter Party about this and their response was that this
> was larger than their FIX Engine's internal buffer size of 10K for reading
> messages. Unfortunately (for us) at this point, their behavior appears to
> be that they just drop the message without any sort of response back to the
> sender.
>
> They will be looking into what to do to correct this but this will take
> some time on their end.
>
> We are using FIX 4.4 (via QuickFix/N on our end).
> Is this a common issue for others? Knowing their limit, is there a way we
> might break this request up into multiple messages, but still have it
> behave as expected? (Of course, that would take development and QC efforts
> on our part).
>
> Is there any configuration setting I might use on my end that would at
> least allow me to fail to even attempt to send a message over a certain
> size on our end? A failure would be better than a mysterious non-response,
> so that we can give our end user an indication that this is not going to
> happen?
>
> I am asking about configuration so that we might have an immediate
> solution which does not require code changes (though would still require
> testing, of course)
>
> _______________________________________________
> 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/20150713/19fdce90/attachment-0001.htm>