|Anonymous | Login | Signup for a new account||2021-01-25 05:50 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008259||opensim||[GRID] Robust Server||public||2017-10-31 19:40||2019-05-11 20:02|
|Platform||Windows Server 2013||Operating System||Opensim & Robust||Operating System Version||8.2.1|
|Target Version||Fixed in Version|
|Summary||0008259: Presence in Robust|
|Description||In this case I used 8.2.1 Release but I saw the same results on other versions like 0.9.0. If a Users logs on, there will be an UUID in the table Presence, however if the user logs off there is still an UUID in the table Presence, as result you will see users online 1, while the user is offline.|
|Steps To Reproduce||Its a random situation, in fact just logon your grid and do what you have to do or logon your grid and logoff in both scenarios keep an eye that it says you are logged off if not open the DB from Robust and check the table Presence, if it shows an off line UUID you have reproduce it|
|Additional Information||Maybe a function what returns with an true or false, if Frank Orbis logs in the UUID will be shown in Presence, if Frank Orbis logs off we need to pass that to that function logoffcheck(UUID) : Boolean; what this function does is it will look at Presence and waits a certain delay is needed, lets say 10 seconds. If the UUID is still there after 10 seconds or longer logoffcheck(UUID) will return FALSE that needs to be passed to a DB eraser, well in this case if Frank did logoff but after X seconds Frans is still in the table presence we will forced remove that UUID, logoff completed is TRUE something like that.|
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||Mono / Windows|
|This has been an issue for quite some time actually. Generally the regionhandle for these presences seems to be null, but this also happens sometimes in transit so it cannot be simply cleared based on that factor alone.|
Confirmed on OpenSim Master
Presence table is not being cleaned of users that crash or logout the normal way.
i see user removed from presence table on normal logouts
crash my fail to do it
8.2.1 is dead code as far as the developers are concerned, AFAIK there is no intention to work or patch 8.2.1 from core.
Maybe a third party could do it for you, or you could upgrade ...
paela argus (reporter)
I will correct this for you, can you send your e-mail please in private message.
I'll do it when I have 5 minutes in the week or the next
edited on: 2019-03-24 00:46
Xantis, there is no easy/clean way to inform the robust server that the user "crashed", (they do seem to be removed correctly on a logout), could just be bad network connections, over zealous cleaning of the presence table will create a whole host of other issues, seen it first hand ..
But for people who are bothered by it can simply create a sql query that clears users where their current region is a null UUID ..
this merge is more 3 years old now, and most people who put their misconceptions aside, find that 9x does perform a lot better, things change and they move forward.
The people who have issues with 9x in general simply refuse to do anything different or new, and want to stay stuck in the past.
Talk all you want to whoever you want, we are NOT SL, we have hypergrid and a hundred other things to deal with that their walled garden does not have to deal with, they also get PAYED to fix things.
have fun ....
@Xantis what you describe is a simple php query that you can cron your database for, that is how most deal with this. Yes it would be nice if robust did this itself, but there are some considerations to make in regards to edge cases with HG and the like, not to mention that robust is a bit of a mess anyways and touching it means descending down into a rabbit hole.
This mantis is set to confirmed because eventually this is something robust should be doing on its own, feel free to submit a patch though if you have solved this in robust.
paela argus (reporter)
|Linden Lab has exactly the same problem and I do not see how Linden lab could help in a bug that they've ever been able to fix it too!|
paela argus (reporter)
Moreover on secondlife, it is about the proxy which manages the connections of the users etc.
Secondlife has nothing to do with OpenSim.
I really do not see how an employee of linden lab can help you by showing you how is structured their proxy squid!
|@Xantis no this is why this is set to confirmed in the first place. However working around this issue for the time being is not exactly difficult and the same operations may very well find their way into robust at some point. For the moment there is not much interest to touch robust code as there are a lot of other considerations to be made regarding the state of it anyways. Robust is a dumb service, it has almost no self-awareness and that goes for many of its capabilities. There are some other mantis tickets regarding that fact and they eventually all need addressing, but it almost constitutes a complete rewrite at this point so that seems to be what is planned more than just fiddling with individual services.|
edited on: 2019-03-27 07:14
@all case suspended even after it has been confirmed.
@paela argus, I want to thank you for sending me the correction! as you said "I will correct this for you, can you send your e-mail please in private message.
I'll do it when I have 5 minutes in the week or the next" and that I did, sending you my email. then you said, "Linden Lab has exactly the same problem" do they? Then login at Second Life and disconnect (do not log out) but just unplug your internet lets say, create a crash then login directly again and you'll see a window popup what tells you "You can nog login, the logout process is still in progress, you can log in at date, time" in meantime they clean your UUID. does that not sound the same?
|2017-10-31 19:40||Xantis||New Issue|
|2017-11-01 08:16||tampa||Note Added: 0032388|
|2018-08-24 12:33||Fly-Man-||Note Added: 0032878|
|2018-08-24 12:33||Fly-Man-||Status||new => confirmed|
|2018-08-25 18:26||UbitUmarov||Note Added: 0032884|
|2019-02-25 03:46||Xantis||Note Added: 0034846|
|2019-02-27 00:05||BillBlight||Note Added: 0034871|
|2019-02-27 01:41||paela argus||Note Added: 0034874|
|2019-03-23 05:27||Xantis||Note Added: 0034956|
|2019-03-23 05:28||Xantis||Note Edited: 0034956||View Revisions|
|2019-03-23 05:28||Xantis||Note View State: 0034956: private|
|2019-03-24 00:09||Xantis||Note Deleted: 0034956|
|2019-03-24 00:37||Xantis||Note Added: 0034971|
|2019-03-24 00:42||BillBlight||Note Added: 0034972|
|2019-03-24 00:46||BillBlight||Note Edited: 0034972||View Revisions|
|2019-03-24 11:14||Xantis||Note Added: 0034976|
|2019-03-24 11:48||BillBlight||Note Added: 0034977|
|2019-03-24 13:41||tampa||Note Added: 0034978|
|2019-03-24 13:47||paela argus||Note Added: 0034979|
|2019-03-24 13:50||paela argus||Note Added: 0034980|
|2019-03-25 01:24||BillBlight||Note Added: 0034985|
|2019-03-25 01:24||BillBlight||Note Deleted: 0034985|
|2019-03-25 04:58||Xantis||Note Added: 0034988|
|2019-03-25 05:16||Xantis||Note Added: 0034989|
|2019-03-25 05:20||Xantis||Note Added: 0034990|
|2019-03-26 04:30||Xantis||Note Added: 0034991|
|2019-03-26 10:04||tampa||Note Added: 0034993|
|2019-03-27 07:03||Xantis||Note Deleted: 0034846|
|2019-03-27 07:03||Xantis||Note Deleted: 0034971|
|2019-03-27 07:03||Xantis||Note Deleted: 0034976|
|2019-03-27 07:03||Xantis||Note Deleted: 0034988|
|2019-03-27 07:03||Xantis||Note Deleted: 0034989|
|2019-03-27 07:04||Xantis||Note Deleted: 0034990|
|2019-03-27 07:04||Xantis||Note Deleted: 0034991|
|2019-03-27 07:07||Xantis||Note Added: 0034994|
|2019-03-27 07:11||Xantis||Priority||normal => high|
|2019-03-27 07:11||Xantis||Severity||minor => major|
|2019-03-27 07:11||Xantis||Resolution||open => suspended|
|2019-03-27 07:14||Xantis||Note Edited: 0034994||View Revisions|
|2019-05-11 20:02||Xantis||Note Added: 0035195|
|Copyright © 2000 - 2012 MantisBT Group|