Re: [Quickfixj-users] Capturing application message receive time in quickfixj

[Christoph J. <chr...@ma...>]

Hi Ankit,

I was not suggesting to use LoggingFilter but just to build your own filter and take LoggingFilter as an example. 😊

I did not use AspectJ yet. But your approach with the hash map should work. Just bear in mind that you have to treat the message as a String and need to parse it to find the ID which itself will also cost time.

Cheers
Chris


--
Christoph John
Software Engineering

D +49 241 557080 28
chr...@ma...

 

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

    

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald


> Hey Chris,
> 
> Following up on this - we are now thinking of using LoggingFilter and
> manage a hash map that will store the trade execution ID as key and the
> receive timestamp as its value.
> Will access the same time then during the actual message translation layer
> and do further calculations to get network latencies.
>
> AspectJ load weaver option is still open and we might explore that as well.
>
> Just running by you to see if you could share some expert advice or opine
> on a better way to achieve the same.
>
> Thanks,
> Ankit


On Thu, 4 Apr 2024 at 11:42 PM, Ankit Mehta <ank...@gm...>
wrote:

> Thanks for a reply Chris.
> But I am not sure if this will solve what we were looking for.
> For example, I can think of below implementation of the LoggingFilter -
> Note: We are initiators and use SocketInitiator class for the same.
> As soon as we have initialized the SocketInitiator, it can be followed by
> below piece of code -
>
> DefaultIoFilterChainBuilder builderChain = new DefaultIoFilterChainBuilder();
>
> builderCHain.addFirst("logging", new LoggingFilter());
>
> initiator.setIoFilterChainBuilder(builderChain);
>
>
> But from what I understand - all this will do is just start logging in the
> logs, whenever a message is received.
> What we were looking for instead is to capture that time somewhere in the
> message itself, which can be later utilized for some analysis (which we do
> after doing calculations between tag 52 and this newly added field on the
> message, which at present we do inside the fromApp callback)
>
> Maybe my understanding is wrong and I am missing something from what you
> were proposing. Please correct me if that is the case.
>
> Another alternative to achieve this that we have been thinking about is to
> use AspectJ and then do load weavering to amend the message and add the new
> receive time field inside the EventStrategy class under the onMessage
> method.
> Appreciate your thoughts on this approach or if you can propose a better
> alternative for our requirement.
>
> Regards,
> Ankit