0005317: Flotsam asset cache error

Notes
(0017803) samiam (reporter) 2011-01-08 02:32 edited on: 2011-01-08 02:39	That message comes from the wait state of the I/O read or write. If an attempt is made to write to the file at the same time it is in use you will get that. Depending on a few hardware factors this will prob allways occur randomly. On slower HD's typicly you want to increase the wait state time. That places the current readwrite req. on hold should it happen. You have to fiddle with a few numbers to find what is best for your hardware. I typicaly use: WaitOnInprogressTimeout = 4500 CacheDirectoryTiers = 2 CacheDirectoryTierLength = 2 DeepScanBeforePurge = true The larger tier and length helps spread out the chance and the waitONinprogressTimeout adds to also lessen the chance of it more. The effect is none the less harmless as it will check again anyway and correct for something it missed. Mostly you will see this if you have made a new cache (nothing there yet) but are loading allready existing regions that have alot of content. Once it has done its thing though and after restarts this stops. I also make use of the abuilty to set the cache folder out side of the Opensimfolder, this way i can avoid it having to make a new cache folder and files eachtime i test a differnt rev. Tnx

(0017804) samiam (reporter) 2011-01-08 02:58	Also Odd things can happen if you share the same cache folder with more than one instance. I dont recomennd doing that. Found it best to give each instance its own cache folder. This way it cant mix up the requests and also lessent the chance evan more that an I/O colision will happen.

(0017805) Bruce (reporter) 2011-01-08 15:47	Hi samiam:-) Thank you for your input. Confirming that this problem occurred on first-time run of a new opensim.exe instance (r/14750) after a clean install when asset-cache folder was empty. However, this is now occurring randomly (startup_command.txt file with fcache assets command not used to eliminate the possibility of any lock-up at startup) and apparently there is no trigger or time factor for these occurrences. No flotsam cache problems with r/14740 or earlier (no hardware changes were made). However, some other odd problems started with r/14740: (a) need to restart simulator two or three times in a row before scripts in all regions are working properly; (b) scripts in last region listed in region.ini file are not firing at all, even after multiple simulator restarts (region.ini unchanged and opensim.exe console reports on channel -800 that all regions are fine); and (c) flags in MySQL table "regions" are not recording anything (they remain unchanged) when objects and/or scripts options are changed in the viewer (World>About Land>Options). Compared MySQL database table entries for the simulator on interface 7 (r/14370) with those for the simulator on interface 7b and wondering if all 3 of the above mentioned problems could be related with database issues (looks like this will be the next test objective).

(0017806) samiam (reporter) 2011-01-08 17:15	Well all i can add then, Defrag your HD (just to be shure).Keep inmind that Flotsam can and does have a low priorty to re-filling. It takes quite a long time to re-build it. In our case at least a day. Our members know when i have cleared it anymore because its seen as lag why it refills again. In my case around 20 regions per instance and mostly filled with a mix of scripts,prims and physics (alot of stuff). As it recovers, things slowly get better but always takes quite a while. Thats why i place flotsam folder out side of opensim folder. As far as the other things you mention, i reaaly dont think flotsam is the resion.

(0017807) samiam (reporter) 2011-01-08 17:32	Scripts are persisted in the scritpengine folder btw, When a script is running it saves its state there. If it is cleared its not un-common to have to reset some of the bigger ones. If that folder isant preserved on an update you no doubt will have to reset scripts again. That isant new ether. That folder can also be set outside of opensim folder as well. If i forget about it, we do have to run around checking things to make shure there all running again. It can be a real chore sometimes! Flotsom has nothing to do with this though. tnx

(0017808) samiam (reporter) 2011-01-08 18:20	One of the bigger Offenders i have found has been when some 3rd party modules call outside php functions (xmlrpc) can mess with startup and client logins depending on the systems latency at the time. I do see a less randomness when it dosent load groups (xmlrpc)and a few other things. Usualy i wount see messages like 'Cant find baked textuer for xxxx' on login. Why it matters im not shure but more random things pop up when it has to make xmlrpc calls than when it dosent. Flotsam also has little todo with that.

(0017809) samiam (reporter) 2011-01-08 19:07	SubNote: I have a new server ariving monday. It has 3x the the I/O thruput as what i normaly test on. When i think of the common reports of random things happning, I/O comes to mind as a common thing that happens. Its possable that I/O is getting hit really hard at startup perhaps leaving it in bad state but is running anyway. When alot of I/O calls are made at the same time a flood of things happens as a result CPU usage gets slammed, Mem spikes up a bit and so on. If thats the case i should see alot less random problems under the same test conditions that im use to. Have to see and i know thats reaching :)

(0017811) samiam (reporter) 2011-01-08 22:01	@Bruce, i hapened to remember something i did whenever i suspected disk caching may be playing a part in some bug and that is to use CenomeCache. If you have the ram to spare it can help to eliminate some of the possabuiltys. Its been sometime since i have used it so im not shure of the state of it at current revs. It gen was well thought of and qute stable.

(0017819) Bruce (reporter) 2011-01-11 13:18	Problem solved, was hardware related. Thank you samiam for your inputs.

Issue History
Date Modified	Username	Field	Change
2011-01-08 01:49	Bruce	New Issue
2011-01-08 01:49	Bruce	Git Revision	=> 81587466e72cfb989c0cb3fa74ae5ff6e7f861bb
2011-01-08 01:49	Bruce	SVN Revision	=> r/14750
2011-01-08 01:49	Bruce	Run Mode	=> Standalone (Multiple Regions)
2011-01-08 01:49	Bruce	Physics Engine	=> ODE
2011-01-08 01:49	Bruce	Environment	=> .NET / Windows32
2011-01-08 01:49	Bruce	Mono Version	=> None
2011-01-08 01:49	Bruce	Viewer	=> Imprudence 1.3.0
2011-01-08 02:32	samiam	Note Added: 0017803
2011-01-08 02:39	samiam	Note Edited: 0017803
2011-01-08 02:58	samiam	Note Added: 0017804
2011-01-08 15:47	Bruce	Note Added: 0017805
2011-01-08 17:15	samiam	Note Added: 0017806
2011-01-08 17:32	samiam	Note Added: 0017807
2011-01-08 18:20	samiam	Note Added: 0017808
2011-01-08 19:07	samiam	Note Added: 0017809
2011-01-08 22:01	samiam	Note Added: 0017811
2011-01-11 13:18	Bruce	Note Added: 0017819
2011-01-11 13:19	Bruce	Status	new => resolved
2011-01-11 13:19	Bruce	Resolution	open => fixed
2011-01-11 13:19	Bruce	Assigned To	=> Bruce
2011-05-07 01:52	chi11ken	Status	resolved => closed

Relationships