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

[Steve B. <sb...@sm...>]

Hi Oren,

I derived an interface because I couldn't add methods to existing=20
JNI interfaces without breaking API compatibility. If anybody had=20
implemented custom message stores those would be broken when they=20
migrated to QuickFIX/J.

I prefer providing user feedback instead of implementing
the operation as a no-op if the user has requested a refresh at=20
logon time and the message store they are using doesn't support=20
refresh. If we changed the MessageStore interface we could add
a predicate isRefreshable(), but I'm still a little uncomfortable
with a no-op operation when it results in incorrect runtime=20
behavior.

For the option name, I prefer more descriptive names.=20
RefreshOnLogon is a bit vague (refresh what?) but=20
RefreshSessionOnLogon would be fine and less implementation
oriented. However, I don't have a big issue with the
shorter name.

Steve

> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]=20
> Sent: Sunday, May 28, 2006 11:32 AM
> To: Steve Bate
> Cc: qui...@li...;=20
> qui...@li...
> Subject: Re: [Quickfix-developers] QuickFix FailOver/Farming Support.
>=20
> Steve,
>=20
> 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?
>=20
> --oren
>=20
> On May 28, 2006, at 2:09 AM, Steve Bate wrote:
>=20
> > 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=20
> 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=20
> FailOver/Farming Support.
> >
> > Oren,
> >
> > From looking at the source looks like "revert" would=20
> 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=20
> "recreate" =20
> > on the logon event, which would also have the same effect? =20
>  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=20
> 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=20
> 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=20
> "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" - The Wall Street Journal
> >
>=20
>=20