Cannot configure ComponentProtocol repository items in `component` mode (#972)

Andrzej Wójcik (Tigase) opened 7 years ago

After removing the configuration of repository items from the config file, it is no longer possible to configure ComponentProtocol repository items when Tigase is running in the component mode.

To fix this issue it is required to:

modify repository item configuration layer to separate items of the Tigase running in server mode from items of Tigase running in the component mode
create new bean/component to allow management of the component repository items of the Tigase running in the component mode from the Tigase running in the server mode
reimport data from the config file to make sure that it is properly separated

Parent Issue
- RepoItems handling changes (#962) Closed

Activities

Andrzej Wójcik (Tigase) commented 7 years ago

I think this task is done. Documentation was updated in a separate task and those changes are covered by tests in TTS-NG.

Wojciech Kapcia (Tigase) commented 7 years ago

Configuration UI is ok (I would add dropdown for Protocol field as we have finite set of options).

~~However, I ran into an issue:~~ * configure fist instance to listen for connections (using xep-0114), afterwards tigase started listening * bring up second instance (a bit of a twist - I set it up with same repository but I also added http-api on separate port) * configure external instance with appropriate details, confirm.~~

~~Soon afterwards (couple of seconds) I ended up with hundreds of established connections:~~

java    48852 wojtek  212u  IPv6 0x66f17e31bbc741b3      0t0  TCP 192.168.1.17:58848->192.168.1.17:5301 (ESTABLISHED)
java    48852 wojtek  213u  IPv6 0x66f17e31bbc74d33      0t0  TCP 192.168.1.17:58849->192.168.1.17:5301 (ESTABLISHED)
wojtek@atlantiscity.local ~/dev $ sudo lsof -iTCP:5301 -sTCP:ESTABLISHED -P -n | grep java | wc -l
     182
wojtek@atlantiscity.local ~/dev $ sudo lsof -iTCP:5301 -sTCP:ESTABLISHED -P -n | grep java | wc -l
     226
wojtek@atlantiscity.local ~/dev $ sudo lsof -iTCP:5301 -sTCP:ESTABLISHED -P -n | grep java | wc -l
     254
wojtek@atlantiscity.local ~/dev $ sudo lsof -iTCP:5301 -sTCP:ESTABLISHED -P -n | grep java | wc -l
     284
wojtek@atlantiscity.local ~/dev $ sudo lsof -iTCP:5301 -sTCP:ESTABLISHED -P -n | grep java | wc -l
     312
wojtek@atlantiscity.local ~/dev $ sudo lsof -iTCP:5301 -sTCP:ESTABLISHED -P -n | grep java | wc -l
     354
wojtek@atlantiscity.local ~/dev $ sudo lsof -iTCP:5301 -sTCP:ESTABLISHED -P -n | grep java | wc -l
     384
wojtek@atlantiscity.local ~/dev $ sudo lsof -iTCP:5301 -sTCP:ESTABLISHED -P -n | grep java | wc -l
     381
wojtek@atlantiscity.local ~/dev $ sudo lsof -iTCP:5301 -sTCP:ESTABLISHED -P -n | grep java | wc -l
     542
wojtek@atlantiscity.local ~/dev $ sudo lsof -iTCP:5301 -sTCP:ESTABLISHED -P -n | grep java | wc -l
    1022

~~All those were connections between two instances (see PID):~~

java    48524 wojtek  421u  IPv6 0x66f17e31bbc73bf3      0t0  TCP 192.168.1.17:5301->192.168.1.17:58847 (ESTABLISHED)
java    48524 wojtek  422u  IPv6 0x66f17e31bbc74773      0t0  TCP 192.168.1.17:5301->192.168.1.17:58848 (ESTABLISHED)
java    48852 wojtek  142u  IPv6 0x66f17e31bbc19633      0t0  TCP 192.168.1.17:58804->192.168.1.17:5301 (ESTABLISHED)
java    48852 wojtek  143u  IPv6 0x66f17e31bbc1c9f3      0t0  TCP 192.168.1.17:58805->192.168.1.17:5301 (ESTABLISHED)

~~It seems that the second instance was trying to connect to itself for some reason (?):~~

2018-09-17 17:16:22.574 [ConnectionOpenThread]  ConnectionManager.reconnectService()  FINER: Reconnecting service for: ext, scheduling next try in 2secs, cid: null@null, props: {remote-host=atlantiscity.local, repo-item=muc.atlantiscity:pass:connect:5301:atlantiscity.local:connect:tigase.server.ext.lb.ReceiverBareJidLB, port-no=5301, local-host=muc.atlantiscity, ifc=[Ljava.lang.String;@5983f899, max-reconnects=7199985, socket=plain, type=connect, hostname-key=atlantiscity.local}
2018-09-17 17:16:22.574 [ConnectionOpenThread]  ConnectionManager$ConnectionListenerImpl.accept()  FINEST: Accept called for service: null@null, port_props: {remote-host=atlantiscity.local, repo-item=muc.atlantiscity:pass:connect:5301:atlantiscity.local:connect:tigase.server.ext.lb.ReceiverBareJidLB, port-no=5301, local-host=muc.atlantiscity, ifc=[Ljava.lang.String;@12a83b6f, max-reconnects=7199974, socket=plain, type=connect, hostname-key=atlantiscity.local}
2018-09-17 17:16:22.574 [ConnectionOpenThread]  ConnectionManager.serviceStarted()  FINER:   [[ext]] Connection started: null, type: connect, Socket: nullSocket[addr=atlantiscity.local/192.168.1.17,port=5301,localport=61036], jid: null
2018-09-17 17:16:22.574 [ConnectionOpenThread]  ComponentProtocol.serviceStarted()  FINEST:  Connection started: 192.168.1.17, xmlns: jabber:component:connect, type: connect, id=192.168.1.17_61036_192.168.1.17_5301
2018-09-17 17:16:22.574 [ConnectionOpenThread]  ComponentProtocol.serviceStarted()  FINEST:  cid: null, sending: null, sessionData: {remote-host=atlantiscity.local, repo-item=muc.atlantiscity:pass:connect:5301:atlantiscity.local:connect:tigase.server.ext.lb.ReceiverBareJidLB, port-no=5301, local-host=muc.atlantiscity, ifc=[Ljava.lang.String;@12a83b6f, max-reconnects=7199974, socket=plain, type=connect, hostname-key=atlantiscity.local}
2018-09-17 17:16:22.574 [ConnectionOpenThread]  ConnectionManager$ConnectionListenerImpl.accept()  FINEST: Problem reconnecting the service: null, type: connect, Socket: nullSocket[addr=atlantiscity.local/192.168.1.17,port=5301,localport=61036], jid: null, port_props: {remote-host=atlantiscity.local, repo-item=muc.atlantiscity:pass:connect:5301:atlantiscity.local:connect:tigase.server.ext.lb.ReceiverBareJidLB, port-no=5301, local-host=muc.atlantiscity, ifc=[Ljava.lang.String;@12a83b6f, max-reconnects=7199974, socket=plain, type=connect, hostname-key=atlantiscity.local}, exception: java.lang.UnsupportedOperationException: Not supported yet.
2018-09-17 17:16:22.575 [ConnectionOpenThread]  ConnectionManager.reconnectService()  FINER: Reconnecting service for: ext, scheduling next try in 2secs, cid: null@null, props: {remote-host=atlantiscity.local, repo-item=muc.atlantiscity:pass:connect:5301:atlantiscity.local:connect:tigase.server.ext.lb.ReceiverBareJidLB, port-no=5301, local-host=muc.atlantiscity, ifc=[Ljava.lang.String;@12a83b6f, max-reconnects=7199973, socket=plain, type=connect, hostname-key=atlantiscity.local}
2018-09-17 17:16:22.575 [ConnectionOpenThread]  ConnectionManager$ConnectionListenerImpl.accept()  FINEST: Accept called for service: null@null, port_props: {remote-host=atlantiscity.local, repo-item=muc.atlantiscity:pass:connect:5301:atlantiscity.local:connect:tigase.server.ext.lb.ReceiverBareJidLB, port-no=5301, local-host=muc.atlantiscity, ifc=[Ljava.lang.String;@12a83b6f, max-reconnects=7199974, socket=plain, type=connect, hostname-key=atlantiscity.local}
2018-09-17 17:16:22.575 [ConnectionOpenThread]  ConnectionManager.serviceStarted()  FINER:   [[ext]] Connection started: null, type: connect, Socket: nullSocket[addr=atlantiscity.local/192.168.1.17,port=5301,localport=61046], jid: null
2018-09-17 17:16:22.575 [ConnectionOpenThread]  ComponentProtocol.serviceStarted()  FINEST:  Connection started: 192.168.1.17, xmlns: jabber:component:connect, type: connect, id=192.168.1.17_61046_192.168.1.17_5301
2018-09-17 17:16:22.575 [ConnectionOpenThread]  ComponentProtocol.serviceStarted()  FINEST:  cid: null, sending: null, sessionData: {remote-host=atlantiscity.local, repo-item=muc.atlantiscity:pass:connect:5301:atlantiscity.local:connect:tigase.server.ext.lb.ReceiverBareJidLB, port-no=5301, local-host=muc.atlantiscity, ifc=[Ljava.lang.String;@12a83b6f, max-reconnects=7199974, socket=plain, type=connect, hostname-key=atlantiscity.local}

main tigase server configuration: https://www.dropbox.com/s/z4hq3x9s3npjuq7/tigase_main.png?dl=0
external tigase server configuration: https://www.dropbox.com/s/0m8hnoge7rlwwpt/tigase_ext.png?dl=0

Separate issue - after shutting down Tigase and making sure it's down and nothing is listening on configured port, after subsequent start I get exception:

2018-09-17 17:38:47.011 [ConnectionOpenThread]  ConnectionOpenThread.addAllWaiting()  WARNING: Error: creating connection for: {port-no=5301, local-host=muc.atlantiscity, remote-host=null, hostname-key=null, type=accept, socket=plain, ifc=[Ljava.lang.String;@3a5c6009, max-reconnects=7200000, repo-item=muc.atlantiscity:pass:accept:5301:null:accept:tigase.server.ext.lb.ReceiverBareJidLB}
java.net.BindException: Address already in use
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at tigase.net.ConnectionOpenThread.addISA(ConnectionOpenThread.java:270)
	at tigase.net.ConnectionOpenThread.addPort(ConnectionOpenThread.java:303)
	at tigase.net.ConnectionOpenThread.addAllWaiting(ConnectionOpenThread.java:243)
	at tigase.net.ConnectionOpenThread.run(ConnectionOpenThread.java:212)
	at java.lang.Thread.run(Thread.java:748)

Tigase correctly listens on this port so it looks like it's try second time to bind the port?

Wojciech Kapcia (Tigase) commented 7 years ago
OK, first issue stemmed from wrong configuration of external instance (using "connect" with connect protocol). However:

we should add some delay between attempting connection failed;

selecting wrong protocol should not result in connecting instance to itself

IMHO protocol should be optional (or we could use some sane default) - previously on the listening end protocol was optional and on the connecting end we had simpler choice boiling down to actual protocol we want to use:

You don’t have to specify a protocol if you setup a connection in 'listen' mode as the server automatically detects a protocol which is used in incoming connections. You can specify the protocol which is used for outgoing connections but you have to add one more parameters to the connection string. There are two possibilities:

'accept' which is an identifier for protocol defined in XEP-0114 (and is default if you do not specify anything)

'client' which is identifier for protocol defined in XEP-0225 and is based on the client-to-server protocol.
Wojciech Kapcia (Tigase) commented 7 years ago
After short chat:

add support for <desc/> element in Data forms and include there explanation about possible options for connection type and protocol (see #7924#note-8)

include validation of ext-comp CompRepoItem (e.g. so it won't be possible to select incorrect protocol for selected connection type)
Andrzej Wójcik (Tigase) commented 7 years ago

I've made requested changes.

Wojciech Kapcia (Tigase) commented 7 years ago

After adding an item (with listen) and then restarting the instance there is an BindException (reproducible: always)

2018-10-04 22:04:32.550 [ConnectionOpenThread]  ConnectionOpenThread.addAllWaiting()  WARNING: Error: creating connection for: {port-no=5300, local-host=muc.atlantiscity, remote-host=null, hostname-key=null, type=accept, socket=plain, ifc=[Ljava.lang.String;@26c986f0, max-reconnects=7200000, repo-item=muc.atlantiscity:pass:accept:5300:null:null:tigase.server.ext.lb.ReceiverBareJidLB}
java.net.BindException: Address already in use
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at tigase.net.ConnectionOpenThread.addISA(ConnectionOpenThread.java:270)
	at tigase.net.ConnectionOpenThread.addPort(ConnectionOpenThread.java:303)
	at tigase.net.ConnectionOpenThread.addAllWaiting(ConnectionOpenThread.java:243)
	at tigase.net.ConnectionOpenThread.run(ConnectionOpenThread.java:212)
	at java.lang.Thread.run(Thread.java:748)

I think this is most likely related to another issue: when removing RepoItem configuration the connection is not stopped. So most likely, during startup RepoItem is reloaded but because previous socket is not closed we endup with BindException.

Andrzej Wójcik (Tigase) commented 7 years ago

I've fixed reported issues.
Wojciech Kapcia (Tigase) commented 7 years ago

I just tested and removing an Item from the external-component (the one that connects to the main server) machine doesn't stop established connection. On main machine, removing RepoItem correctly stops listening on configured port.
Andrzej Wójcik (Tigase) commented 7 years ago
From what I've found out there was a couple of issues:

UserRepository during reload was not removing entries which were gone from the database.

ComponentProtocol was not closing active connections when there were removed (only stopped reconnecting or stopped accepting connections).

Both of those issues are now fixed and I've checked to confirm that I was able to make modifications and they were applied.

As for the change in UserRepository, it may also have an impact on VHostManager as it is based on this class, however from what I've checked all was working well.
Wojciech Kapcia (Tigase) commented 7 years ago

Now it works correctly.
Login to comment

Type	Bug
Priority	Normal
Assignee	Wojciech Kapcia (Tigase)
RedmineID	8143
Version	tigase-server-8.0.0
Spent time	0

Issue Votes (0)

Watchers (0)

Reference

tigase/_server/server-core#972