nharward / commons-j Goto Github PK

When shutting down, only subscribed client channels are closed currently. There could be a condition where a client recently connected but has not yet subscribed to any channels, if the shutdown happened at this time then the channel would not be closed and the server shutdown sequence will hang.

Looks like some of the handlers do not properly close channels when they are disconnected - this is left to the parent class which does not appear to do it. After reviewing the Netty internals looks like a few handler methods here need to be augmented to properly close all channels - in particular during the disconnect event.

Calling get() on the returned Future from PubSubClient does not wait for the actual future to complete, instead returns false if called immediately after publishing.

5603 [New I/O client worker #6-2] DEBUG us.harward.commons.net.pubsub.RoundRobinReconnectHandler - Established connection to server localhost/127.0.0.1:9002
5603 [Hashed wheel timer #7] DEBUG us.harward.commons.net.pubsub.RoundRobinReconnectHandler - Have available servers[[localhost/127.0.0.1:9003]], calling connect() with localhost/127.0.0.1:9003
5604 [New I/O server worker #3-4] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Server received message: SubscriptionMessage{type=Subscription, ttl=2, source UUID=8ec18bdc-7a8f-4b58-9529-21e983eaba36, server UUID=00000000-0000-0000-0000-000000000000, body length=32}
5604 [New I/O server worker #3-4] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Dropped TTL: SubscriptionMessage{type=Subscription, ttl=1, source UUID=8ec18bdc-7a8f-4b58-9529-21e983eaba36, server UUID=00000000-0000-0000-0000-000000000000, body length=32}
5609 [New I/O client worker #7-2] DEBUG us.harward.commons.net.pubsub.RoundRobinReconnectHandler - Established connection to server localhost/127.0.0.1:9003
5610 [New I/O server worker #4-3] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Server received message: SubscriptionMessage{type=Subscription, ttl=2, source UUID=1ca9a58e-1f20-4471-9c45-190ee1dfe979, server UUID=00000000-0000-0000-0000-000000000000, body length=32}
5610 [New I/O server worker #4-3] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Dropped TTL: SubscriptionMessage{type=Subscription, ttl=1, source UUID=1ca9a58e-1f20-4471-9c45-190ee1dfe979, server UUID=00000000-0000-0000-0000-000000000000, body length=32}
5624 [Hashed wheel timer #11] DEBUG us.harward.commons.net.pubsub.RoundRobinReconnectHandler - Have available servers[[localhost/127.0.0.1:9003]], calling connect() with localhost/127.0.0.1:9003
5629 [New I/O client worker #11-2] DEBUG us.harward.commons.net.pubsub.RoundRobinReconnectHandler - Established connection to server localhost/127.0.0.1:9003
5631 [New I/O server worker #4-4] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Server received message: SubscriptionMessage{type=Subscription, ttl=2, source UUID=1ce7dcad-0740-4d0d-8b79-491563580c78, server UUID=00000000-0000-0000-0000-000000000000, body length=32}
5631 [New I/O server worker #4-4] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Dropped TTL: SubscriptionMessage{type=Subscription, ttl=1, source UUID=1ce7dcad-0740-4d0d-8b79-491563580c78, server UUID=00000000-0000-0000-0000-000000000000, body length=32}
PSCacheS has 30 entries.
10749 [New I/O server worker #1-1] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Server received message: ApplicationMessage{type=Application, ttl=2, source UUID=80b7f701-35ad-4913-b070-b2046f99c058, server UUID=00000000-0000-0000-0000-000000000000, body length=21}
10750 [New I/O server worker #1-1] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Dropped TTL: ApplicationMessage{type=Application, ttl=1, source UUID=80b7f701-35ad-4913-b070-b2046f99c058, server UUID=00000000-0000-0000-0000-000000000000, body length=21}
10750 [New I/O server worker #1-1] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Server received message: ApplicationMessage{type=Application, ttl=2, source UUID=80b7f701-35ad-4913-b070-b2046f99c058, server UUID=00000000-0000-0000-0000-000000000000, body length=21}
10750 [New I/O client worker #9-1] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Server received message: ApplicationMessage{type=Application, ttl=1, source UUID=80b7f701-35ad-4913-b070-b2046f99c058, server UUID=fa725965-addf-4cb1-9f5c-697d3d85b8f4, body length=21}
10751 [New I/O server worker #1-1] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Dropped TTL: ApplicationMessage{type=Application, ttl=1, source UUID=80b7f701-35ad-4913-b070-b2046f99c058, server UUID=00000000-0000-0000-0000-000000000000, body length=21}
10751 [New I/O client worker #9-1] DEBUG us.harward.commons.net.pubsub.ServerMessageHandler - Dropped TTL: ApplicationMessage{type=Application, ttl=0, source UUID=80b7f701-35ad-4913-b070-b2046f99c058, server UUID=fa725965-addf-4cb1-9f5c-697d3d85b8f4, body length=21}

If a server is given its own listening address as a remote server, it should ignore it (and log it with a warning). I don't know what will happen in such a case, but I doubt it will be good. Better to just not do it.

In all our local environments it is occupied by jenkins, so unit tests with default port will fail

Currently space after comma is appended to server name, resulting to incorrect server name and subsequent connection errors

See http://stackoverflow.com/questions/4332264/wrapping-a-bytebuffer-with-an-inputstream for details.