Re: [Quickfix-developers] Configuration Failover Settings

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

Oh, then why are sequence numbers a concern?  If you are always 
resetting to 1, then you should never have a situation where sequence 
numbers are too high.  Am I understanding this correctly?

--oren

On Jun 9, 2004, at 2:13 PM, Jon Dahl wrote:

> Understood. However we are setting ResetOnDisconnect and ResetOnLogout 
> to
> 1 so I would assume session state is not that big of a deal then. 
> Unless
> of course I am reading the config documentation incorrectly.
>
> jd
>
>> Well you need to determine what it is exactly you are trying to make
>> redundant.  If you are trying to make the FIX session redundant, than
>> you should have the same compids while making sure that only one 
>> server
>> is active at any given time.  These processes should share the same
>> source for the state of the session.  This way no matter where they
>> connect to, the sequence numbers will be the same.  In this case flat
>> file storage probably won't do, in which case you would likely want to
>> use a database.  For extra reliability you would also want to make the
>> database redundant.
>>
>> Now if you are simply trying to provide redundant lines, then you
>> should use different compids.  In this case you are not making the
>> session redundant, but you are making sure that they always have a 
>> path
>> into the system.  The upside is that these lines are always on and are
>> immediately available to accept traffic.  In fact they can accept
>> traffic simultaneously (distributing the load), and the client can
>> reroute excess traffic to the other lines if one goes down.  The
>> downside is that if a session goes down, lost messages won't be
>> retrieved until it can be brought back up.
>>
>> You can also combine these by having redundant paths into the system
>> which have redundant sessions.  It all depends on what you are trying
>> to accomplish.  But the thing that should remain solid is that if I am
>> connecting somewhere with the same compids, I should expect the
>> sequence numbers to carry over.  If not, I can only assume something 
>> is
>> catastrophically wrong and manual intervention is required.
>>
>> --oren
>>
>> On Jun 9, 2004, at 12:51 PM, Jon Dahl wrote:
>>
>>> I understand about having the same SenderCompID's. SenderLocationID
>>> can be
>>> used instead of the SenderCompID to indentify the source of the
>>> message.
>>>
>>> But in the case of a failover, won't sequence numbers be an issue? If
>>> the failover server sequence numbers for a client were higher than
>>> what
>>> the client was at, wouldn't there be a possiblity of a resend or
>>> locking
>>> the client out until the sequence numbers caught up?
>>>
>>> jd
>>>
>>>> John,
>>>>
>>>> When you have multiple connection points that share the same comp
>>>> id's,
>>>> cycling through the connections is a necessity because you can't 
>>>> keep
>>>> the same session alive simultaneously on multiple hosts/ports.  But
>>>> if you failover sessions with unique compids and unique sets of
>>>> sequence numbers, why would you not just keep these connections up 
>>>> at
>>>> all  times?
>>>>
>>>> --oren
>>>>
>>>> On Jun 9, 2004, at 10:46 AM, Jon Dahl wrote:
>>>>
>>>>> QuickFIX Documentation:
>>>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>>>> QuickFIX FAQ:
>>>>> http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
>>>>>
>>>>> I have been asked to research QuickFIX's scalability/failover
>>>>> capabilities
>>>>> by our Ops center and have come upon an issue. I think I found a
>>>>> situation
>>>>> where the clients won't be able to connect to an alternate gateway
>>>>> in case
>>>>> of a failure.
>>>>>
>>>>> Let's say a client has two hosts(gateways) to connect to. Each one
>>>>> has
>>>>>  a
>>>>> separate SenderCompID. If the client detects a failure and tries to
>>>>> connect to the secondary host, it will fail to connect because its
>>>>> TargetCompID is for the primary host and not the secondary one.
>>>>>
>>>>> I was wondering if there was a way to have the [SESSION] settings
>>>>> have
>>>>> alternate TargetCompID's to go a long with SocketConnectPort[n] and
>>>>> SocketConnectHost[n]?
>>>>>
>>>>> JD
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.Net email is sponsored by: GNOME Foundation
>>>>> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
>>>>> GNOME Users and Developers European Conference, 28-30th June in
>>>>> Norway
>>>>> http://2004/guadec.org
>>>>> _______________________________________________
>>>>> Quickfix-developers mailing list
>>>>> Qui...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>>>
>>> --
>>> Jon Dahl
>>> jd...@wi...
>
>
> -- 
> Jon Dahl
> jd...@wi...
>
>
>