This is very experimental feature so it might not be fully implemented. We will look at it.

Ok, thanks.

In the meantime, I can see a "last_logout" field in table tig_users. How can I use that?

Daniele Ricci wrote:

In the meantime, I can see a "last_logout" field in table tig_users. How can I use that?

This field (along with the status field) is not reliable as sometimes users can't be disconnected abruptly without performing proper logout.

I did some tests and checked that the field is correctly updated when the connection is reset (e.g. kill -9 on the client process). I guess it's unreliable when the socket is broken (e.g. not yet closed), but I guess that is perfectly normal (the server will realize later).

Can you confirm?

If the connection is broken but the server thinks the connection is OK, then it still considers the user as online. Eventually it will discover broken connection and will mark the user as offline and update the database counter. Also, even when a user disconnects without performing a proper logout the field is correctly updated.

However, the database field is unreliable source of information for other reasons. First, when you kill, shutdown or restart the server, field in the database for all users is not reset and the server cannot do it for many reasons:

1. Clustered environment - some servers are up with connected users, so it cannot reset counter for all users.

2. Reseting the field for "own users - only users connected to this server" during shutdown time is not recommended as users can have multiple connections and even if not, it could take unreasonable long time to update database for potentially 300k users connected to the server. And it still does not solve the problem when the server is simply killed, machine restarted or unlikely crash.

3. Reseting the field at startup time is also not reasonable, consider database with 10M or more user accounts. A startup time would be unreasonable long in such a case.

For these reasons, I suggest not to use the last_logout and other similar fields in the user's database.

I think a better approach is to make sure the last-seen feature is working correctly as it would be much more reliable.

Wojciech, do you need feedback from me?

No, it was marked as feedback from Artur to you.

mixed up with the previous update.

Daniele Ricci wrote:

I don't know if this can considered a bug, but I see that last-seen roster element attribute updated only on initial presence stanzas, and not on user disconnection. I use the last-seen attribute as a "last connection" indicator, is that right?

OK, I've modified the logic so roster's last-seen will be updated even on unavailable presence.

Thanks! I'll try it as soon as I can.

I realized the last-seen value in the roster wasn't enough: it reflects the last seen timestamp from the user's point of view, not the absolute time the user was connected to the server (which would be last_logout in tig_users in this case).

I've implemented a custom roster implementation for this here:

https://github.com/kontalk/tigase-extension/commit/e9e49e011f98a2c177b7d81977eeb5efc0df13db

But I'm afraid its performance impact would be huge: a query would be made for every unavailable user in the roster. Can I make use of some of the Tigase API to improve this? Something like a single SQL query for all unavailable users in the roster to retrieve all last_logout values at once?

Never mind: I ended up writing a last activity plugin (XEP-0012) backed by tig_users.last_logout, which is much more efficient because clients have to request that manually.

Indeed, last activity plugin is very costly to implement on the server side and it may impact the server overall performance if it is used extensively by users. This is why we still do not have finished our implementation. A correct way to do it, would be to have some kind of a cache for last activity for offline users to reduce number of DB calls.