|Anonymous | Login | Signup for a new account||2013-12-13 20:24 UTC|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005317||opensim||[REGION] OpenSim Core||public||2011-01-08 01:49||2011-05-07 01:52|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0005317: Flotsam asset cache error|
|Description||[FLOTSAM ASSET CACHE]: System.IO.IOException: Cannot create a file when that file alread|
[FLOTSAM ASSET CACHE]:
[FLOTSAM ASSET CACHE]: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeF
[FLOTSAM ASSET CACHE]: at System.IO.__Error.WinIOError()
[FLOTSAM ASSET CACHE]: at System.IO.File.Move(String sourceFileName, String destFileN
[FLOTSAM ASSET CACHE]: at Flotsam.RegionModules.AssetCache.FlotsamAssetCache.WriteFil
eCache(String filename, AssetBase asset) in c:\Opensim\Program Files\Opensim\opensim-tree-ec83e9f\O
CacheDirectory = ./assetcache
LogLevel = 0
HitRateDisplay = 100
MemoryCacheEnabled = false
MemoryCacheTimeout = 2
FileCacheTimeout = 0
FileCleanupTimer = .166
|Tags||No tags attached.|
|Git Revision or version number||81587466e72cfb989c0cb3fa74ae5ff6e7f861bb|
|Run Mode||Standalone (Multiple Regions)|
|Environment||.NET / Windows32|
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.
|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.|
|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).|
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.
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.
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.
|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 :)|
@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.
|Problem solved, was hardware related. Thank you samiam for your inputs.|
|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|
|Copyright © 2000 - 2012 MantisBT Group|