Thread: RE: [Quickfix-developers] QuickFix FailOver/Farming Support.
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Steve B. <sb...@sm...> - 2006-05-28 07:19:35
|
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 |
|
From: Steve B. <sb...@sm...> - 2006-05-29 05:55:38
|
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 |
|
From: Oren M. <or...@qu...> - 2006-05-29 18:31:51
|
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 |
|
From: Steve B. <sb...@sm...> - 2006-05-29 20:24:58
|
> 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 |
|
From: Sean K. <sea...@pi...> - 2006-05-30 13:07:27
|
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 |
|
From: Oren M. <or...@qu...> - 2006-05-30 16:17:58
|
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 > |
|
From: Staffan U. <sta...@mu...> - 2006-06-02 15:57:50
|
Hello, We moved a FIX gateway server built on quickfixj into production a few days ago, and it quickly became quite clear that the java program leaked menory somehow, and so did the mysql server. Both servers grew to about 2GB each in a few hours. After that, we had to restart the processes because of performance problems. Anyway, I traced the problem to the JdbcStore class, which allocates a new statement for each call. The statement is never closed. Depending on the Jdbc driver, these statements might or might not be garbage collected, but in our case they were at least not. After patching the code everything seems to run really well and fast. Anyway, I'm a bit reluctant to post a patch since the one I made is so ugly... It seems that someone started work on caching prepared statements in the JdbcStore class (using the statementCache member), but since it is not finished, it results in the leak. The JdbcLog class does not have this problem. At first glance it seems very easy to make the cache work (the only missing statement is one that actually adds the statement to the cache). It seems to me that thread safety needs to be taken into account, which might not be trivial. Maybe that's why the cache mechanism was never finished? Btw, my current patch just adds a close() call to a number of places. Staffan |
|
From: Ferran C. <fer...@vi...> - 2006-06-02 16:54:26
|
Hi, I was sending and receiving messages when a "SessionNotFound" exception was thrown when calling to "sendToTarget()". After that, the communication was reestablished but one message was missing because my application didn't handle this exception. Any want knows when the session can be destroyed during a communication? I tried to reproduce cutting the connection but it never happens again. Regards, -- Ferran Casarramona Dep. Broker Visual Chart Group |
|
From: Oren M. <or...@qu...> - 2006-05-28 09:32:47
|
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 > |
|
From: Oren M. <or...@qu...> - 2006-05-28 18:26:18
|
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 > |
