Re: [Quickfixj-users] Message Resliency On FIX Initiator side

[Colin D. <co...@ma...>]

Rahul,


Even with the session disconnected you can still send messages. They 
will be queued until the session is available again.


As for testing, I would just mock up an Acceptor with QFJ that just 
kills the connection after x number of messages. You can have it wait 
30s and restart itself. This will test your initiator's ability to not 
drop any messages in this scenario. Whether the acceptor does or not is 
not your responsibility.


- Colin


On 10/15/2018 06:16 AM, Rahul Gaur wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Hi Chris,
>
> Thanks for the information.
>
> Comments inline
>
> *[Chris]*what do you mean by "how it can be tested"? Pull the network 
> cable?? ;) Alternatively you could ask the other side to kill their 
> Acceptor.
> *[Rahul]*As soon as I pull the network cable or kill the Acceptor(Our 
> own FIX simulator as external Acceptor is not in our control), the FIX 
> session immediately detects that the TCP/IP connection is broken and 
> marks itself as disconnected. This makes simulating this scenario 
> nearly impossible(at least for me:) ). That's why I asked if someone 
> has ever tested this on the Initiator side and If someone can suggest 
> testing this in a predictable manner. Or, if any quickfixj expert can 
> confirm that using *FileStoreFactory *on initiator side will ensure 
> the expectation as you suggested => 'The expectation would be that the 
> remote side gets all missing messages by re-requesting them via 
> ResendRequest on the next Logon'.
>
> Thanks
> Rahul
> ------------------------------------------------------------------------
> *From:* Christoph John <chr...@ma...>
> *Sent:* Monday, October 15, 2018 5:25 PM
> *To:* qui...@li...; Rahul Gaur
> *Subject:* Re: [Quickfixj-users] Message Resliency On FIX Initiator side
> Hi,
>
> what do you mean by "how it can be tested"? Pull the network cable?? 
> ;) Alternatively you could ask the other side to kill their Acceptor.
> The expectation would be that the remote side gets all missing 
> messages by re-requesting them via ResendRequest on the next Logon.
>
> Cheers,
> Chris.
>
> On 15/10/18 13:48, Rahul Gaur wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>
>> Hi All,
>>
>> We have a typical FIX setup in which we have one Initiator connecting 
>> to an external Acceptor and are exchanging FIX messages with each 
>> other. On *Initiator *side we are using *FileStoreFactory *as 
>> MessageFactory and caching 10000 outgoing messages. We need to test a 
>> resiliency scenario wherein the Acceptor goes down while some of the 
>> messages from Initiator are still in-flight. Can you suggest how it 
>> can be tested and also what is the expectation in the above scenario.
>>
>> The quickfixj version on initiator side is *1.6.3*
>>
>> Thanks
>> Rahul
>>
>>
>>
>>
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li... 
>> <mailto:Qui...@li...>
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> -- 
> Christoph John
> Software Engineering
> T +49 241 557080-28
> chr...@ma... <mailto:chr...@ma...>
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germany
> www.macd.com <http://www.macd.com>
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users