| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the status of the region using the region http uri just passed in
* If the status cannot be retrieved, then the region startup will terminate.
* The aim of this is for earlier detection of situations where the region can send messages out but cannot accept incoming requests (often due to firewall issues)
* This is currently an extremely simplistic check which completely trusts whatever http uri is given by the region
* This contact may be problematic, though since the user service needs to be able to contact the region http uri, it doesn't seem unreasonable for the grid to have to be able to do so too at this stage
* This change will require a prebuild
|
|
|
|
|
|
|
| |
* This in preparation for further login validation to check that the region logging in is properly contactable.
* Also increase verbosity of some error messages
|
|
|
|
| |
instead
|
|
|
|
| |
startup will now terminate instead of carrying on (and thus burying the error message)
|
| |
|
|
|
|
| |
dispatch for now
|
| |
|
|
|
|
|
|
|
|
| |
yet received data from the inventory service
* Replaced instead with the system now used by other requests where the fetch request is placed on a queue and service when the data comes in
|
| |
|
| |
|
|
|
|
|
| |
* Added shell of new Python scripting engine. Similar in design to the one used by Rex, but will be structured at a region rather than object level, also is a region module.
|
|
|
|
|
|
|
|
| |
where appropriate
* This also means that the command quit (as well as shutdown) will now close down grid servers (instead of only being in place for the region server)
|
| |
|
|
|
|
| |
won't be useful until we let the client cache (again?)
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
CachedUserInfo
* Remove unused/superseded methods from GridInventoryService
|
|
|
|
|
|
|
| |
just ignore this for now, but it lets us get connect strings to sqlite
and nhibernate.
|
|
|
|
|
|
|
|
| |
almost every inventory method
* This allows lots of redundant inventory methods with only slightly different names to be eliminated.
|
| |
|
| |
|
|
|
|
|
| |
* Made a bunch more members static, removed some dead code, general cleaning.
|
|
|
|
| |
with namespaces.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Thanks A_Biondi and Melanie!
* This builds but might not work. JustinCC will examine.. it may work out of the box.
|
|
|
|
|
|
|
|
|
| |
* Now, emptying the trash should remove folders and the items they contain as well as items which were not in a subfolder.
* This will only work once both the region and grid servers have reached this revision.
* You may also need to clear your cache before this will work
* Refactoring to follow.
|
|
|
|
|
|
|
|
|
| |
which will let you specify a connection string. Required
for Nhibernate, optional for sqlite (there is a sane default),
ignored for mysql and mssql until someone implements the
Iniatialise(string) method.
|
|
|
|
|
|
|
|
| |
configs. This works with sqlite and nhibernate backends, and
stays with default seperate ini files for mysql and mssql until
someone writes those.
|
|
|
|
|
|
|
| |
* On standalone, folders (and their items) should now be persistently deleted on trash emptying, as well as immediate child items
* An implementation for grid mode will follow.
|
|
|
|
|
|
|
|
|
| |
received by a region from the inventory service
* This replaces the old behaviour of failing straight away, which could cause lost updates if the inventory service was slow in responding
* This is the first baby step to making all inventory requests behave this way, to reduce inventory lossage
|
|
|
|
| |
(this took a while to run).
|
|
|
|
| |
skeleton has been successfully created.
|
|
|
|
|
|
|
| |
* A much more significant fix is required to clean up the cache when a user moves out of a region, but really better handling of delayed inventory cache updates needs to be
written first, and possibly better affinity to cut down agent inventory requests when the move is between two regions hosted on the same server.
|
|
|
|
|
|
|
|
| |
console from sync to async
* Catch more error conditions and provide more messages when things go wrong
|
|
|
|
|
|
|
|
| |
than async.
* Add more error checking so that we don't proceed if there has been a problem with inventory retrieval
|
|
|
|
|
|
|
|
| |
empty response to a whole agent inventory request, then post an inventory login failure message.
IMO, this is better than allowing the agent to login with an apparantly blank inventory.
|
|
|
|
| |
handled by the base http server
|
|
|
|
|
|
|
| |
* Implements 'Teleport Home'
* User Server has to be updated for it to save your home in grid mode
* home position accuracy is in int because the grid comms ExpectUser method tries to convert to Uint and crashes if it gets a float. Added a convert to decimal in ExpectUser but to avoid a breaking change with old revisions, kept the save value in int for now. Eventually it needs to be a float, but lets release another incremental version before doing that.
|
| |
|
|
|
|
| |
up log messages
|
|
|
|
| |
if a login fails because the inventory service has failed.
|
|
|
|
|
|
|
|
| |
when they were.
* A few things for testing.
* This makes a modification to the region registration with the grid server so that the region can send it a chosen password to identify itself. It will not cause any errors, if either one are not updated.
|
|
|
|
|
|
|
|
|
| |
duplicate sets of inventory data to be sent over the grid
* Won't actually fix anything, since we were handling the problem anyway
* Also add more doc, fix up debugging messages, etc
|
|
|
|
|
|
|
|
| |
at once, rather than each individual
* This is required in order to work towards eliminating some inventory race conditions and to better deal with situations where a grid inventory server is slow or not responding.
|
|
|
|
|
| |
:: Believe it or not, but INSERT/UPDATE is actually a better pattern than REPLACE, since, with INSERT/UPDATE you can catch erroneous UPDATES to non-INSERTed items as well as catch erroneous re-INSERTS. in 95% of the cases, you SHOULD have a clear INSERT context, and a clear and separate UPDATE context. If you think your case falls within the 5%, maybe you should re-evaluate your code. ::
|
|
|
|
| |
Preparation for handling inventory problems where the inventory server receives a request and never responds, or is late in responding
|
| |
|