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

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

Steve,

Can you explain the rational for implementing this as another =20
interface.  It seems you are using reflection to determine if the =20
interface implements RefreshableMessageStore or MessageStore.  If it =20
is, it does a downcast to RefreshableMessageStore and calls refresh, =20
if not it says that refresh is not supported.  Why wouldn't refresh =20
be on the MessageStore interface, and if the store doesn't require =20
any action to refresh (in this case since the state is in memory and =20
is therefore always up to date), implement it as a no-op?

--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
>