Project

General

Profile

Task #6234

Avatar?id=6023&size=22x22

Print "Tigase cache turned off" only once

Added by Wojciech Kapcia TigaseTeam over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Database:
n/a

Description

Whether cache should be enabled or not is controlled globally and when enabling clustering it's by default disabled (and we no default to cluster mode even with single node...) which results in dozen entries WARNING: Tigase cache turned off. which may give wrong impression.

Associated revisions

Revision 913474cb (diff)
Added by Wojciech Kapcia TigaseTeam over 1 year ago

#6234 Print "Tigase cache turned off" only once

Revision 8f140a63 (diff)
Added by Wojciech Kapcia TigaseTeam over 1 year ago

#6234 Print "Tigase cache turned off" only once

History

#1 Updated by Wojciech Kapcia TigaseTeam over 1 year ago

  • Status changed from New to Resolved
  • Assignee changed from Wojciech Kapcia to Artur Hefczyc
  • % Done changed from 0 to 100

I've made the change but actually, the problem is a little bit more convoluted. The basic idea was that SimpleCache used for repository in cluster mode would cause problems (data inconsistency in the repository). After looking at the usages I've noticed that there are some parts of the code that may still may benefit from using SimpleCache (DNSResolver*) or they simply reference it without actually doing much with it (@tigase.component.adhoc.AdHocCommandManager#process()@ -- %bmalkow - could you expound on the use of SimpleCache and AdHocSession there?).

As for repositories -- except for JDBC repository Cache is not used.

The time parameter seems to also be ignored...

We could:

  • remove SimpleCache from JDBCRepository and remove the constrains that would disable it in cluster mode;

  • remove SimpleCache altogether;

  • improve SimpleCache (time based items removal, remove disabling when clustering with documenting that it may yield wrong results while using with repositories).

#2 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam over 1 year ago

  • Status changed from Resolved to Closed

Wojciech Kapcia wrote:

  • improve SimpleCache (time based items removal, remove disabling when clustering with documenting that it may yield wrong results while using with repositories).

I am in favor of going this route. I think we should seek performance improvements and optimizations. Using some sort of cache, even in clustered env is very much desired. Maybe not on the DB level but maybe on application level (PubSub, MUC, etc....). That is on the components level which are aware of clustered env and can automatically invalidate cache in case of some changes in other cluster nodes.

My assumption is that for the most part we do reading from DB and then the cache might be very useful. When we do writing in DB we could send a message through the cluster to empty cache. This is not super optimal but could still provide improvements.

For sure, this needs more research and work to make it usable in clustered env.

#3 Updated by Wojciech Kapcia TigaseTeam over 1 year ago

Artur Hefczyc wrote:

Wojciech Kapcia wrote:

  • improve SimpleCache (time based items removal, remove disabling when clustering with documenting that it may yield wrong results while using with repositories).

I am in favor of going this route. I think we should seek performance improvements and optimizations. Using some sort of cache, even in clustered env is very much desired. Maybe not on the DB level but maybe on application level (PubSub, MUC, etc....). That is on the components level which are aware of clustered env and can automatically invalidate cache in case of some changes in other cluster nodes.

My assumption is that for the most part we do reading from DB and then the cache might be very useful. When we do writing in DB we could send a message through the cluster to empty cache. This is not super optimal but could still provide improvements.

For sure, this needs more research and work to make it usable in clustered env.

AFAIR PubSub (and possibly MUC) are already using caching (and there is cache hit-miss ration in statistics) but this is probably done by just using a collection (map?) -- %andrzej.wojcik ?

#4 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam over 1 year ago

%wojtek MUC and PubSub are using custom caches adjusted to them. They are based on a Map and List to make sure that access is concurrent and fast and we will invalidate older entries. Moreover, clustering strategies are taking care of notifying other nodes about items to invalidate in case, and in some cases provide other nodes with new values to use as in some cases it was far better (faster) than rereading data from the database.

Also available in: Atom PDF