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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Ok, I see why the reasoning for the second interface.  Since refresh support 
is being added to quickfix that can probably be consolidated into a single 
interface for future versions.

I don't really see why the no-op results in incorrect runtime behavior.  My 
view of the method is that it sets the state of the session to the persisted 
state.  In the case of the memory store, it is persisted into memory.  I 
could copy the state in memory from one place to another, it just happens 
that a no-op is a more efficient implementation.  I don't really see it any 
different than if I refreshed against a database with store that is already 
in sync with the database.  Nothing has changed (state wise), so it 
essentially acted like a no-op memory store refresh, but the end result is 
correct since the state of the session is correct.

As to the name, I had always seen the settings as sitting in the [SESSION] 
section.  So I never thought that the settings required additional 
clarification any more then methods on the Session class are prefixed with 
Session.  Pretty much every setting is like this.  StartTime, EndTime, 
ConnectionType, ReconnectInterval etc. etc.  None of these settings 
explicitly state they are session settings, but that is implied by the name 
of the section.

--oren

----- Original Message ----- 
From: "Steve Bate" <sb...@sm...>
Cc: <qui...@li...>; 
<qui...@li...>
Sent: Monday, May 29, 2006 12:50 AM
Subject: RE: [Quickfix-developers] QuickFix FailOver/Farming Support.

QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi Oren,

I derived an interface because I couldn't add methods to existing
JNI interfaces without breaking API compatibility. If anybody had
implemented custom message stores those would be broken when they
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
logon time and the message store they are using doesn't support
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
behavior.

For the option name, I prefer more descriptive names.
RefreshOnLogon is a bit vague (refresh what?) but
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...]
> Sent: Sunday, May 28, 2006 11:32 AM
> To: Steve Bate
> Cc: qui...@li...;
> qui...@li...
> Subject: Re: [Quickfix-developers] QuickFix FailOver/Farming Support.
>
> Steve,
>
> Can you explain the rational for implementing this as another
> interface.  It seems you are using reflection to determine if the
> interface implements RefreshableMessageStore or MessageStore.  If it
> is, it does a downcast to RefreshableMessageStore and calls refresh,
> if not it says that refresh is not supported.  Why wouldn't refresh
> be on the MessageStore interface, and if the store doesn't require
> any action to refresh (in this case since the state is in memory and
> 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
> > interface that provides the methods for refreshing the store and
> > marks which stores can be refreshed (MemoryStore can't, for
> > example). The Session can be configured to refresh it's state at
> > logon if a refreshable store is being used (see the
> > "RefreshMessageStoreAtLogon" configuration option). This
> might give
> > you some ideas how to modify the C++ code in a similar way.
> >
> > Regards,
> >
> > Steve
> >
> > From: qui...@li...
> > [mailto:qui...@li...] On Behalf
> > 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,
> >
> > From looking at the source looks like "revert" would
> propbably just
> > call "populateCache()" on the message store's.  Not sure where
> > abouts in logon is the safest place to call this.
> >
> > What is the possibility of this being available in a future
> > release?  I'd prefer not to change the code for my system as
> > creates issues with Fix Fixengine releases.
> >
> > Also is there a way I can simulate this behaviour without changing
> > the "FixEngineCode".  Is it possible to make the session
> "recreate"
> > on the logon event, which would also have the same effect?
>  In the
> > worst case I could expose the "PopulateCache" as a public method,
> > and call this on the "OnLogon", however I suspect this is too late
> > as you will have already started using the sequence number.   Any
> > 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
> > MessageStore interface which would revert to the persisted state.
> > This could then be called by a session when receiving a logon.  It
> > actually might be a useful thing to do in all logon
> situations.  It
> > also gives us the ability to modify sequence numbers and such
> > 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
> > backend, running fine.  I would like to be-able to provider
> > "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
> > message store.
> >
> > If I "pull the plug" on A, clients are disconnected and connect to
> > "secondary", which in theory when they connect we pick up the
> > session from where it left off.
> >
> > The problem is the "Secondary" quick fix engine does not know to
> > "re-read" the clients "Sessions" when they connect, it
> appears that
> > this is performed when the "Fix Engine Starts Up" probably during
> > the create session.
> >
> > My only solution at the moment would be to have the
> "Secondary" fix
> > 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
> > connect and force a "re-read" of session information from the
> > message store  cleanly with no side effects?   I'd prefer not to
> > change the Fix engine source code.
> >
> > Any info would be appreciated.
> >
> > Regards
> >
> > Phil.
> > Copy addresses and emails from any email account to Yahoo! Mail -
> > quick, easy and free. Do it now...
> >
> >
> > Try the all-new Yahoo! Mail . "The New Version is radically easier
> > to use" - The Wall Street Journal
> >
>
>

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=k&kid7521&bid$8729&dat1642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers