Ambal

VladimirMangos changed position handling when loading creatures in [11222] so it might cause problems to you. We'll take a look into this issue, michalpolko. Thank you for reporting.

Romain77, you'll get better results if you'll google for anticheat which is suitable for mangos.

No,it is not an anticheat - this patch is intended to speed up DB interaction. Current SQL requests in mangos are already protected from SQL injection attacks, prepared statements simply do not require any additional code to do this.

Fixed broken SQL syntax for some prepared statements. Thanks to Undergarun for reporting.

Your changes are fine, kero99. I've pushed them into my repo. Thank you very much

it is resolved, kero99. Try again

I've fixed compilation issues and updated my patch to the latest [11235] rev. Also more ODBC-compatible API is introduced for statement parameter binding. Feel free to try

Hi, everyone. kero99, thank you for pointing to compilation issue - I'll fix it definitely today. P.S. I think I'll change API a bit also to make it more ODBC-style compatible aka: SqlStatement stmt = db.CreateStatement(); stmt.addInt(); stmt.addBool(); ... stmt.Execute(); Exposing function parameters to client as it is done in current code is not very nice idea, IMO... Cheers

- looks like this is an issue with you VS2010 and not mangos itself. I'm able to compile mangos on Win7 w/o any issues with VS2005/2008/2010.

What tools do you use to compile mangos on Windows? If it is CMake - we suggest you to not use it for now.

Hi, everyone Here is the first part of prepared statement work I'm doing for the Core. If you are not familiar with prepared statements, here are the benefits they give: 1) more speed - your DBMS is not spending time on reparsing your SQL requests all the time, it just does it once; 2) less bandwidth with DBMS - sending data in binary format is very space efficient comparing with plain string requets; 3) more security - no SQL injection is possible. This part of a patch is intended to implement prepared statements support for INSERT+DELETE+UPDATE queries - such requests cover ~70% of all DBMS tasks. The SELECT statement support will be the next part of this work. Currently I've rewritten all SQL requests which are invoked from Player::SaveToDB() function. Also, if someone has any profiling data about what SQL requests are used most of the time - I'll greatly appreciate it NOTE: For PostgreSQL users there will be a compatibility fix, which will use current plain SQL requests - I don't have time to implement native support for it, sry =/ WARNING: BACKUP YOUR DATABASES!!!! And I would greatly appreciate if you can test this patch with mtmaps installed repo: https://github.com/Ambal/mangos/tree/prepared_statements update #1: PostgreSQL support is added. Major code refactoring. update #2: ODBC-style API for parameter binding. Fix reported compilation issue. Support rev [11235]. update #3: More item queries are using prepared statements. Compile errors on *nix are resolved with kero99 help. update #4: Fix broken SQL syntax for some prepared statements. Thanks to Undergarun for reporting. update #5: CRITICAL - rewrite some code due to serious issues with function static variable initialization in multithreaded environment. Thanks to Vinolentus. Expect slight increase in CPU usage. update #6: resolve issues caused by improper usage of static local variables. Should restore CPU usage to normal.

Thank you, faramir118 I'll definitely check your changes in nearest days since I'm currently very busy on workplace and with my 'prepared statements' branch. Cheers

Hi, faramir118. I'm glad to hear that you continue working on this patch Priority queue sounds very good to me - indeed, writes should have more priority than reads. Cheers

If you do not plan to host high population server (or not skilled with *nix ) - you can stick with Windows. Otherwise - *nix is the best choice so far.

In case there will be no reports about server instability with "visibility_op2_simplified" branch - it will get added into repo in nearest time as most simple and reliable solution out of all introduced patches. It also has the highest performance due to the fact that there is no need to traverse through all cells on map/any containers to search for objects which need to be updated - this is the main explanation why this patch is faster even than "relocation_opt_merged" patch disregarding of all those optimizations implemented in it. Cheers

Well, if you trust cipherCOM enough to invite him into the team - I don't mind, actually

I don't see alot of activity from cipherCOM - only 18 posts on this forum. Also he is not very active even in dev channel. So I have doubts if it is a good idea to invite him. IMO, currently we lack ppl who are skilled with spell system. After upcoming changes to Core (visibility optimizations, prepared statements, world tasks etc) there will be only spells and scripting left to push more efforts against. P.S. why not invite qsa and faramir118 into #mangos channel? They already proved their skills.

ah, you are too evil, faramir118 Ok, so "some queueing mechanism" will be the best choice then

cyberium, ThreadManager.spawn() limitation has nothing to do with AIO stuff.

Hi, faramir118. I'd stick with "session queue to prevent exceeding aio slot limits". All you need is to: 1) push all async read/write requests into one queue 2) count amount of active requests 3) upon read/write callbacks lower the active request count 4) execute pending tasks until active count limit will reach ACE_AIO_DEFAULT_SIZE (or whatever value you will pick up). This solution will work across all the platforms. You just need to find out if that ACE_AIO_DEFAULT_SIZE limit is applied for one ACE_Proactor object or per process. In first case implentation will be simple, in the second one it will require some more syncronisation. ACE_Atomic_Op<> will fit just fine to handle active request count. P.S. You will definitely need to count/remove from queue requests while disconnecting a client. Cheers

Thank you, Undergarun. It must be something weird in message block resize algorithm if your mangos process ate all your RAM - this cannot be detected as memory leak at all. Another frustrating error is "Max Number of AIOs=1024". Default value should be not lower than 4096 AIOs... But ACE code thinks in other way: #define ACE_AIO_DEFAULT_SIZE 1024 Undergarun, what is the value of "Network.Threads" config option? P.S. faramir118, you should test for EAGAIN or EWOULDBLOCK (whateven ACE is using to report operation overflow condition) error in case our send or receive operation wasn't successful to reschedule it. Or even create a per-proactor queue of async requests to workaround issues with max async IO request problem(?). If every ACE_Proactor object allows us on *nix 1024 async io requests, then better load balancing might help us. Cheers

In [11148]. Thanks

In [11147]. Thank you very much, nos4r2zod

In [11146]. Thank you

In [11145]. Cheers