tarber.net

The coding is complete and we’ve produced a small number of OAR files for export from InWorldz. In some cases the intended destination is a Sim-on-a-stick personally installation or a grid running OpenSim. While the new OAR files have been updated to be recognized and supported by OpenSim, there is some data within the OAR file that will only be useful to Halcyon regions. These are assets which may not be in an XML format.

Problem: Back in July of 2015, Kitely’s technical lead (Oren) submitted some changes to OpenSim to actually dump any non-XML assets to the region console. This means that if you attempt to load a Halcyon OAR file under OpenSim, the console will stream thousands of lines of jibberish data. Because the data is known to not be valid XML in this case, it may include content that could cause the region to freeze or hang, but in the best case scenario it will simply spew thousands of lines of error messages for much of the oar load. These errors are false-positives (and will hide any legitimate errors).

Solution: You should ignore these errors and let it finish.

That’s all, just wait for it to finish. Then log in and visually verify that it has seemed to successfully load the OAR contents.

For those who build their own OpenSim executables:

For those who build their own, I suggest the following changes to mute the very noisy error handling:
In SceneObjectSerializer.cs, change the first catch (in FromOriginalXmlFormat) to:

catch (Exception e)
{
    m_log.Warn("[SERIALIZER]: Deserialization of xml failed: " + e.Message);
    // Util.LogFailedXML("[SERIALIZER]:", fixedData);
    return null;
}

In CoalescedSceneObjectsSerializer.cs, change the last catch (in TryFromXml near the end of the file) to:

catch (Exception e)
{
    m_log.Warn("[COALESCED SCENE OBJECTS SERIALIZER]: Deserialization of xml failed: " +  e.Message);
    // Util.LogFailedXML("[COALESCED SCENE OBJECTS SERIALIZER]:", xml);
    return false;
}

Both of these change the message to a warning, don’t bother reporting a stack traceback (since this can only happen from one place) and most importantly, completely eliminate the dumping of the invalid data to the console. This will still produce a noisy (3-lines per case) log, but OpenSim seems very verbose in logging, and this is considerably quieter than it is otherwise and won’t make you think something is horribly wrong when all is working according to plan.

I took a quick look at submitting this as a patch to OpenSim but first I must make it clear that I am not going to make it my mission to fix OpenSim issues. I have submitted fixes in the past directly to Justin, and I considered submitting this one using their patch process, but realized that there are a variety of development philosophies and I don’t know OpenSim’s. e.g. whether OpenSim has OAR debugging levels that the XML dump could be conditional upon, or whether I should remove that commented out line (or leave it for developers debugging issues), etc. Bottom line, I don’t know what to submit as a patch. I do know how to change the code to avoid this issue so I have posted that above. Since the key fix is a simple commenting out of a line, I’ll leave it to others to decide how much or how little they want to include from these trivial code changes.