Using SipJs 0.17.1 and freeswitch 1.10.5. Debian 10. stun:stun.l.google.com:19302
<param name="apply-candidate-acl" value="wan.auto"/>
If users using any home or office internet and when receive a call, audio appears in ~ 0.2 seconds.
9bd6fc2d-fe49-4a05-8a43-b400e4ce3565 2021-01-16 21:39:29.103910 [NOTICE] switch_rtp.c:4952 Activating RTP audio ICE: UpI7:gafAlEO8WSw1T9B3 109.201.xxx.xxx:9646
9bd6fc2d-fe49-4a05-8a43-b400e4ce3565 2021-01-16 21:39:29.103910 [INFO] switch_core_media.c:8896 Skipping RTCP ICE (Same as RTP)
9bd6fc2d-fe49-4a05-8a43-b400e4ce3565 2021-01-16 21:39:29.103910 [INFO] switch_rtp.c:3764 Activate RTP/RTCP audio DTLS client
9bd6fc2d-fe49-4a05-8a43-b400e4ce3565 2021-01-16 21:39:29.103910 [INFO] switch_rtp.c:3927 Changing audio DTLS state from OFF to HANDSHAKE
9bd6fc2d-fe49-4a05-8a43-b400e4ce3565 2021-01-16 21:39:29.243916 [INFO] switch_rtp.c:3282 Changing audio DTLS state from HANDSHAKE to SETUP
9bd6fc2d-fe49-4a05-8a43-b400e4ce3565 2021-01-16 21:39:29.263910 [INFO] switch_rtp.c:3189 audio Fingerprint Verified.
9bd6fc2d-fe49-4a05-8a43-b400e4ce3565 2021-01-16 21:39:29.263910 [INFO] switch_rtp.c:4254 Activating audio Secure RTP SEND
9bd6fc2d-fe49-4a05-8a43-b400e4ce3565 2021-01-16 21:39:29.263910 [INFO] switch_rtp.c:4232 Activating audio Secure RTP RECV
9bd6fc2d-fe49-4a05-8a43-b400e4ce3565 2021-01-16 21:39:29.263910 [INFO] switch_rtp.c:3231 Changing audio DTLS state from SETUP to READY
But when users using mobile internet and when receive a call, audio appears in ~ 1.5 seconds (subjectively longer).
7518c5c2-a045-4535-9630-97a20c4cd980 2021-01-16 23:37:40.003922 [NOTICE] switch_rtp.c:4952 Activating RTP audio ICE: rzCc:NJN0su78A6fbnv6q 89.42.xxx.xxx:45466
7518c5c2-a045-4535-9630-97a20c4cd980 2021-01-16 23:37:40.003922 [INFO] switch_core_media.c:8896 Skipping RTCP ICE (Same as RTP)
7518c5c2-a045-4535-9630-97a20c4cd980 2021-01-16 23:37:40.003922 [INFO] switch_rtp.c:3764 Activate RTP/RTCP audio DTLS client
7518c5c2-a045-4535-9630-97a20c4cd980 2021-01-16 23:37:40.003922 [INFO] switch_rtp.c:3927 Changing audio DTLS state from OFF to HANDSHAKE
7518c5c2-a045-4535-9630-97a20c4cd980 2021-01-16 23:37:41.243907 [NOTICE] switch_rtp.c:1301 Auto Changing audio stun/rtp/dtls port from 89.42.xxx.xxx:45466 to 89.42.xxx.xxx:63930 idx:1
7518c5c2-a045-4535-9630-97a20c4cd980 2021-01-16 23:37:41.403925 [INFO] switch_rtp.c:3282 Changing audio DTLS state from HANDSHAKE to SETUP
7518c5c2-a045-4535-9630-97a20c4cd980 2021-01-16 23:37:41.423918 [INFO] switch_rtp.c:3189 audio Fingerprint Verified.
7518c5c2-a045-4535-9630-97a20c4cd980 2021-01-16 23:37:41.423918 [INFO] switch_rtp.c:4254 Activating audio Secure RTP SEND
7518c5c2-a045-4535-9630-97a20c4cd980 2021-01-16 23:37:41.423918 [INFO] switch_rtp.c:4232 Activating audio Secure RTP RECV
7518c5c2-a045-4535-9630-97a20c4cd980 2021-01-16 23:37:41.423918 [INFO] switch_rtp.c:3231 Changing audio DTLS state from SETUP to READY
Why does the line appear Auto Changing audio stun/rtp/dtls ?
What makes ports change?
How to avoid time-consuming port switching?
Connection establishment in WebRTC uses a protocol called ICE (https://www.rfc-editor.org/rfc/rfc8445). ICE first tries to establish a direct connection between the peers, and only after this fails falls back to using a TURN relay.
In your case, it is highly likely that the direct connection is successful from your office network, but that the mobile client requires the use of a TURN server, which only happens after a timeout. If you know that a TURN server will be required, you may avoid the timeout by specifying {iceTransportPolicy: 'relay'} when you establish the peer connection.
Related
I'm trying to run Redis data set on Jmeter. I'm using VPN and bypass to proxy. I'm writing to log down side.
In HTTP Request part I wrote to adress and I'm trying to go amazon webservis adress. I was able to ran different test successfully before applying redis. Now trying with Redis. I couldn't find how to pass this error.
I found some SSL certificate know how on internet. So mostly tell install sertificate in chrome or firefox
Thanks
Redis localhost settings
Bybass proxy
2022-03-23 09:58:11,976 INFO o.a.j.u.JsseSSLManager: Using default SSL protocol: TLS
2022-03-23 09:58:11,976 INFO o.a.j.u.JsseSSLManager: SSL session context: per-thread
2022-03-23 09:58:11,976 INFO o.a.j.u.SSLManager: JmeterKeyStore Location: type JKS
2022-03-23 09:58:11,976 INFO o.a.j.u.SSLManager: KeyStore created OK
2022-03-23 09:58:11,976 WARN o.a.j.u.SSLManager: Keystore file not found, loading empty keystore
2022-03-23 09:58:13,104 INFO o.a.j.g.a.Start: Stopping test
2022-03-23 09:58:13,120 INFO o.a.j.t.JMeterThread: Stopping: Thread Group 1-1
2022-03-23 09:58:13,120 WARN o.a.j.t.JMeterThread: Interrupting: Thread Group 1-1 sampler: HTTP Request
2022-03-23 09:58:13,120 INFO o.a.j.t.JMeterThread: Thread finished: Thread Group 1-1
2022-03-23 09:58:13,129 INFO o.a.j.e.StandardJMeterEngine: Notifying test listeners of end of test
2022-03-23 09:58:13,131 WARN r.c.j.JedisFactory: Error while close
redis.clients.jedis.exceptions.JedisException: Could not return the broken resource to the pool
at redis.clients.jedis.util.Pool.returnBrokenResourceObject(Pool.java:116) ~[jedis-3.6.3.jar:?]
at redis.clients.jedis.util.Pool.returnBrokenResource(Pool.java:98) ~[jedis-3.6.3.jar:?]
at redis.clients.jedis.JedisPool.returnResource(JedisPool.java:382) ~[jedis-3.6.3.jar:?]
at redis.clients.jedis.JedisPool.returnResource(JedisPool.java:15) ~[jedis-3.6.3.jar:?]
at redis.clients.jedis.Jedis.close(Jedis.java:3957) ~[jedis-3.6.3.jar:?]
at redis.clients.jedis.JedisFactory.destroyObject(JedisFactory.java:166) [jedis-3.6.3.jar:?]
at org.apache.commons.pool2.PooledObjectFactory.destroyObject(PooledObjectFactory.java:126) [commons-pool2-2.9.0.jar:2.9.0]
at org.apache.commons.pool2.impl.GenericObjectPool.destroy(GenericObjectPool.java:958) [commons-pool2-2.9.0.jar:2.9.0]
at org.apache.commons.pool2.impl.GenericObjectPool.clear(GenericObjectPool.java:677) [commons-pool2-2.9.0.jar:2.9.0]
at org.apache.commons.pool2.impl.GenericObjectPool.close(GenericObjectPool.java:721) [commons-pool2-2.9.0.jar:2.9.0]
at redis.clients.jedis.util.Pool.closeInternalPool(Pool.java:122) [jedis-3.6.3.jar:?]
at redis.clients.jedis.util.Pool.destroy(Pool.java:109) [jedis-3.6.3.jar:?]
at kg.apc.jmeter.config.redis.RedisDataSet.testEnded(RedisDataSet.java:200) [jmeter-plugins-redis-0.5.jar:?]
at kg.apc.jmeter.config.redis.RedisDataSet.testEnded(RedisDataSet.java:195) [jmeter-plugins-redis-0.5.jar:?]
at org.apache.jmeter.engine.StandardJMeterEngine.notifyTestListenersOfEnd(StandardJMeterEngine.java:218) [ApacheJMeter_core.jar:5.4.3]
at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.java:493) [ApacheJMeter_core.jar:5.4.3]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_275]
Caused by: java.lang.IllegalStateException: Invalidated object not currently part of this pool
at org.apache.commons.pool2.impl.GenericObjectPool.invalidateObject(GenericObjectPool.java:642) ~[commons-pool2-2.9.0.jar:2.9.0]
at org.apache.commons.pool2.impl.GenericObjectPool.invalidateObject(GenericObjectPool.java:620) ~[commons-pool2-2.9.0.jar:2.9.0]
at redis.clients.jedis.util.Pool.returnBrokenResourceObject(Pool.java:114) ~[jedis-3.6.3.jar:?]
... 16 more
2022-03-23 09:58:13,136 INFO o.a.j.g.u.JMeterMenuBar: setRunning(false, *local*)
I am implementing DTLS 1.2 protocol in C. While testing the client with openSSL, I observed that one of the frames sent by OpenSSL is not using the correct Dtls version (1.2) but an older version (1.0).
The client in C supports only DTLS1.2, and therefore reject the frame send by OpenSSL.
HelloClient sent by the C client:
Frame 2461: 109 bytes on wire (872 bits), 109 bytes captured (872 bits) on interface 0
Ethernet II, Src: Infineon_00:00:01 (00:03:19:00:00:01), Dst: Tp-LinkT_dc:4e:82 (50:3e:aa:dc:4e:82)
Internet Protocol Version 4, Src: 192.168.88.73, Dst: 192.168.88.77
User Datagram Protocol, Src Port: 50003, Dst Port: 60003
Datagram Transport Layer Security
DTLSv1.0 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: DTLS 1.2 (0xfefd)
Epoch: 0
Sequence Number: 0
Length: 54
Handshake Protocol: Client Hello
Response from OpenSSL server:
Frame 2464: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on interface 0
Ethernet II, Src: Tp-LinkT_dc:4e:82 (50:3e:aa:dc:4e:82), Dst: Infineon_00:00:01 (00:03:19:00:00:01)
Internet Protocol Version 4, Src: 192.168.88.77, Dst: 192.168.88.73
User Datagram Protocol, Src Port: 60003, Dst Port: 50003
Datagram Transport Layer Security
DTLSv1.0 Record Layer: Handshake Protocol: Hello Verify Request
Content Type: Handshake (22)
Version: DTLS 1.0 (0xfeff)
Epoch: 0
Sequence Number: 0
Length: 35
Handshake Protocol: Hello Verify Request
I force OpenSSL to use the version 1.2 of DTLS running the following command:
openssl.exe s_server -nocert -psk 01234567 -accept 443 -cipher PSK-AES128-GCM-SHA256 -dtls1_2
I saw in the RFC of TLS (https://www.rfc-editor.org/rfc/rfc5246#appendix-E)
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the ClientHello format
remains compatible, and the client supports the highest protocol
version available in the server.
Nothing is specified for HelloRequestVerify (rfc5246 or rfc6347), but does that means that any version between 1.0 and 1.2 should be accepted?
Or is that a bug in OpenSSL?
Note: If I continue the DTLS handshake, every further frame sent by OpenSSL are using the correct version of DTLS (1.2).
According RFC 6347, 4.2.1. Denial-of-Service Countermeasures
However, in order to avoid the requirement to do version negotiation
in the initial handshake, DTLS 1.2 server implementations SHOULD use
DTLS version 1.0 regardless of the version of TLS that is expected to
be negotiated.
(That section contains some more information on that usage.)
I'm using rabbitmq cluster in k8s which has only pure ipv6 address. inet return nxdomain error when parsing the k8s service name.
The paramter passed to erlang from rabbitmq is:
RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS="+A 128 -kernel inetrc '/etc/rabbitmq/erl_inetrc' -proto_dist inet6_tcp"
RABBITMQ_CTL_ERL_ARGS="-proto_dist inet6_tcp"
erl_inetrc: |-
{inet6, true}.
when rabbitmq using its plugin rabbit_peer_discovery_k8s to invoke k8s api:
2019-10-15 07:33:55.000 [info] <0.238.0> Peer discovery backend does not support locking, falling back to randomized delay
2019-10-15 07:33:55.000 [info] <0.238.0> Peer discovery backend rabbit_peer_discovery_k8s does not support registration, skipping randomized start
up delay.
2019-10-15 07:33:55.000 [debug] <0.238.0> GET https://kubernetes.default.svc.cluster.local:443/api/v1/namespaces/tazou/endpoints/zt4-crmq
2019-10-15 07:33:55.015 [debug] <0.238.0> Response: {error,{failed_connect,[{to_address,{"kubernetes.default.svc.cluster.local",443}},{inet,[inet]
,nxdomain}]}}
2019-10-15 07:33:55.015 [debug] <0.238.0> HTTP Error {failed_connect,[{to_address,{"kubernetes.default.svc.cluster.local",443}},{inet,[inet],nxdom
ain}]}
2019-10-15 07:33:55.015 [info] <0.238.0> Failed to get nodes from k8s - {failed_connect,[{to_address,{"kubernetes.default.svc.cluster.local",443}}
,
{inet,[inet],nxdomain}]}
2019-10-15 07:33:55.016 [error] <0.237.0> CRASH REPORT Process <0.237.0> with 0 neighbours exited with reason: no case clause matching {error,"{fa
iled_connect,[{to_address,{\"kubernetes.default.svc.cluster.local\",443}},\n {inet,[inet],nxdomain}]}"} in rabbit_mnesia:init_from
_config/0 line 167 in application_master:init/4 line 138
2019-10-15 07:33:55.016 [info] <0.43.0> Application rabbit exited with reason: no case clause matching {error,"{failed_connect,[{to_address,{\"kub
ernetes.default.svc.cluster.local\",443}},\n
in k8s console, the address could be resolved:
[rabbitmq]# nslookup -type=AAAA kubernetes.default.svc.cluster.local
Server: 2019:282:4000:2001::6
Address: 2019:282:4000:2001::6#53
kubernetes.default.svc.cluster.local has AAAA address fd01:abcd::1
the inet could return ipv6 address.
kubectl exec -ti zt4-crmq-0 rabbitmqctl eval 'inet:gethostbyname("kubernetes.default.svc.cluster.local").'
{ok,{hostent,"kubernetes.default.svc.cluster.local",[],inet6,16,
[{64769,43981,0,0,0,0,0,1}]}}
as I know, plugin call httpc:request to invoke k8s api. I don't know what's the gap between httpc:request and inet:gethostbyname. I also don't what's used by httpc:request to resolve the address of hostname.
I query for the rabbitmq plugin, It's said that rabbitmq plugin don't aware how erlang resovlve the address. https://github.com/rabbitmq/rabbitmq-peer-discovery-k8s/issues/55.
Anything else I could set for erl_inetrc so that erlang could resolve the ipv6 address? what did i miss to config? or how could i debug from erlang side? I'm new to erlang.
B.R,
Tao
Here's a interesting problem I started facing since migrating from Heroku to Google Container Engine:
Since moving to GCE, after a few hours after server start/restart/deploy, out of nowhere, my Elixir application can't deliver push notifications to APNS any longer. I'm using the apns4ex library. Here is roughly what I found out so far:
Internally on init, the library opens a :ssl (erlang) socket to APNS and keeps recycling that inside a GenServer process
def connect_socket(host, port, opts, timeout_seconds) do
address = "#{host}:#{port}"
case :ssl.connect(host, port, opts, timeout_seconds * 1000) do
{:ok, socket} ->
APNS.Logger.debug("successfully connected to #{address}")
{:ok, socket}
{:error, reason} ->
APNS.Logger.error("failed to connect to push socket #{address}, reason given: #{inspect(reason)}")
{:error, {:connection_failed, address}}
end
end
Now, from hour x, after attempting to send a message, the library starts receiving the :ssl_closed message/callback to indicate that the SSL connection got closed
def handle_info({:ssl_closed, socket}, %{socket_apple: socket} = state) do
APNS.Logger.debug("ssl socket closed, returning :connect")
{:connect, {:error, "ssl_closed"}, %{state | socket_apple: nil}}
end
How it handles this is that it just let's the connection close and returns :connect, which will then re-connect to APNS (here)
Once push notifications stop working, the debug log always reports the following pattern on every message.
Attempt to send the message
Report "success sending" (nothing is being delivered to the phones. This message is caused by :ssl.send reporting :ok)
Then receive a ssl socket close message
Reconnect to gateway.push.apple.com (:ssl.connect returns :ok)
Repeat
send_package code:
def send_package(socket, packet) do
result = :ssl.send(socket, [packet])
case result do
:ok ->
APNS.Logger.debug("success sending ssl package")
{:error, reason} ->
APNS.Logger.warn("error #{reason} sending ssl package")
end
result
end
In contrast, on successful sending it stops at point 2.
Here is some raw log output from my app when sending a push (notice the last 9 lines showing the pattern I described)
01:41:14.820 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 23303051:1ad798 sending in poolboy transaction :myapp
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 23303051:1ad798 sending message
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 62064556:b12e98 sending in poolboy transaction :myapp
01:41:14.821 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 handling cast :send
01:41:14.821 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 message's payload looks good
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 62064556:b12e98 sending message
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 19048099:b3ed8e sending in poolboy transaction :myapp
01:41:14.822 [debug] [APNS] #PID<0.349.0> success sending ssl package
01:41:14.822 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 success sending
01:41:14.822 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 handle call :send received :ok
01:41:14.822 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 handling cast :send
01:41:14.822 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 message's payload looks good
01:41:14.823 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 19048099:b3ed8e sending message
01:41:14.823 request_id=fecds3h3s1so2825c44qfestvvvpv707 [info] Sent 200 in 22ms
01:41:14.823 [debug] [APNS] #PID<0.348.0> success sending ssl package
01:41:14.823 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 success sending
01:41:14.823 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 handle call :send received :ok
01:41:14.823 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e handling cast :send
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e message's payload looks good
01:41:14.824 [debug] [APNS] #PID<0.347.0> success sending ssl package
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e success sending
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e handle call :send received :ok
01:41:15.027 [debug] [APNS] #PID<0.348.0> ssl socket closed, returning :connect
01:41:15.029 [debug] [APNS] #PID<0.347.0> ssl socket closed, returning :connect
01:41:15.043 [debug] [APNS] #PID<0.349.0> ssl socket closed, returning :connect
01:41:15.207 [debug] [APNS] #PID<0.348.0> successfully connected to gateway.push.apple.com:2195
01:41:15.207 [debug] [APNS] #PID<0.348.0> successfully connected to socket
01:41:15.209 [debug] [APNS] #PID<0.347.0> successfully connected to gateway.push.apple.com:2195
01:41:15.209 [debug] [APNS] #PID<0.347.0> successfully connected to socket
01:41:15.214 [debug] [APNS] #PID<0.349.0> successfully connected to gateway.push.apple.com:2195
01:41:15.214 [debug] [APNS] #PID<0.349.0> successfully connected to socket
One theory is that GCE is closing the connection for being idle but this doesn't explain why another message after reconnect immediately results in the same pattern. Also why does the socket only close after sending with :ssl.send?
I have same issue with apns4erl, when socket close after trying send message, but problem was on my side, do not remember, it was either in the wrong certificate file or malformed messages
I am using Akka.Remote to communicate between a server-side service application and multiple desktop client applications. The clients send a request message to the server (using Akka.net) and waits for the server to reply with a response message. The client applications are transient, meaning that they often connect to the server, stay connected for some time, disconnect and then reconnect again.
The problem I encountered is that sometimes when a client disconnects from the server actor (by shutting down its ActorSystem) and then reconnects back to the server, it does not receive any replies from the server for some time. After a few minutes the communication works without any problems. I found out that this issue occurs when the server sends a reply to a client that has disconnected during the request and is no longer reachable. The server cannot deliver the response message and it somehow marks the client endpoint as invalid.
In the log (on the server side) I am getting the following messages when the client is disconnected.
[DEBUG] 2016-01-21 13:04:58.6151 received AutoReceiveMessage <Terminated>: [akka.tcp://qb#client:8090/user/qb] - ExistenceConfirmed=True ServerActor
[DEBUG] 2016-01-21 13:04:58.6550 Stopped Akka.Remote.Transport.ProtocolStateActor
[ INFO] 2016-01-21 13:04:58.6550 Quarantined address [akka.tcp://qb#client:8090] is still unreachable or has not been restarted. Keeping it quarantined. Akka.Event.DummyClassForStringSources
[DEBUG] 2016-01-21 13:04:58.6725 Stopped Akka.Remote.ReliableDeliverySupervisor
[DEBUG] 2016-01-21 13:04:58.6725 no longer watched by [akka://myservice/system/endpointManager/reliableEndpointWriter-akka.tcp%3a%2f%2fqb%40client%3a8090-2] Akka.Remote.EndpointWriter
[DEBUG] 2016-01-21 13:04:58.6725 Disassociated [akka.tcp://myservice#server:8081] <- akka.tcp://qb#client:8090 Akka.Remote.EndpointWriter
[DEBUG] 2016-01-21 13:04:58.6725 Stopped Akka.Remote.EndpointWriter
And then when the client attempts to reconnect, I get:
[DEBUG] 2016-01-21 13:05:15.5883 ConnectResponse [akka.tcp://qb#client:8090/user/qb] ServerActor
[DEBUG] 2016-01-21 13:05:16.0467 Started (Akka.Remote.Transport.ProtocolStateActor) Akka.Remote.Transport.ProtocolStateActor
[DEBUG] 2016-01-21 13:05:16.0467 Stopped Akka.Remote.Transport.ProtocolStateActor
[ WARN] 2016-01-21 13:05:16.0467 AssociationError [akka.tcp://myservice#server:8081] -> akka.tcp://qb#client:8090: Error [Invalid address: akka.tcp://qb#client:8090] [] Akka.Remote.EndpointWriter
[ INFO] 2016-01-21 13:05:16.0467 Quarantined address [akka.tcp://qb#client:8090] is still unreachable or has not been restarted. Keeping it quarantined. Akka.Event.DummyClassForStringSources
[DEBUG] 2016-01-21 13:05:16.0643 Stopped Akka.Remote.ReliableDeliverySupervisor
[DEBUG] 2016-01-21 13:05:16.0711 no longer watched by [akka://myservice/system/endpointManager/reliableEndpointWriter-akka.tcp%3a%2f%2fqb%40client%3a8090-4] Akka.Remote.EndpointWriter
[DEBUG] 2016-01-21 13:05:16.0711 Disassociated [akka.tcp://myservice#server:8081] -> akka.tcp://qb#client:8090 Akka.Remote.EndpointWriter
[DEBUG] 2016-01-21 13:05:16.0711 Stopped Akka.Remote.EndpointWriter
[DEBUG] 2016-01-21 13:05:16.0867 received AutoReceiveMessage <Terminated>: [akka://myservice/system/endpointManager/reliableEndpointWriter-akka.tcp%3a%2f%2fqb%40client%3a8090-4] - ExistenceConfirmed=True Akka.Remote.EndpointManager
[DEBUG] 2016-01-21 13:05:16.0867 Terminated [akka.tcp://qb#client:8090/user/qb] ServerActor
I suspect that this behavior is a feature of Akka.net, however, I need to implement my system so that clients can disconnect and then reconnect back to the server without the need to wait. Is there any way to disable the quarantine mechanism or to gracefully close the client endpoint on the server so that the client endpoint doesn't get quarantined?
[ INFO] 2016-01-21 13:04:58.6550 Quarantined address [akka.tcp://qb#client:8090] is still unreachable or has not been restarted. Keeping it quarantined. - that says it all. The node was quarantined which requires a restart of the actor system.
However, IMHO - just upgrade to Akka.NET 1.0.6, which we released on Monday. We made the remoting policy manager much less brittle than it has been historically.