Project

General

Profile

S2S - Incorrect destinationaddress issue when trying to use MUC as the Virtual Component

Igor Khomenko
Added over 4 years ago

Hi there,

we are trying to setup a chat cluster with 2 nodes and MUC as the Virtual Component

Here are configs on each node:

Node1:

--virt-hosts = chat.domain.com

--cluster-mode=true

--comp-name-2=muc
--comp-class-2=tigase.muc.MUCComponent
...

Node2:

--virt-hosts = chat.domain.com

--cluster-mode=true

--comp-name-2=muc
--comp-class-2=tigase.cluster.VirtualComponent

muc/redirect-to=muc@qb-qa-1
muc/disco-name=multi-user-chat
muc/disco-node=
muc/disco-type=text
muc/disco-category=conference
muc/disco-features=http://jabber.org/protocol/muc
...

Here is what the hostname command prints on each server:

Node1: qb-qa-1

Node2: qb-qa-2

We checked the cluster-nodes table in DB - it contains 2 rows with these hostnames, so everything looks correct

We also use AWS Load Balancer - it contains these 2 nodes.

When a user connects to chat - the load balancer forwards this connection to one of the nodes.

With the 1st node MUC works great - user can interact with it.

With the 2nd node user gets an error: S2S - Incorrect destinationaddress - one of local virtual hosts or components. when trying to interact with MUC

We send this request:

<iq type="get" to="muc.chat.domain.com" id="561002909"><query xmlns="http://jabber.org/protocol/disco#items"></query></iq>

We are stuck with this issue.

We did a quick investigation where this error happens.

First of all, above IQ packet goes to the VirtualComponent class, method processPacket*. Looks like this method works correct - it sets *qb-qa-1 to the packetTo property

if (redirectTo != null) {
    packet.setPacketTo(redirectTo);
    results.add(packet);
}

Next, above error happens inside class S2SConnectionManager, method processPacket.

I actually don't understand why here the to_hostname is formed in next way:

String to_hostname = packet.getStanzaTo().getDomain();

bot not the getPacketTo which you set above.

Could you please clarify a bit what can be the cause of this issue


Replies (6)

Added by Wojciech Kapcia TigaseTeam over 4 years ago

Igor Khomenko wrote:

Here is what the hostname command prints on each server:

Node1: qb-qa-1

Node2: qb-qa-2

Can you share how acutaly Tigase instances identifies themselves (for example in logs/tigase-console.log you can get resolved hostname as well as list of all internal components addresses @ConfiguratorAbstract.setup() CONFIG: Component basic-conf defaults: {component-id=basic-conf@…@)

Added by Igor Khomenko over 4 years ago

I found this line, it looks like

ConfiguratorAbstract.setup() CONFIG: Component basic-conf defaults: {component-id=basic-conf@ip-xxx-xx-xx-xx.us-west-1.compute.internal)

here is actually what hostname -f prints

With this settings for muc/redirect-to=muc@ip-xxx-xx-xx-xx.us-west-1.compute.internal it works in the same way - error happens

Added by Wojciech Kapcia TigaseTeam over 4 years ago

Igor Khomenko wrote:

here is actually what hostname -f prints

And this is correct - as per clustering documentation Tigase requires usage of FQDNs (well, it's possible to use any names, but you have to make sure all names are matched exactly!).

Here is what the hostname command prints on each server:

Node1: qb-qa-1

Node2: qb-qa-2

We checked the cluster-nodes table in DB - it contains 2 rows with these hostnames, so everything looks correct

With the above in mind I would say, that in such case clustering should not be working for you at all (if you have hostnames like ip-xxx-xx-xx-xx.us-west-1.compute.internal and you have different entries in cluster-nodes table.

Added by Igor Khomenko over 4 years ago

Wojciech, yes , you are right

I have checked again this table, here is what we have there

+--------------------------------------------+------------------------------------------------------------------+---------------------+------+-----------+-----------+
| hostname                                   | password                                                         | last_update         | port | cpu_usage | mem_usage |
+--------------------------------------------+------------------------------------------------------------------+---------------------+------+-----------+-----------+
| ip-xxx-xx-xx-xx.us-west-1.compute.internal | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 2014-12-03 11:23:53 | 5277 |       0.2 | 1.6918751 |
| ip-xx-xx-xx-xx.us-west-1.compute.internal | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 2014-12-03 11:23:58 | 5277 | 0.2527167 | 1.4692177 |
+--------------------------------------------+------------------------------------------------------------------+---------------------+------+-----------+-----------+

so, everything is ok and I can confirm that Chat cluster works ok

Added by Igor Khomenko over 4 years ago

Do you have any ideas where could be the issue?

Added by Wojciech Kapcia TigaseTeam over 4 years ago

Please make sure, that on node2 you have correct address of node1 (FQDN) and that the redirect packet is correctly addressed (packet-to, after VirtualComponent) to the address of node1. If that's correct please track the packet through router manager.

    (1-6/6)