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

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

Closed

Activities

	Andrzej Wójcik (Tigase) opened 6 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
	Andrzej Wójcik (Tigase) commented 6 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.net commented 6 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.net commented 6 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.net commented 6 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 6 years ago I've made requested changes.
	wojciech.kapcia@tigase.net commented 6 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 6 years ago I've fixed reported issues.
	wojciech.kapcia@tigase.net commented 6 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 6 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.net commented 6 years ago Now it works correctly.

Type	Bug
Priority	Normal
Assignee	wojciech.kapcia@tigase.net
RedmineID	8143
Version	tigase-server-8.0.0
Spent time	129h

Child Issue

Parent Issue

#962

RepoItems handling changes

Issue Votes (0)

Watchers (0)

Reference

tigase/_server/server-core#972

Please wait...

Page is in error, reload to recover