kf6kjg
commented
5 years ago IIRC the loss of the multiple-regions-per-simulator feature was due to some detail involving PhysX and SQLite, though my memory is hazy at best on the subject.
So in theory, once the problem is identified, the feature could be brought back - or this feature of multiple regions on a simulator could be removed and the code drastically simplified.
Some benefits for multiple regions on a simulator: (again, this currently is broken and causes issues)
- Less resources required for clusters of light duty regions, e.g. ocean spaces.
- Allows having more than one region in standalone mode during the pre-gridmode testing phase for new users.
- Simpler code, leading to faster iteration on new features and bug fixes, and faster on-boarding of new developers. Though making the changes will likely introduce a ton of bugs on its own.
Some negatives for multiple regions on a simulator:
- If one region crashes, or needs a reboot, all regions on the same simulator also need to be taken down.
- Continued code complexity, but code complexity that we are all used to dealing with.
With the advent of droplets, and other cloud compute resources, the grid-level need for this could be nullified: dozens of instances can be configured to read most of the critical data from a single source. Likewise even a single server setup can be configured to share most all the static data and binaries.
In the past when I first set up my world on the InWorldz code before it became Halcyon, I had one simulator instance opened and several regions running in it. I had mistakenly assumed that was the normal way of operating the world based on OpenSim Standalone mode. Later, a change made after Halcyon was released, prevented the multiple regions per simulator. It was also noted that if any region in the simulator crashed, it would bring down all the regions in that simulator. A case that would not be good for a live world.
This issue is specifically aimed at the case where the code is structured to support the multiple regions in the simulator instance. I propose that that option be removed from Halcyon and it be officially no longer an option; one simulator instance per region only be supported. The benefit will be a clear configuration control process where the simulator instance is synonymous with a single region. Console commands for that instance would only apply to the single region by the relationship of one simulator per region. This association would also have a direct impact on the saveexplicit oar console command, rendering the region identity redundant and the entire command essentially identical to the save oar command.
Halcyon currently will not allow multiple regions in a simulator based on the way it maintains a regions persistence data and maybe some other features. Perhaps the code can be optimized as a result of there only being one region to process and keep track of, making even better performance.