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

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

Not exactly.  As an optimization the sequence numbers are cached in =20
memory (otherwise each sequence number lookup would require a round-=20
trip to the database).  So with the current implementation you need =20
to start the Acceptor in order to read the state from the database.  =20
So you are required to failover all sessions at once since you must =20
start the new acceptor and probably stop the old one.

The failover implementation described by Steve is now in the QuickFIX =20=

subversion tree and will go out with the next release.

--oren

On May 30, 2006, at 8:07 AM, Sean Kirkpatrick wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Oren / Steve,
>
> Prior to this thread of posts, I had been under the impression that =20=

> when utilizing a database message store a system could be set up =20
> such that you have a backend database server to house the message =20
> store / logs with a layer above containing an array of servers, =20
> each running a quickfix acceptor that is configured to know about =20
> all of the sessions.  A load balancer would then sit in front of =20
> the array of acceptors round-robinning FIX connections to them.  If =20=

> a session were to be logged in to box A for 3 hours, lose =20
> connectivity, and come back in to box C, then because each acceptor =20=

> is working with the same database the session could continue as if =20
> it had reconnected to box A.  Is this not the case?
>
> If not, where does the failover / farming support fall in the list =20
> of to-dos?
>
> Thanks,
> Sean
>
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...]On Behalf Of
> Steve Bate
> Sent: Monday, May 29, 2006 4:19 PM
> Cc: qui...@li...;
> qui...@li...
> Subject: RE: [Quickfix-developers] QuickFix FailOver/Farming Support.
>
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>> 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.
>
> Hi Oren,
>
> Can you explain your view a little further? With a memory
> store, how do you refresh the failed over session with the
> session state that was previously stored in memory in a
> separate process? When you say you could copy the state in
> memory from one place to another are you talking about some
> form of ongoing synchronization (vs. refresh at logon)
> that updates the remote memory store every time the local
> state changes?
>
>> 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.
>
> OK, I understand. I agree about the shorter name. A
> different question... did you envision the configuration
> file eventually having section types other than "Session"
> (and the pseudo-session for defaults)?
>
> Steve
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and =20
> Risk!
> Fully trained technicians. The highest number of Red Hat =20
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=107521&bid$8729&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and =20
> Risk!
> Fully trained technicians. The highest number of Red Hat =20
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=107521&bid$8729&dat=121642=

> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>