quickfixj-users — General mailing list for QuickFIX/J topics.

[Quickfixj-users] Log4FIX (Beta Release)

[Brian C. <co...@oc...>]

I am pleased to announce the beta release of Log4FIX. Log4FIX is an  
open source FIX logger/ message viewer, written in Java 5, and based  
on QuickFIX/J. Log4FIX provides a "pretty" view for FIX messages by  
utilizing the QuickFIX data dictionary.

Log4FIX works in two main modes:
- tightly integrated with your QuickFIX/J application (real time  
logging)
- standalone application capable of parsing any file with valid FIX  
messages (replay a session)

Log4FIX is still in beta. However, you should find it useful today.  
You can find out more information at: http:// 
www.opentradingsolutions.org/.

Thanks,
Brian Coyner
Object Computing, Inc.
http://www.ociweb.com/
http://www.opentradingsolutions.org/

[Quickfixj-users] (no subject)

[Clive M. <cl...@va...>]

-- 
Clive Messer <cl...@va...>

[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
>

[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

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

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

> 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

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

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

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

[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

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

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

Hi Steve,

One more comment.  I was thinking that simply RefreshOnLogon would be =20=

a better name for the setting.  It is more consistent with the reset =20
configuration settings already in place "ResetOnLogon, =20
ResetOnLogout...".  I don't think that it is really necessary to put =20
MessageStore in there, as from the application users point of view it =20=

is the session state in the end that is being refreshed.  So I think =20
this creates more consistency as well as being easier to remember.

--oren

On May 28, 2006, at 2:09 AM, Steve Bate wrote:

> 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 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 FailOver/Farming Support.
>
> Oren,
>
> =46rom looking at the source looks like "revert" would 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 "recreate" =20=

> on the logon event, which would also have the same effect?   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 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 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 "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" =96 The Wall Street Journal
>

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

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

Steve,

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?

--oren

On May 28, 2006, at 2:09 AM, Steve Bate wrote:

> 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 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 FailOver/Farming Support.
>
> Oren,
>
> =46rom looking at the source looks like "revert" would 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 "recreate" =20=

> on the logon event, which would also have the same effect?   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 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 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 "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" =96 The Wall Street Journal
>

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

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

Hi Phil,
=20
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.
=20
Regards,
=20
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.
=09
=09
	Oren,
	=20
	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.
	=20
	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.
	=20
	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.
	=20
	Thanks
	Phil.
=09
	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.
		=20
		--oren

			----- Original Message -----=20
			From: pc redev <mailto:pc....@ta...> =20
			To: qui...@li...=20
			Sent: Thursday, May 25, 2006 2:08 PM
			Subject: [Quickfix-developers] QuickFix
FailOver/Farming Support.

			Hi,=20
			=20
			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:
			=20
			Primary Machine:  Fix Engine Running Serving
Active Clients
			Secondary Machine: Fix Engine Running in No
client connections.
			=20
			Both Fix Engines are connected to the clustered
SQL Server for the message store. =20
			=20
			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.
			=20
			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.
			=20
			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.=20
			=20
			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. =20
			=20
			Any info would be appreciated.
			=20
			Regards
			=20
			Phil.
________________________________

			Copy addresses and emails from any email account
to Yahoo! Mail - quick, easy and free. Do it now...
<http://us.rd.yahoo.com/mail/uk/taglines/default/trueswitch/*http://uk.d
ocs.yahoo.com/trueswitch2.html>=20


=09
________________________________

	Try the all-new Yahoo! Mail
<http://us.rd.yahoo.com/mail/uk/taglines/default/nowyoucan/wall_st_2/*ht
tp://us.rd.yahoo.com/evt=3D40565/*http://uk.docs.yahoo.com/nowyoucan.html=
>
. "The New Version is radically easier to use" - The Wall Street Journal

[Quickfixj-users] QFJ: Session EndTime and Logout

[Shepheard, T. \(London\) <Tob...@ml...>]

Sadly not... I've got defaults set explicitly in the config. I tried
bumping up the logout from 3 to 10, but it has no effect on the timing
of the TCP disconnect (its not getting as far as tryign to send any FIX
logout message).=20
=20
As far as I can see its doing something as follows:
=20
Timer triggers in SessionConnector, calls session.next()
checkSessionTime() returns false, calls session.reset() ->
session.disconnect()
disconnect() calls responder.disconnect(), closes TCP session
=20
I think session.next() perhaps needs changing when checkSessionTime is
false to generate a logout message rather than calling reset(), unless
there's another timer somewhere meant to do that which might have
missed.

	-----Original Message-----
	From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Steve Bate
	Sent: 26 May 2006 13:57
	To: qui...@li...
	Subject: RE: [Quickfix-developers] QFJ: Session EndTime and
Logout
=09
=09
	Toby,
	=20
	This might be related to a bug that was fixed this morning in
Subversion. The logon and logout timeout defaults were zero. They should
have been 10 seconds for the logon timeout and 2 seconds for the logout
timeout. These are configurable, so the workaround for now is to set the
timeouts explicitly in the configuration file.
	=20
	Steve


  _____ =20

		From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Shepheard, Toby (London)
		Sent: Friday, May 26, 2006 2:00 PM
		To: qui...@li...
		Subject: [Quickfix-developers] QFJ: Session EndTime and
Logout
	=09
	=09

		Hiya,=20

		A quick question on the Session EndTime. I'd assumed
that when running as an Initiator, QFJ would send a Logout message (and
await a Logout response for LogoutTimeout seconds) when the EndTime is
reached, but when I tested it, it just does a TCP FIN (disconnect). Is
this expected behaviour or a bug?

		I'm running with a ThreadedSocketInitiator, QFJ 1.0.0.=20

		[2006-05-26 12:24:23,126][INFO ][QFJ Timer
reuters.protocol.ReutersQFApplication]:   Sending FIX heartbeat message
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1

		[2006-05-26 12:24:23,126][INFO ][QFJ Timer
quickfixj.msg.outgoing]:
8=3DFIX.4.4=019=3D68=0135=3D0=0134=3D15=0149=3DML_RTFI_DEV1=0152=3D200605=
26-11:24:23.126=0156=3DRE
UTFIXTEST1=0110=3D062=01

		[2006-05-26 12:24:44,083][INFO ][AnonymousIoService-1-2
quickfixj.msg.incoming]:
8=3DFIX.4.4=019=3D68=0135=3D0=0134=3D17=0149=3DREUTFIXTEST1=0152=3D200605=
26-11:24:06.324=0156=3DML
_RTFI_DEV1=0110=3D065=01

		[2006-05-26 12:24:44,083][DEBUG][QF/J Session
dispatcher: FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
reuters.protocol.ReutersQFApplication]:   QuickFIX session
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1: fromAdmin()

		[2006-05-26 12:24:44,083][INFO ][QF/J Session
dispatcher: FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
reuters.protocol.ReutersQFApplication]:   Received FIX heartbeat message
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1

		[2006-05-26 12:24:53,146][INFO ][QFJ Timer
reuters.protocol.ReutersQFApplication]:   Sending FIX heartbeat message
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1

		[2006-05-26 12:24:53,146][INFO ][QFJ Timer
quickfixj.msg.outgoing]:
8=3DFIX.4.4=019=3D68=0135=3D0=0134=3D16=0149=3DML_RTFI_DEV1=0152=3D200605=
26-11:24:53.146=0156=3DRE
UTFIXTEST1=0110=3D068=01

		[2006-05-26 12:25:02,830][INFO ][QFJ Timer
quickfixj.event]:   Disconnecting=20
		[2006-05-26 12:25:02,830][INFO ][QFJ Timer
reuters.protocol.ReutersQFApplication]:   Logged out from the FIX engine
for session FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1

		[2006-05-26 12:25:02,830][INFO ][QFJ Timer
protocol.session.ReutersSession]:   Logged out from FIX session, setting
AQ Session status to DISCONNECTED

		Regards,=20
		Toby=20

  _____ =20

		If you are not an intended recipient of this e-mail,
please notify the sender, delete it and do not read, act upon, print,
disclose, copy, retain or redistribute it. Click here
<http://www.ml.com/email_terms/> for important additional terms relating
to this e-mail.     http://www.ml.com/email_terms/
  _____ =20

RE: [Quickfixj-users] FW: [Quickfix-developers] QFJ: Session EndTime and Logout

[Steve B. <st...@te...>]

I just saw the crossposting. :-) I responded to the other list, but you =
can
reply here if needed.
=20
Steve


  _____ =20

From: qui...@li...
[mailto:qui...@li...] On Behalf Of =
Shepheard,
Toby (London)
Sent: Friday, May 26, 2006 2:39 PM
To: qui...@li...
Subject: [Quickfixj-users] FW: [Quickfix-developers] QFJ: Session =
EndTime
and Logout


Forgot about this new list, apologies for the cross-posting but I felt =
its
more appropriate here.
=20
-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Shepheard, Toby (London)
Sent: 26 May 2006 13:00
To: qui...@li...
Subject: [Quickfix-developers] QFJ: Session EndTime and Logout



Hiya,=20

A quick question on the Session EndTime. I'd assumed that when running =
as an
Initiator, QFJ would send a Logout message (and await a Logout response =
for
LogoutTimeout seconds) when the EndTime is reached, but when I tested =
it, it
just does a TCP FIN (disconnect). Is this expected behaviour or a bug?

I'm running with a ThreadedSocketInitiator, QFJ 1.0.0.=20

[2006-05-26 12:24:23,126][INFO ][QFJ Timer
reuters.protocol.ReutersQFApplication]:   Sending FIX heartbeat message
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
[2006-05-26 12:24:23,126][INFO ][QFJ Timer quickfixj.msg.outgoing]:
8=3DFIX.4.4=019=3D68=0135=3D0=0134=3D15=0149=3DML_RTFI_DEV1=0152=3D200605=
26-11:24:23.126=0156=3DREUTFI
XTEST1=0110=3D062=01
[2006-05-26 12:24:44,083][INFO ][AnonymousIoService-1-2
quickfixj.msg.incoming]:
8=3DFIX.4.4=019=3D68=0135=3D0=0134=3D17=0149=3DREUTFIXTEST1=0152=3D200605=
26-11:24:06.324=0156=3DML_RTF
I_DEV1=0110=3D065=01
[2006-05-26 12:24:44,083][DEBUG][QF/J Session dispatcher:
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1 =
reuters.protocol.ReutersQFApplication]:
QuickFIX session FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1: fromAdmin()
[2006-05-26 12:24:44,083][INFO ][QF/J Session dispatcher:
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1 =
reuters.protocol.ReutersQFApplication]:
Received FIX heartbeat message FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
[2006-05-26 12:24:53,146][INFO ][QFJ Timer
reuters.protocol.ReutersQFApplication]:   Sending FIX heartbeat message
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
[2006-05-26 12:24:53,146][INFO ][QFJ Timer quickfixj.msg.outgoing]:
8=3DFIX.4.4=019=3D68=0135=3D0=0134=3D16=0149=3DML_RTFI_DEV1=0152=3D200605=
26-11:24:53.146=0156=3DREUTFI
XTEST1=0110=3D068=01
[2006-05-26 12:25:02,830][INFO ][QFJ Timer quickfixj.event]:   =
Disconnecting

[2006-05-26 12:25:02,830][INFO ][QFJ Timer
reuters.protocol.ReutersQFApplication]:   Logged out from the FIX engine =
for
session FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
[2006-05-26 12:25:02,830][INFO ][QFJ Timer =
protocol.session.ReutersSession]:
Logged out from FIX session, setting AQ Session status to DISCONNECTED

Regards,=20
Toby=20

  _____ =20

If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, =
retain
or redistribute it. Click here  <http://www.ml.com/email_terms/> for
important additional terms relating to this e-mail.
http://www.ml.com/email_terms/
  _____ =20

[Quickfixj-users] FW: [Quickfix-developers] QFJ: Session EndTime and Logout

[Shepheard, T. \(London\) <Tob...@ml...>]

Forgot about this new list, apologies for the cross-posting but I felt
its more appropriate here.
=20
-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Shepheard, Toby (London)
Sent: 26 May 2006 13:00
To: qui...@li...
Subject: [Quickfix-developers] QFJ: Session EndTime and Logout



Hiya,=20

A quick question on the Session EndTime. I'd assumed that when running
as an Initiator, QFJ would send a Logout message (and await a Logout
response for LogoutTimeout seconds) when the EndTime is reached, but
when I tested it, it just does a TCP FIN (disconnect). Is this expected
behaviour or a bug?

I'm running with a ThreadedSocketInitiator, QFJ 1.0.0.=20

[2006-05-26 12:24:23,126][INFO ][QFJ Timer
reuters.protocol.ReutersQFApplication]:   Sending FIX heartbeat message
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
[2006-05-26 12:24:23,126][INFO ][QFJ Timer quickfixj.msg.outgoing]:
8=3DFIX.4.4=019=3D68=0135=3D0=0134=3D15=0149=3DML_RTFI_DEV1=0152=3D200605=
26-11:24:23.126=0156=3DRE
UTFIXTEST1=0110=3D062=01
[2006-05-26 12:24:44,083][INFO ][AnonymousIoService-1-2
quickfixj.msg.incoming]:
8=3DFIX.4.4=019=3D68=0135=3D0=0134=3D17=0149=3DREUTFIXTEST1=0152=3D200605=
26-11:24:06.324=0156=3DML
_RTFI_DEV1=0110=3D065=01
[2006-05-26 12:24:44,083][DEBUG][QF/J Session dispatcher:
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
reuters.protocol.ReutersQFApplication]:   QuickFIX session
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1: fromAdmin()
[2006-05-26 12:24:44,083][INFO ][QF/J Session dispatcher:
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
reuters.protocol.ReutersQFApplication]:   Received FIX heartbeat message
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
[2006-05-26 12:24:53,146][INFO ][QFJ Timer
reuters.protocol.ReutersQFApplication]:   Sending FIX heartbeat message
FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
[2006-05-26 12:24:53,146][INFO ][QFJ Timer quickfixj.msg.outgoing]:
8=3DFIX.4.4=019=3D68=0135=3D0=0134=3D16=0149=3DML_RTFI_DEV1=0152=3D200605=
26-11:24:53.146=0156=3DRE
UTFIXTEST1=0110=3D068=01
[2006-05-26 12:25:02,830][INFO ][QFJ Timer quickfixj.event]:
Disconnecting=20
[2006-05-26 12:25:02,830][INFO ][QFJ Timer
reuters.protocol.ReutersQFApplication]:   Logged out from the FIX engine
for session FIX.4.4:ML_RTFI_DEV1->REUTFIXTEST1
[2006-05-26 12:25:02,830][INFO ][QFJ Timer
protocol.session.ReutersSession]:   Logged out from FIX session, setting
AQ Session status to DISCONNECTED

Regards,=20
Toby
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the =
sender, delete it and do not read, act upon, print, disclose, copy, =
retain or redistribute it. Click here for important additional terms =
relating to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------

RE: [Quickfixj-users] logon timeout defaults to 0?

[Steve B. <st...@te...>]

Hi Brad,
 
Thanks for the report. I'll look into it. Do you mind entering a Jira issue
for this?
 
Thanks again,
 
Steve

  _____  

From: qui...@li...
[mailto:qui...@li...] On Behalf Of Brad
Harvey
Sent: Friday, May 26, 2006 12:07 AM
To: qui...@li...
Subject: [Quickfixj-users] logon timeout defaults to 0?



Hi Steve, 

Sounds like you've been busy lately - 1.0.0, confluence and jira!  Great
work. 

We've come across a minor issue with 1.0.0.  We kept getting logon timeouts
- it seems that the timeout defaults to 0.  Setting the logon timeout
session setting explicitly to 10 solved this problem.

Regards, 
Brad. 

[Quickfixj-users] logon timeout defaults to 0?

[Brad H. <Bra...@gb...>]

Hi Steve,

Sounds like you've been busy lately - 1.0.0, confluence and jira!  Great
work.

We've come across a minor issue with 1.0.0.  We kept getting logon
timeouts - it seems that the timeout defaults to 0.  Setting the logon
timeout session setting explicitly to 10 solved this problem.

Regards,
Brad.