Project

General

Profile

Access data repository in tigase plugin

Pankaj Sharma
Added over 3 years ago

Hi,

We have a situation in application where we might want to block certain messages and handle them differently based upon certain criteria.

I guess the best way to block the messages and route them to an alternate business logic would be inside Session Manager's plugin by implementing XMPPProcessorIfc interface. Please suggest if you see a better way.

Whether the packet should be blocked or not can be decided after looking inside application database. As per my understanding the best way to access database is by using DataRepository which can be created by calling RepositoryFactory.getDataRepository(). Because of my failure to find any substantial knowledge about these APIs this question arose:

  • We have done custom implementation for AuthRepository, inside which we create another DataRepository using RepositoryFactory.getDataRepository() with the --auth-db-uri and authenticate against hashed passwords. Is there a better way to handle this?

  • This custom dataRepo will be same database as the application Authentication database(configured using --auth-db-uri), so does this means it would be the same instance used for both authentication and custom usage inside plugin?

  • If question to above question is yes, Then what is the best way i can independently configure separate pools for authentication and plugin?

  • Are there any consequences i should be aware of when I access dataRepository inside a plugin(e.g. adverse effect of database latency) upon functioning of Tigase? If Yes what is best way to avoid them?

  • Is there any way to configure caching in the dataRepository?

Thanks in advance,


Replies (1)

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam over 3 years ago

Hi,

Here are answers for your questions:

We have done custom implementation for AuthRepository, inside which we create another DataRepository using RepositoryFactory.getDataRepository() with the --auth-db-uri and authenticate against hashed passwords. Is there a better way to handle this?

Our implementation of AuthRepository in fact uses internally othter implementation (implementation of UserRepository) but as you want to access other database I think that usage of DataRepository in this case is best way to do this.

This custom dataRepo will be same database as the application Authentication database(configured using --auth-db-uri), so does this means it would be the same instance used for both authentication and custom usage inside plugin?

If in both cases you create DataRepository of same class and that use same JDBC URI then Tigase XMPP Server (RepositoryFactory) will create single instance of this implementation of DataRepository.

If question to above question is yes, Then what is the best way i can independently configure separate pools for authentication and plugin?

You can create 2 separate custom classes implementing DataRepository (or extending it, ie. AuthDataRepository extends DataRepository and CustomDataRepository extends DataRepository) and use them where needed (this can be good to separate DB logic from logic of your processors as you would have your own subclasses to which you could cast DataRepository after retrieving from Repository factory).

Other solution would be to use 2 different JDBC URIs - ie. one with additional parameter which would be skipped by database.

Are there any consequences i should be aware of when I access dataRepository inside a plugin(e.g. adverse effect of database latency) upon functioning of Tigase? If Yes what is best way to avoid them?

Each request to processor which accesses database will be delayed by time needed to retrieve data from database - which under load may (and probably will) cause performance issues including delay in message delivery and high memory usage to queue packets waiting to be processed. I would consider increased number of processing threads.

However please note that by packets which should be processed by 2 processors then they are scheduled to be processed by 2 separate threads (not one processor and then next one). To properly implement blocking I would suggest to look into our implementation of privacy lists (see https://projects.tigase.org/projects/tigase-server/repository/revisions/master/entry/src/main/java/tigase/xmpp/impl/JabberIqPrivacy.java which implements blocking).

For sure I would suggest to keep read data on which you decided how to handle message cached in memory using XMPPResourceConnection instance and map returned by it's method getSessionData() to store loaded data until user is connected (XMPP connection is active).

Is there any way to configure caching in the dataRepository?

No, there is no cache. But you can add it creating custom implementation or extending DataRepository implementation.

    (1-1/1)