Re: [Quickfixj-users] outgoing seqnum

[Joerg T. <Joe...@ma...>]

Hi Robert,

we currently use JdbcStore, but not JdbcLog (you sometimes call things "logging" where I would
expect the MessageStore; is it possible to you mix logging and saving state?).

In our test environment, all works well with JDBC access to PostgreSQL. Our customer uses Oracle 8
with OCI, there are currently installing our new version and maybe I get some feedback soon.

If I remember right, you are using Oracle 9? Which JDBC driver -- "thin:" or "oci:"? Please give me
some more details here.

For the moment, I would recommend to replace the JdbcLog by Log4J logging. This is flexible enough
for most purpose. For failover, it is important to keep the JdbcStore.

In general, I am very interested in your experiences because our customer also uses Oracle.

Cheers, Jörg

On 05/21/07 20:55, Robert Brueckmann wrote:
> Thanks for the reply.  I did as you said and set up a test
> environment...I am using JDBC logging against Oracle.  I'm the one that
> had a barrage of emails a few weeks ago about the problems with JDBC
> logging and Oracle playing nicely together.  I'm still intermittently
> getting the recursive exception about:
> 
> "JdbcLog cannot log SQLException due to recursive log errors!
> java.sql.SQLException: We are already in the process of making 1
> connections and the number of simultaneous builds has been throttled to
> 0"
> 
> Thing is, it IS logging to the database.  I get a record inserted in the
> Sessions table with the initial information, only the incoming AND
> outgoing seqnums are always set to 1.  I then enter an order in the test
> client the one vendor I'm testing with provided us to buy 500 shares of
> IBM.  The messages come through...all the messages are stored in the
> database, I let the heartbeat run for a while, then I shut down the
> engine and start it back up again.
> 
> Immediately I begin receiving:
> 
> "Serious Error:  Message sequence number: 1 is less than expected
> sequence number: 28"
> 
> And then the engine continues to logout and login, each time, internally
> incrementing that message count, but never once updating the session
> entry in the SESSIONS table in the database with the newly incremented
> outgoing sequence number.  Currently, the engine is up to 22 and the
> SESSIONS table record for this engine instance is still showing 1 for
> both the incoming and outgoing sequence numbers...but internally, it's
> obviously incrementing the count.
> 
> Nowhere on the console are there any database exceptions relating to
> having a problem inserting into the SESSIONS table or updating that
> table.  Every so often I'll get something like this:
> 
> "2007-05-21 14:44:47,361 DEBUG [HouseKeeper] proxool.ConnectionPool
> (ConnectionPool.java:447) - 000079 (00/01/00) - #0001 removed because it
> has been active for too long.
> 2007-05-21 14:44:47,377 WARN  [HouseKeeper] proxool.HouseKeeper
> (HouseKeeper.java:149) - #0001 was active for 11562 milliseconds and has
> been removed automaticaly. The Thread responsible was named 'QFJ Timer',
> but the last SQL it performed is unknown because the trace property is
> not enabled.
> JdbcLog cannot log SQLException due to recursive log errors!
> java.sql.SQLException: We are already in the process of making 1
> connections and the number of simultaneous builds has been throttled to
> 0"
> 
> I don't know what to do about these exceptions or the one I mentioned
> above, but messages and the message log tables both seem to be capturing
> the messages fine and running the engine without shutting it down and
> restarting for a long period of time, quite a few days in a row...the
> engine seems to work as does the logging without a hitch...but the
> minute we shut it down, that internal incrementing is lost and the
> sessions table sequence numbers are always initiated with 1 and we get
> stuck in a sequence reset loop until the engine increments to a number
> the endpoint session can handle, then a successful reset request is
> handled and things carry on normally.
> 
> Any thoughts?  Should I just give up on JDBC logging in conjunction with
> an Oracle database?  
> 
> Is there a better way to handle fail-over?  The reason the IT guys here
> wanted database logging was so if the FIX engine server went down, we
> could fire up the fail-over server and it would be able to look at the
> database logs (which reside on a totally different server) and pick up
> seamlessly where the initial instance left off.  If we use just basic
> file logging and the entire FIX server crashes and we can't get to the
> log files, what do we do?  Am I completely confused in thinking that the
> database logging approach would be better for my scenario or are there
> alternatives?
> 
> Thanks so much!
> 
> robert l. brueckmann
> vice president
> merlin securities
> 712 fifth avenue
> new york, ny 10019
> p: 212.822.4821
> f: 212.822.4820
> 
> 
> 
> Merlin Securities - #1 Prime Broker North America, #1 Prime Broker Single Strategy Funds, #1 Prime Broker Funds Under $100M - Global Custodian 2007
> 
> 
> From: qui...@li...
> [mailto:qui...@li...] On Behalf Of
> Steve Bate
> Sent: Sunday, May 20, 2007 6:01 PM
> To: qui...@li...
> Subject: Re: [Quickfixj-users] outgoing seqnum
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>> We had to stop our engine mid-day today to do some database 
>> maintenance.  ...
>>
>> Why is the sessions table not being updated each time the 
>> outgoing seq num is being incremented by the engine?  Why is 
>> this not being maintained?  
> 
> I don't know based on the information you've provided. You
> say you were doing database maintenance. If the engine's
> database connection was bad it might explain the problem.
> You'd see information in the log file and/or event log
> table if this was the cause. This could happen if the
> database was restarted but the FIX engines were not.
> 
> Was the outgoing sequence number = 1 in the sessions table?
> This information won't help to explain the lack of updates,
> but it will tell me if the session was reset or whether the
> engine just couldn't read the information from the database.
> 
>> If we need to stop and start the 
>> engine in the middle of the day, we obviously don't want this 
>> to happen every time.  What can we do?  
> 
> I'd be surprised is this was an issue directly related to
> stopping and starting the engine midday. Set up a client
> and server test environment using a JDBC message store and
> try stopping and starting. It should work. I don't personally
> use the JDBC message store, but there are tests for the
> implementation and others use it. There are no bug reports
> related to this type of behavior.
> 
>> In this instance, we 
>> contacted the endpoint and they reset the seq num on their 
>> end so we could catch up to a reasonable number and then we 
>> captured all missed messages. Is there a bug in the jdbc logging?  
> 
> Based on the information so far, I'd guess not. Check the log
> files for additional clues. 
> 
>> Any thoughts on what we can do to better handle a mid-day 
>> shutdown and restart that would allows us to pick back up 
>> where we left off with our endpoint?
> 
> You just be able to restart. If you have any other information,
> please let us know.
> 
> Steve
-- 
Joerg Thoennes
http://www.macd.com                 Tel.: +49 (0)241 44597-24
Macdonald Associates GmbH           Geschäftsführer: Roger Macdonald
Lothringer Str. 52, D-52070 Aachen  Amtsgericht Aachen, HRB 8151, Ust.-Id DE813021663