This one is wierd!
I am running a local test server on which I have updated xmlspawner (to version 3.10) and a few other scripts. My public server is not on my local machine.
The computer I am using is slow, mostly because it has WindowsME as an operating system. So I have wiped all facets and left the player accounts.
I was on testing some script updates and I used the xmlfind command to search for potions (including those on the internal map) and came up with a result of something like 230 potions . . . and a few seconds later I lost connection. Being on the same computer as the server, I had never experienced this without the server going down. There were no errors in the console window. Just the standard Disconnected message.
I reconnected and tried again with the same result. So I tried searching for playermobiles (over 200 of them) and got disconnected again . . . same thing.
I searched for something else where the resulting amount was only 5 items, and did not lose connection. Seems to disconnect only when longer lists are generated.
Now, logging on to my public server (across town) using the same client, I can use xmlfind without any issues. The public server is using an older version of XMLSpawner, somewhere around version 3.08 I believe.
Is it possible that it is a memory issue on my machine here? Since WinME doesn't use all the RAM I have? I would have expected a client error if that were the case, rather than a disconnect.
Any thoughts?
strange. It sounds like a problem with synchronizing gump packets that might result from running the client and server on a slower machine.
The search does run in a separate thread to avoid blocking other server activity, so it is possible that there are sync issue when the results of the search are sent back through a gump via the main server thread.
I'll take a look.
That sounds logical. Well, it's not a big deal, so long as it is isolated to those conditions. I just didn't want to have the same problem on the public server, as I plan to update XMLSpawner2 on that machine today.
Thanks Arte.
I dont think that it is a version issue.
On rare occasions I have a few reports of corrupted display text in the xmlfind gump even with older versions, and I wasnt thinking of syncing as a possible cause, but they might be related.
It is pretty easy to assure sync with the main thread so I will probably add it to the beta_311 and you can give it a try if you get a chance.
(edit)
ok, I have put a modified version of xmlfind.cs in the beta_311.zip. Take a look and see if it fixes the problem.
http://xmlspawner.15.forumer.com/index.php?showtopic=53
As a General rule i dont usually revive old posts but the problem i have found is very simular to the problem discussed in this post. This is just for your information, im not waiting on anyone to fix it

