Sending direct presence and message to same user with different resource does not work! (#218)

Closed

	Steffen Larsen opened 1 decade ago I am trying to send from the same user with one resource to anohter resource. That is: sending a message stanza from test2@test.dk/Phone to test2@test.dk/Web. This have worked before when using tigase 5.1 (using 5.2 now), so I wonder what have changed?. Of course it could be AMP or Message module that have changed, but I really cant see it. Here are the stanzas (from test2@test.dk/Phone client): @ jkhjkhk jkhjkhk The recipient is no longer available. @ My init.prop (sm-plugins) looks like this: Ive tried using both AMP and message as sm-plugins.
	Steffen Larsen commented 1 decade ago It seems to come from the tigase.xmpp.impl.Message.java class around line 181 (from master branch). Apparently conns (connected resources) are less than zero. Strange.
	Steffen Larsen commented 1 decade ago Hi again, This issue is quite critical. Do you guys need some help or are you on it?
	Artur Hefczyc commented 1 decade ago I am sorry it's taking so long on our side. We are quite busy working through a queue of tasks and projects. If you can provide any help it would certainly speed up resolving it.
	wojciech.kapcia@tigase.net commented 1 decade ago Hi, I've run some tests on the latest version from repository and I wasn't able to replicate the issue, the log: Psi+/1, incomming presence after second resource logs in `<presence from="tigase1@firefly/Psi+/2" to="tigase1@firefly"> <priority>50</priority> <c xmlns="http://jabber.org/protocol/caps" node="http://psi-dev.googlecode.com/caps" ver="0.16" ext="ca cv e-time ep-notify-2 last-act sxe whiteboard"/> </presence>` Psi+/1, outgoing message to second resource `<message type="chat" to="tigase1@firefly/Psi+/2" id="ab20a"> <subject>test</subject> <body>test</body> </message>` Psi+/2, incomming message from anotherresource `<message from="tigase1@firefly/Psi+/1" type="chat" id="ab20a" to="tigase1@firefly/Psi+/2"> <subject>test</subject> <body>test</body> </message>` Psi+/2, outgoing message to another resource `<message type="chat" id="msg2" to="tigase1@firefly/Psi+/1"> <subject>test2</subject> <body>test2</body> </message>` Psi+/1, incomming message from second resource `<message from="tigase1@firefly/Psi+/2" type="chat" to="tigase1@firefly/Psi+/1" id="msg2"> <subject>test2</subject> <body>test2</body> </message>` I've run the test on both AMP and message plugins. Could you provide exact version/revision which manifested the issue? Could you provide your `init.properties` (you mention it in the ticket but it's missing)
	Steffen Larsen commented 1 decade ago Hi, Yes of course. I'll provide it tomorrow. The tigase-server version is latest 5.2. But I check exact number. Is there a way to check the version number of the war file?
	wojciech.kapcia@tigase.net commented 1 decade ago Thanks. `war` file? How come you have such type of file? Neverhteless - it should be available in the manifest file inside war/jar
	Steffen Larsen commented 1 decade ago ohh sorry, lost in java translation! :-) of course I meant the jar file. I'll check the manifest and give feedback tomorrow.
	Steffen Larsen commented 1 decade ago As you can see from the image, a user (admin@yousee.dk) is connected twice. One with resource zool and the other with Psi. Sending a message fails. Version: 5.1.4 (in cluster mode) Init.properties: @config-type=--gen-config-def --admins=admin@p-xmpp01.xxx.idk, admin@xxx.dk --virt-hosts = xxx.dk --debug=server --user-db=mysql --user-db-uri=jdbc:mysql://localhost:3306/tigase?user=root&password=xxx --cluster-mode=true --cluster-nodes=p-xmpp01.xxx.idk,p-xmpp02.xxx.idk@ I've also tried it without the clusering enabled. And that actually made it work. So the problem does not lay in the versions of the tigase server, but more in the routing when clustering is enabled. :-( It actually also works in version 5.2.0 - beta3. Which I have tested here: Version: 5.2.0-beta3 (b3269) (stand alone mode). Init.properties: @config-type = --gen-config-def --virt-hosts = yousee.dk --cluster-mode = false --debug = server --user-db = mysql --admins = test2@yousee.dk --user-db-uri = jdbc:mysql://localhost/tigasedb?user=tigase&password=adminadmin@
	Artur Hefczyc commented 1 decade ago I am afraid this is a known problem with clustering on version 5.1.x. This has been fixed in the last 5.2.0 version.
	Artur Hefczyc commented 1 decade ago Ups, I am sorry, I misread the original post. I am taking back what I said :-) please ignore my post. The problem may happen in a clustering mode as it is not well tested yet. Thank you for reporting it. This helps us with our tests. We will look at the problem during our tests. Could you please, just tell me what clustering mode you had enabled while experiencing the problem? Was it using ACS component or default clustering?
	Steffen Larsen commented 1 decade ago Hey Artur! I am using the default cluster strategy. Maybe I should try out my scenario for 5.2.0-beta3 as well?. Will ACS work for 5.1.4? because I would very much like to try it out. Beside this message problem when in cluster mode, I am sometimes having trouble with login due to resource conflict, even though I am using different resources for my clients. Have you experienced this before? It only happens in cluster mode. -Cheers! /Steffen
	Artur Hefczyc commented 1 decade ago There is a different version of ACS for 5.1.4 although the ACS included in the 5.2.0 Beta3 should work with 5.1.4. As for the resource conflict, there were problems like this but they were fixed in subsequent versions. Hard to tell about your case though without investigation.
	wojciech.kapcia@tigase.net commented 1 decade ago Tested with latest version with and w/o ACS hence it just struck me that this might be related to the changes in delivery logic (see linked changeset and tickets)
	Artur Hefczyc commented 1 decade ago Wojciech, I suppose you confirm that this happened during your tests as well?
	wojciech.kapcia@tigase.net commented 1 decade ago yes, issue is reproducible in the cluster environment with both available strategies.
	Steffen Larsen commented 1 decade ago So to summarize: the direct presence, sending messages to the same user with different resource, does not work in any clustered scenario (default strategy or ACS) ? and not in 5.1.x or in 5.2? .Cheers! /Steffen
	Steffen Larsen commented 1 decade ago Any news in this issue?
	Artur Hefczyc commented 1 decade ago Yes, I have news. I am working on the issue right now. I have covered this case in our cluster automated tests and I can replicate and confirm this is really a problem. I am working on a fix. I expect to have it fixed today or tomorrow.
	Steffen Larsen commented 1 decade ago Super cool Artur!. I believe that it will be both on the 5.1.x and 5.2.x branch? Just say when it can be tested, I have a full testbed here as well. :-)
	Artur Hefczyc commented 1 decade ago I am working on 5.2.0 release right now, so for sure it will work on this version. 5.1.0 may be fixed as well depending how much work it needs.
	Steffen Larsen commented 1 decade ago Hi Artur, I can only see a few changes that might have something to do with this issue on master. I can see some NPE fixed on https://projects.tigase.org/projects/tigase-server/repository/revisions/f65f1d25375e055d886ee15866bdcc374b56d20e - but I am not sure that this is related to this issue here. :-) I there is a fix on master, then let me know so I can test it. :-) Cheers and thanks Artur! /Steffen
	Artur Hefczyc commented 1 decade ago The fixes were done in SessionManager, thats for sure. They could be accompanied by some code changes in connection managers as well. So you should really start investigation from SM changes tracking. I am very sorry I cannot provide you with more details. Unfortunately these were kind of fast/hot fixes without a ticket report attached to code changes. So I do not even remember when exactly they were made. Andrzej was the developer who was making the fixes. Let's ask him where to look and when this could be done. Andrzej: could you please provide any details if you have them?
	Artur Hefczyc commented 1 decade ago Ups sorry everybody. I am responding to so many queries and some of them are very similar, so I messed this up. Again! Please forget my previous comment. Stephen the cluster fix is not available in repository yet. I am still working on it. Instead of a quick dirty fix I found a way to do it in a better way, more reliable but it needs some work, therefore it will take me a few more days. I am sorry for keeping you waiting.
	Steffen Larsen commented 1 decade ago Hi Artur, Thats ok. Just ping me via. IM or mail, when there is a fix on master. I'll synch my source and test it straight after that. /Steffen
	Artur Hefczyc commented 1 decade ago Andrzej, you have made some fixes in this part of the code recently. Could you please confirm that the issue is fixed?
	Andrzej Wójcik (Tigase) commented 1 decade ago I made a fix in delivery of presence stanzas to other resources of same user and it is fixed now, so delivery of direct presence to other resources works fine. As for delivery of messages to other resources on diffrent nodes, there is still an issue there which needs to be fixed.
	Steffen Larsen commented 1 decade ago OK cool. So it means that direct messages to full JID now works on single instances of Tigase, but not in a cluster?
	Andrzej Wójcik (Tigase) commented 1 decade ago Applied in changeset tigase-server\|commit:c86055dfb29cd582b7b698d2ae8db658ffe64538. I applied a fix for delivery of messages sent to resources connected to other cluster nodes.
	Steffen Larsen commented 1 decade ago Super!. I am looking forward to try out the fix. Will try it tomorrow or the following days. Thanks!

Type	Bug
Priority	Major
Assignee	Andrzej Wójcik (Tigase)
RedmineID	1480
Version	tigase-server-5.2.0

#67 Closed

Revisit how the server handles stanzas to bareJID
#122 Closed

Stanza sent to full jid delivered to more than 1 connected resource
#671 Closed

Duplication of message in offline store when Message and OfflineMessages processors are used

Issue Votes (0)

Watchers (0)

Reference

tigase/_server/server-core#218