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

[Sean K. <sea...@pi...>]

Hi Oren / Steve,

Prior to this thread of posts, I had been under the impression that when =
utilizing a database message store a system could be set up such that =
you have a backend database server to house the message store / logs =
with a layer above containing an array of servers, each running a =
quickfix acceptor that is configured to know about all of the sessions.  =
A load balancer would then sit in front of the array of acceptors =
round-robinning FIX connections to them.  If a session were to be logged =
in to box A for 3 hours, lose connectivity, and come back in to box C, =
then because each acceptor is working with the same database the session =
could continue as if it had reconnected to box A.  Is this not the case?

If not, where does the failover / farming support fall in the list 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/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


> I don't really see why the no-op results in incorrect runtime=20
> behavior.  My view of the method is that it sets the state=20
> of the session to the persisted state.  In the case of the=20
> memory store, it is persisted into memory.  I=20
> could copy the state in memory from one place to another, it=20
> just happens that a no-op is a more efficient implementation. =20
> I don't really see it any different than if I refreshed against=20
> a database with store that is already in sync with the database. =20
> Nothing has changed (state wise), so it essentially acted like=20
> a no-op memory store refresh, but the end result is=20
> 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=20
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=20
> the [SESSION] section.  So I never thought that the settings=20
> required additional clarification any more then methods on=20
> the Session class are prefixed with Session.  Pretty much=20
> every setting is like this.  StartTime, EndTime,=20
> ConnectionType, ReconnectInterval etc. etc.  None of these=20
> settings explicitly state they are session settings, but=20
> that is implied by the name=20
> of the section.

OK, I understand. I agree about the shorter name. A
different question... did you envision the configuration=20
file eventually having section types other than "Session"=20
(and the pseudo-session for defaults)?

Steve
=20


-------------------------------------------------------
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=3Dk&kid=107521&bid$8729&dat=121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers