Ambal

Your problem is connected to this code in Player::SaveToDB() where we save zoneId for player. So in case GetZoneId() or GetCachedZoneId() will return you the 0 (zero) zone_id - you have troubles. ss << (IsInWorld() ? GetZoneId() : GetCachedZoneId()) << ", "; We cache player's zone_id while he is in world and might reuse this value when saving character. Question is why we get 0 (zero) zone_id there... Wrong DBC data, anyone? fallenangelX, can you place some MANGOS_ASSERTs in TerrainManager::GetZoneIdByAreaFlag() and TerrainManager::GetZoneAndAreaIdByAreaFlag() to see if we return zone_id = 0 for your case? Does this happen to ALL characters who fly into Plaque Lands? Or only with DK? Do you have coordinates of that particular place where your character gets saved with zero zoneid?

Thank you, Undergarun Your test results are fantastic! For branch_2 and new patch performance difference can be explained by the fact that for 1 sec player can run ~7 yards != 10 yards default in second patch => less updates. Plus, in branch_2 we update visibility only if player moves away from certain point - no updates for player if he is running around certain point => less updates This can be tricky but no worries, everything will be fine Anyway, I and SilverIce have STRONG arguments about where we can improve optimizations Cheers to everyone

Guys, you should test this branch: https://github.com/SilverIce/mangos/tree/relocation_old_ver2 instead of branch_1 Do not mess patches - this is very important since they differ greatly in terms of performance

We'll think of pre-creating all non-instancable maps upon server startup so your FindMap() calls will be always successful. This should simplify MapManager interface even more: 1) CreateMap(uint32 mapid, Player& plr) - to create instances for player 2) LoadContinents() - to create Map objects and fill in registry in MapManager upon server startup. This will be influenced by detail whether or not non-instancable maps can be unloaded or not - not all non-instancable maps are continents... But will see P.S. Current transport system should be rewritten too since transports in dungeons are not possible nowadays -> only players can create dungeons, everything else will fail... But this will be possible only when proper "World Tasks" system will be released. Cheers

In current core you cannot simply use MapManager::CreateMap() w/o using hacks - you should atleast pass valid WorldObject pointer in order to create continent map. If you pass NULL - your server crashes. Basically all continent maps are created in MapManager::LoadTransports(), so your FindMap() will return correct results. There is no way to create an instance/BG/Arena map w/o using valid player object.

Well, thing is that MySQL 'autocommit' mode turns ANY sort of DB request into single transaction if you do not specifically create transaction by START TRANSACTION request. So for SELECTs it was stated as overkill BUT noone from MySQL team said that SELECTs will return you empty resultsets if you will not wrap your SELECT into transaction - this happens with REPEATABLE_READ (default isolation mode for InnoDB)!!! With READ_COMMITTED it returns data but we should better keep this option enabled for our safety.

Try to update to [11061] or newest revision - your issues should be fixed now.

With small changes in [11062]. Thank you

The real cause of your problems is disabled by me 'autocommit' MySQL mode. Fix submitted in [11061]. UPDATE URGENTLY!!! P.S. this feature behaves so strangely that now I become to be scared by MySQL... W/o it turned on you should wrap even SELECTs into transactions to be sure that they will really get any results to you. Cheers.

So you did everything I told you in the previous post and it worked fine? If so then this only means that you get notification about character deletion BEFORE it was actually deleted from the database! WorldSession::HandleCharDeleteOpcode( WorldPacket & recv_data ) { .... Player::DeleteFromDB(guid, GetAccountId()); //<= fully async character deletion! //we send opcode right away w/o waiting for character to be removed from DB WorldPacket data(SMSG_CHAR_DELETE, 1); data << (uint8)CHAR_DELETE_SUCCESS; SendPacket( &data ); } UPDATE: ok, I'll try to reproduce this issue today with default transaction isolation settings for DB. Need more information about this issue: what is the workflow to reproduce this issue?

Oh, so this is the problem only when you are trying to delete account from the client? So you get notification about successful character deletion and when you try to create more chars - you fail because server thinks that you still have tonns of chars? And if you delete char from mangos command line you can create characters w/o problems? Try to do this: 1) start your client and login 2) delete your character from client 3) wait for one minute before creating new character 4) try to create an account and report to us if this operation succeeded or not.

Antiroot, is this the SQL logs mangos is writing ("LogSQL = true")? If so - in this log we protocol all queries from multiple databases at once. So multiple START TRANSACTION records are expected there. These SQL requests you've showed to us are from Player::SaveToDB() function - they are not connected to character account deletion. Are you removing character from mangos command line?

Thank you, antiroot. Please, let me know if you'll be able to reproduce this issue again with default settings so I can take a look and help you. We are not interested in the fact that users have to change configs of their MySQL servers in order to keep up with the latest changes in the Core. Cheers.