its not that big of a problem lol
I am running the following:
RunUO - [www.runuo.com] Version 2.0, Build 2357.32527
Core: Running on .NET Framework Version 2.0.50727
XmlSpawner2 version 3.09a updated 5/8/05
Note::
apparently my version is a little old so i will try to download the most recent version and see if it does the same as below.
let me try to explain what i did and what happened:
I converted all of my PremiumSpawners to XmlSpawners using a Conversion utility i wrote, after the conversion i went to each facet and used the [xmlsave command to save the spawns, i wanted them in thier own folder so i did :
[xmlsave SavedXmlSpawners\facetname
I did this for each facet, while i was doing it for each facet twice i was disconnected, the server didnt crash, my client was just disconnected. I looked at my server console and found the below message.
QUOTE |
Client: 127.0.0.1: Too much data pending, disconnecting... Client: 127.0.0.1: Disconnected. [0 Online] [FireStorm]
|
I used AgentRansack to do a search through my scripts but couldnt find that message so i searched through the Core Source files that i downloaded and found that specific message here in NetState.cs in:
CODE |
public void Send( Packet p )
|
heres the whole method:
CODE |
public void Send( Packet p ) { if ( m_Socket == null || m_BlockAllPackets ) { p.OnSend(); return; }
PacketProfile prof = PacketProfile.GetOutgoingProfile( (byte)p.PacketID ); DateTime start = ( prof == null ? DateTime.MinValue : DateTime.Now );
int length; byte[] buffer = p.Compile( m_CompressionEnabled, out length );
if ( buffer != null ) { if ( buffer.Length <= 0 || length <= 0 ) { p.OnSend(); return; }
if ( m_Encoder != null ) m_Encoder.EncodeOutgoingPacket( this, ref buffer, ref length );
SendEnqueueResult enqueueResult;
lock ( m_SendQueue ) enqueueResult = ( m_SendQueue.Enqueue( buffer, length ) );
if ( enqueueResult == SendEnqueueResult.Begin ) { int sendLength = 0; byte[] sendBuffer = m_SendQueue.Peek( ref sendLength );
try { IAsyncResult res = m_Socket.BeginSend( sendBuffer, 0, sendLength, SocketFlags.None, m_OnSend, null ); //Console.WriteLine( "Send: {0}: Begin send of {1} bytes", this, sendLength ); } catch // ( Exception ex ) { //Console.WriteLine(ex); Dispose( false ); } } else if ( enqueueResult == SendEnqueueResult.Overflow ) { Console.WriteLine( "Client: {0}: Too much data pending, disconnecting...", this ); Dispose( false ); }
p.OnSend();
if ( prof != null ) prof.Record( length, DateTime.Now - start ); } else { Dispose(); } }
|
I did some further testing on it and i found out when i logged onto two different accounts it only disconnected the Admin account that used the [xmlsave command, the player account was unaffected by it.
after using my conversion utility i had 2,717 xmlspawners in felucca on further testing in this facet i used the:
several times, heres a history of my attempts
first diconnected.
second successfull save.
third disconnected.
fourth disconnected.
fifth successfull save.
sixth successfull save.
apparently its a 50\50 deal lol at least in Fel
before converting any PremiumSpawners to Xml in Trammel i had 673 spawners i made 10 attempts to do [xmlsave filename and all 10 attempts were successfull.
after converting Trammels PremiumSpawners to Xml i ended up with 3183 XmlSpawners for Trammel.
attempts to save:
first successfull save.
second ditto
third ditto
fourth ditto
fifth woohoo disconnected ...
sixth successfull save.
seventh ditto
eighth disconnected ...
Looks preaty random here to me...

after all of this the player account online continued to be unaffected by all the disconnects. and after checking each saved file i found that the files where i had been disconnected appeared to have saved fine even after it disconnected me.
roadmaster
I think this is an issue with the verbose messages that are sent to the client by default when the spawners are saved. Too many messages too quickly can cause that kind of disconnection.
You can test this out by changing the verbose flag to false in the SaveSpawns method in xmlspawner2.cs around line 6300
QUOTE |
// save the list SaveSpawnList(e.Mobile, saveslist, dirname, oldformat, false); }
|
This will cause the spawners to be saved without reporting each one as it is saved.
QUOTE |
You can test this out by changing the verbose flag to false in the SaveSpawns method in xmlspawner2.cs around line 6300
|
Ok i changed the flag to false and tested both felucca and trammel each 20 times all successfull no disconnects, also as a side note i noticed that without displaying all those messages it cut the time down significantly on how long it took to save the spawns. Id say at least in half but probably more than that. At least thats what it looked like, maybe the time it actually took to save was the same but it looks less due to not recieving the messages... if that makes sense.
in other words maybe recieving the messages made it look like it was taking longer than it actually was to save them.
either way with the verbose flag set to false it seems to stop you from being disconnected.
roadmaster
yes, not sending the messages will definitely speed it up.
Thanks for the help, im gonna leave that setting to false. Hopefully when next i upgrade to a newer version ill remember to make that change. lol
thanks again.
roadmaster
This is just my opinion, but personally I only think it should report when it fails to save.
If you wanted to enhance it though, perhaps it could even have a gump pop up that would let you visit each of the spawners that it had failed to save.
QUOTE (Xarlon @ October 03, 2006 04:08 pm) |
This is just my opinion, but personally I only think it should report when it fails to save.
If you wanted to enhance it though, perhaps it could even have a gump pop up that would let you visit each of the spawners that it had failed to save. |
I'm going to add a '-silent' option to both saving and loading commands.