On Tue, 25 Mar 2008, Tim Ansell wrote: > On Fri, 2008-03-21 at 15:10 +1300, Lee Begg wrote: > > There a some substantial changes I would like to make soon and quickly, > > namely making the Manager's asynchronous to improve the performance of > > the server. > > To be honest I would wait until after a release for these changes. We > have not hit any type of performance problems with tpserver-cpp yet > (specially the networking side).
I was/am going to wait until after a release to do these changes. The main reason for doing them now (at the interface level, not necessarily implemented fully asynchronously) was that it is going to change a lot of code, and it might be better to do it now, instead of having to rewrite 5 rulesets instead of 2.5 (MTSec not really done yet). > > Persistence in tpserver-cpp is quite well broken and all the current work > > I'm doing to fix it will have to be done again anyway. > > My theory is something like this, "A crash which looses data is critical > while a crash which doesn't loose data it is only an annoyance". Fair enough. > Following this theory persistence is very important as any segfault at > the moment causes you to loose the complete game you are playing. (In > theory) With working persistence you could just restart the server and > continue playing. That's the idea... > > I am proposing to remove the mysql module from the build and the tarball. > > It will be left in it's current condition in git. Is this acceptable? > > Comments? > > Would doing a sqlite or other module be quicker? My guess is updating > the mysql one is going to be our best option. Nope. Currently it's a matter of updating the various methods of saving, updating, deleting and retrieving the various objects in the database that has changed since the last release. The interaction between the managers and persistence needs to be fixed as well. > I would recommend getting it into a state where the database is always > in a consistent state before and after turn processing. Being able to > restore to the last "good" state would be very useful (IE just after the > last turn processing occurred). This could be done by wrapping > everything else in a huge transaction (make sure you are using InnoDB). > If you loose a few orders here and there it is not such a huge problem. > > So my proposal looks like this <snip> I will look into this. > That diagram looks pretty confusing, but it should be fairly simple. > > Tim 'Mithro' Ansell My current best guess for tpserver-cpp release is: 1-2 weeks fixed mysql persistence 2-4 weeks fixing manager-persistence interaction 1 week final polish for release So between late April and early June. Encouragement is encouraged. Later Lee
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