Hi, antiroot. I'll very appreciate if you can explain what issues with 'autocommit' you had as well as did you actually changed 'transaction-isolation' level in config? This mode should be automatically disabled for every single connection we establish with MySQL now. We use BEGIN TRANSACTION - COMMIT instead. 'Autocommit' was enabled by-default in previous DB layer and if it took you to update your config in order to fix your issues - we need to know about that. Cheers.

In [11045] Big thanks to Undergarun, kero99 and selector. Have fun

Undergarun, thank you very much Do you have any data about max queries executed on current mangos core so we can make a quick comparison? Maybe you have a new 24h/48h SQL profiling statistics with this patch? If anything is fine then get ready for this patch to be submitted in nearest 1-2 days. This also does not mean that we will abandon DB layer and will not improve it any further Cheers

faramir118, ACE_Proactor class uses IO completion ports (IOCP) under Windows to do its tasks. On *nix it should use the same advanced techniques. So if you'll be able to make your patch work with "Proactor" pattern - we'll definitely accept it into the Core. Cheers

faramir118 - for development purposes you can preload mmaps data into memory on server startup and process config reloads on runtime. But when you'll finish - it is better to stick with the way vmaps and regular geodata are loaded by the server - on-the-fly.This will save alot of memory for those who wishes to use mmaps but also wants to save some RAM. And don't forget that 99% of server setups are "set it and forget it" . Cheers.

If you are trying to make mmaps support config reload - this is, IMO, bad idea since such functionality should be initialized only on server startup. Upd: if you like you can support config reload only while patch is under development. When it will be ready to be included in Core, please, remove this logic. Best regards.

Hi, Undergarun. Thank you and kero99 for pointing on compilation issue. Autoreconnect feature is disabled by default in MySQL 5.1. Enabling it is not a problem as well as using a server-side ping() functionality... But if your server looses connectivity to DBMS - it is fatal error (IMO) and simple attempt to reconnect would not help in 99.73% of cases. Also, there are some side effects which will be hard to deal with when we will have prepared statements implemented: http://dev.mysql.com/doc/refman/5.0/en/auto-reconnect.html. So I personally have doubts if we actually need this logic in Core. Patch is updated: 1) PostgreSQL support is added; 2) compilation error in latest commit is fixed; 3) support for rev [11040]. Cheers

Ok, you have a few more days to test this patch and submit your comments while I'm preparing a PosgreSQL patch. ...And then we will move on 'prepared statements'. Cheers

While everyone seems happy with configurable pool of DB connections, a few words about what is the future of DB layer will be. We should move on using 'prepared statements'. Tonns of queries are executed alot of times, so prepared statement will be very helpful - your MySQL servers will not consume CPU on reparsing the same requests again thus being able to process more requests. Network bandwidth will be reduced since data is transfered in binary format etc. Extensively increasing amount of connections to DB cannot save us with transactions - it is VERY difficult and error prone to execute them in the safe way using several connections. So this is +1 to move on using prepared statements. We wanted to use third-party DB library like SOCI http://soci.sourceforge.net/ which supports by using native API DBMSes like MySQL/PostgreSQL/Oracle. But it uses unusual syntax to work with DB so I have doubts about its chances to get into mangos repo. We can try and revive patch written by Wyk3d long ago since currently I don't see any library which can be easily integrated into mangos. Cheers

Configurable connection pool for SELECTs is added to the latest version of this patch, which is updated to rev [11030]. Up to 16 connections per database. Do not spawn more connections than threads you create with mtmaps patch - this is useless. Additional patch details in first post. Update: now interesting data about number of transaction requests we've created to put data into each database in mangos: 1) characters - 411; 2) mangosd - 51; 3) realmd - 42. And number of SELECT statements we've created to preload data on server startup: 1) characters - 39; 2) mangosd - 151; 3) realmd - 1. These numbers are approximate since code search sometimes doesn't provide exact data Yet anyway, with these numbers and profiling data kindly provided by Undergarun we can think of how to tune our DBMS, amount of connections and code Cheers

Thank you, Undergarun I'll see charts when I'll come back home. Also I have to admit that connection pool itself is not able to save you from 2k ppl trying to login Especially if only one thread is processing async login requests

Increased CPU utilization by MySQL server can be explained by more queries parsed and executed in parallel. More queries basically means more SELECTs - with current DB layer where SELECTs occupy only 28.3% of total DBMS requests and can be simply 'starved' by transactions since we have only one single connection protected by mutex. With proposed patch SELECTs are executed in parallel so there is only contention for sync connection. With connection pool this contention can be lowered even more. Cheers