Project

General

Profile

After the tigase server has been running for a while, users will not be able to receive notifications after creating a new group or inviting users to access an existing group.

liwen liu
Added 2 months ago

After the tigase server has been running for a while, creating a new group or inviting users to an existing group, the user is not able to receive notifications, which in turn poses a series of problems. This question makes me very anxious, I hope to get advice, thank you!


Replies (14)

Added by Wojciech Kapcia TigaseTeam 2 months ago

liwen liu wrote:

After the tigase server has been running for a while, creating a new group or inviting users to an existing group, the user is not able to receive notifications, which in turn poses a series of problems.

Does the server is operating normally (no exceptions or errors in the logs)?
Is the user still connected to the server and can receive other type of messages and chat with other users?

Please provide more information and step-by-step guide to reproduce the issue. We have installations with months/years uptime and we haven't experience similar issue.

Added by liwen liu 2 months ago

Yes the user can still connect to the server and can chat normally with other users but the notification of creating a group invitation user is not received properly. There have been similar problems, solved after restarting the server, but now it is useless to restart the server.
The server has exception information as follows:

tigase.xmpp.NotAuthorizedException: Session has not been yet authorised.
        at tigase.xmpp.XMPPResourceConnection.isUserId(XMPPResourceConnection.java:833)
        at tigase.shiku.ShikuOfflineMsgPlugin.process(ShikuOfflineMsgPlugin.java:137)
        at tigase.server.xmppsession.SessionManager$ProcessorWorkerThread.process(SessionManager.java:2782)
        at tigase.util.WorkerThread.run(WorkerThread.java:128)
tigase.xmpp.NotAuthorizedException: Session has not been yet authorised.
        at tigase.xmpp.XMPPResourceConnection.isUserId(XMPPResourceConnection.java:833)
        at tigase.shiku.ShikuOfflineMsgPlugin.process(ShikuOfflineMsgPlugin.java:137)
        at tigase.server.xmppsession.SessionManager$ProcessorWorkerThread.process(SessionManager.java:2782)
        at tigase.util.WorkerThread.run(WorkerThread.java:128)
...

 [IPMonitor Timer]  IPMonitor$1.run()                  WARNING:  Many disconnects for IP: xxxx
 [IPMonitor Timer]  IPMonitor$1.run()                  WARNING:  Many disconnects for IP: xxxx
 [IPMonitor Timer]  IPMonitor$1.run()                  WARNING:  Many disconnects for IP: xxxx

...

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam 2 months ago

It looks like one of your custom plugins is checking if XMPPResourceConnection is for the particular user (most likely comparing JID of the packet to or from attribute) by calling isUserId() method. However, in this case, the user (user session) is not authorized yet and this method throws an exception. If you want to allow processing packets when this happens you need to modify your plugin and catch this exception.

Added by 连生 张 about 2 months ago

Why can't I compile this version of tigase- HTTP - API? How do I compile and install it

tigase-http-api
2.0.0-SNAPSHOT
bundle

error

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project tigase-http-api: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed: Plugin org.apache.maven.plugins:maven-compiler-plugin:3.8.0 or one of its dependencies could not be resolved: The following artifacts could not be resolved: org.codehaus.plexus:plexus-container-default:jar:1.7.1, org.apache.xbean:xbean-reflect:jar:3.7: Could not transfer artifact org.codehaus.plexus:plexus-container-default:jar:1.7.1 from/to vr9mall-maven (http://111.202.41.112:8081/repository/maven-public/): Connect to 111.202.41.112:8081 [/111.202.41.112] failed: Connection timed out: connect -> [Help 1]

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam about 2 months ago

What server is running at 111.202.41.112 at port 8081? I do not recall any of our (Tigase) server running at this address and port. Most likely you have some maven repository caching server configured which is not responding on your requests.

Added by liwen liu about 2 months ago

Thank you for your answer. Actually the exception information I mentioned above actually I feel that it is irrelevant to the question I am asking.My question is actually After the tigase server has been running for a while, creating a new group or inviting users to an existing group, the user is not able to receive notifications, which in turn poses a series of problems. The console does not have a related log. Now it has been restarted again. The reason is still not found and may be reproduced in the future.

Added by Wojciech Kapcia TigaseTeam about 2 months ago

As explained by Andrzej a couple of day ago:

It looks like one of your custom plugins is checking if XMPPResourceConnection is for the particular user (most likely comparing JID of the packet to or from attribute) by calling isUserId() method. However, in this case, the user (user session) is not authorized yet and this method throws an exception. If you want to allow processing packets when this happens you need to modify your plugin and catch this exception.

Please make sure you are not blocking packets.

It also looks that you are breaking client connections causing many disconnects - please make sure that your client is connected and can communicate with the server without problem.

Added by liwen liu about 2 months ago

What I can confirm is that when I have the above situation the user's private chat is normal only the group notification will be problematic.

Added by liwen liu about 2 months ago

That is do you think that many ips have disconnected because the user session has not been authorized?Is this correct?

Added by Wojciech Kapcia TigaseTeam about 2 months ago

liwen liu wrote:

What I can confirm is that when I have the above situation the user's private chat is normal only the group notification will be problematic.

Do you have other exceptions? Maybe in MUC components? Have you tried tracking packet processing after the issue happens with debugging enabled? Have you checked the statistics (especially of the MUC component) and verified that the packets are processed correctly and no queues are rising?

liwen liu wrote:

That is do you think that many ips have disconnected because the user session has not been authorized?Is this correct?

It's one of the possibilities. From the above log entries it's difficult to say more than - there is a surge in disconnects and Tigase reports it - it may be due to lack of authentication (you can check server statistics) or network problems.

Added by liwen liu about 2 months ago

Thank you! I originally thought this was a possibility but because there are too few error logs that can be quoted I am not sure about this guess but I will listen to your suggestions. At the same time I would like to ask where I can view the server statistics information?

Added by Wojciech Kapcia TigaseTeam about 2 months ago

liwen liu wrote:

Thank you! I originally thought this was a possibility but because there are too few error logs that can be quoted I am not sure about this guess but I will listen to your suggestions.

You can find more information about logs in Debuging Tigase

At the same time I would like to ask where I can view the server statistics information?

Please read up Server Monitoring - it gives you all information how to setup gathering of statistics and retrieve them later on.

Added by 连生 张 about 1 month ago

I use Psi or Spark sent to destroy of nodes in the chat room can normal execution and destroy the chat room, but I sent via http://localhost:8080/rest/stream/ the same node cannot destroy chat why?How do I do that?

Macbeth doth come.

http.png (32.7 KB) http.png

Added by Wojciech Kapcia TigaseTeam about 1 month ago

Can you try including xmlns="jabber:client" in the <iq/>?
You should enable debug of the server and verify that the packet is correctly delivered.

    (1-14/14)