[Quickfixj-users] Re: [Quickfix-developers] QuickFix FailOver/Farming Support.

[Oren M. <or...@qu...>]

Hi Steve,

One more comment.  I was thinking that simply RefreshOnLogon would be =20=

a better name for the setting.  It is more consistent with the reset =20
configuration settings already in place "ResetOnLogon, =20
ResetOnLogout...".  I don't think that it is really necessary to put =20
MessageStore in there, as from the application users point of view it =20=

is the session state in the end that is being refreshed.  So I think =20
this creates more consistency as well as being easier to remember.

--oren

On May 28, 2006, at 2:09 AM, Steve Bate wrote:

> Hi Phil,
>
> This feature is in QuickFIX/J. There is a RefreshableMessageStore =20
> interface that provides the methods for refreshing the store and =20
> marks which stores can be refreshed (MemoryStore can't, for =20
> example). The Session can be configured to refresh it's state at =20
> logon if a refreshable store is being used (see the =20
> "RefreshMessageStoreAtLogon" configuration option). This might give =20=

> you some ideas how to modify the C++ code in a similar way.
>
> Regards,
>
> Steve
>
> From: qui...@li... =20
> [mailto:qui...@li...] On Behalf =20
> Of pc redev
> Sent: Friday, May 26, 2006 6:07 PM
> To: Oren Miller; qui...@li...
> Subject: Re: [Quickfix-developers] QuickFix FailOver/Farming Support.
>
> Oren,
>
> =46rom looking at the source looks like "revert" would propbably just =20=

> call "populateCache()" on the message store's.  Not sure where =20
> abouts in logon is the safest place to call this.
>
> What is the possibility of this being available in a future =20
> release?  I'd prefer not to change the code for my system as =20
> creates issues with Fix Fixengine releases.
>
> Also is there a way I can simulate this behaviour without changing =20
> the "FixEngineCode".  Is it possible to make the session "recreate" =20=

> on the logon event, which would also have the same effect?   In the =20=

> worst case I could expose the "PopulateCache" as a public method, =20
> and call this on the "OnLogon", however I suspect this is too late =20
> as you will have already started using the sequence number.   Any =20
> ideas on workaround would be appreciated.
>
> Thanks
> Phil.
>
> Oren Miller <or...@qu...> wrote:
> To do this we would need some sort of revert method on the =20
> MessageStore interface which would revert to the persisted state.  =20
> This could then be called by a session when receiving a logon.  It =20
> actually might be a useful thing to do in all logon situations.  It =20=

> also gives us the ability to modify sequence numbers and such =20
> without having to restart the engine.
>
> --oren
> ----- Original Message -----
> From: pc redev
> To: qui...@li...
> Sent: Thursday, May 25, 2006 2:08 PM
> Subject: [Quickfix-developers] QuickFix FailOver/Farming Support.
>
> Hi,
>
> I have a QuickFixEngine connected to a "Clustered" MS SQL Server =20
> backend, running fine.  I would like to be-able to provider =20
> "FailOver/Farming" support like:
>
> Primary Machine:  Fix Engine Running Serving Active Clients
> Secondary Machine: Fix Engine Running in No client connections.
>
> Both Fix Engines are connected to the clustered SQL Server for the =20
> message store.
>
> If I "pull the plug" on A, clients are disconnected and connect to =20
> "secondary", which in theory when they connect we pick up the =20
> session from where it left off.
>
> The problem is the "Secondary" quick fix engine does not know to =20
> "re-read" the clients "Sessions" when they connect, it appears that =20=

> this is performed when the "Fix Engine Starts Up" probably during =20
> the create session.
>
> My only solution at the moment would be to have the "Secondary" fix =20=

> engine start on failover, i.e cold standby, which is not ideal.
>
> In the Fix Engine logic is it possible to "detect" a client socket =20
> connect and force a "re-read" of session information from the =20
> message store  cleanly with no side effects?   I'd prefer not to =20
> change the Fix engine source code.
>
> Any info would be appreciated.
>
> Regards
>
> Phil.
> Copy addresses and emails from any email account to Yahoo! Mail - =20
> quick, easy and free. Do it now...
>
>
> Try the all-new Yahoo! Mail . "The New Version is radically easier =20
> to use" =96 The Wall Street Journal
>