You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've investigated how does CLOG tutorials work and was wondered how CLOG survives diconnections. That is how I found the problem.
I started the 11 tutorial and opened the page in the browser.
Set (setf clog-connection:*verbose-output* t)
Opened clog-connection::*connection-data* in the inspector. And found there is one connection
In a separate terminal started the command tcpkill -i lo port 8080 to drop websocket connections.
In the REPL I've seen messages about connection closing and transferring (the full log is at the end of the issue.
I stopped the tcpkill.
I've refreshed view of the clog-connection::*connection-data* in the inspector. And it show no connections.
When I tried to push button on the web page, the full page reload had place instead of the form submission.
Looking at the log, I might suppose that the cause of the problem in the order of how new connections are closed - they are dying before reconnection has happened. Also, seems the whole reconnection step should be done under the lock to protect connection-data integrity.
Full log:
Connection 1bcdf267afeadaa429875fc745d8289a Ping
Connection 1bcdf267afeadaa429875fc745d8289a Ping
Connection 1bcdf267afeadaa429875fc745d8289a Ping
Connection close request #<SERVER {10078909E3}>.
Connection close request #<SERVER {10078909E3}> delayed 7 for reconnects.
Reconnection id - 1bcdf267afeadaa429875fc745d8289a to #<SERVER {1007941133}>
Transfer id - #<SERVER {10078909E3}> => #<SERVER {1007941133}>Reconnection id - 1bcdf267afeadaa429875fc745d8289a to #<SERVER {10079C09F3}>
Transfer id - #<SERVER {1007941133}> => #<SERVER {10079C09F3}>Connection close request #<SERVER {10079C09F3}>.
Connection close request #<SERVER {10079C09F3}> delayed 7 for reconnects.
Connection close request #<SERVER {1007941133}>.
Connection close request #<SERVER {1007941133}> delayed 7 for reconnects.
Reconnection id - 1bcdf267afeadaa429875fc745d8289a to #<SERVER {10079E89F3}>
Transfer id - #<SERVER {10079C09F3}> => #<SERVER {10079E89F3}>Reconnection id - 1bcdf267afeadaa429875fc745d8289a to #<SERVER {1007A209F3}>
Transfer id - #<SERVER {10079E89F3}> => #<SERVER {1007A209F3}>Connection close request #<SERVER {1007A209F3}>.
Connection close request #<SERVER {1007A209F3}> delayed 7 for reconnects.
Connection close request #<SERVER {10079E89F3}>.
Connection close request #<SERVER {10079E89F3}> delayed 7 for reconnects.
Reconnection id - 1bcdf267afeadaa429875fc745d8289a to #<SERVER {1007A409F3}>
Transfer id - #<SERVER {1007A209F3}> => #<SERVER {1007A409F3}>Reconnection id - 1bcdf267afeadaa429875fc745d8289a to #<SERVER {1007A689F3}>
Transfer id - #<SERVER {1007A409F3}> => #<SERVER {1007A689F3}>Reconnection id - 1bcdf267afeadaa429875fc745d8289a to #<SERVER {1007AB09F3}>
Transfer id - #<SERVER {1007A689F3}> => #<SERVER {1007AB09F3}>Connection close request #<SERVER {1007A409F3}>.
Connection close request #<SERVER {1007A409F3}> delayed 7 for reconnects.
Connection close request #<SERVER {1007A689F3}>.
Connection close request #<SERVER {1007A689F3}> delayed 7 for reconnects.
Connection close request #<SERVER {1007AB09F3}>.
Connection close request #<SERVER {1007AB09F3}> delayed 7 for reconnects.
Connection close request #<SERVER {10078909E3}>.
Connection close request #<SERVER {10078909E3}> delayed 7 for reconnects.
Connection close request #<SERVER {10079C09F3}>.
Connection close request #<SERVER {10079C09F3}> delayed 7 for reconnects.
Connection close request #<SERVER {1007A209F3}>.
Connection close request #<SERVER {1007A209F3}> delayed 7 for reconnects.
Connection id 1bcdf267afeadaa429875fc745d8289a has closed. #<SERVER {1007AB09F3}>
Connection close request #<SERVER {1007AB09F3}>.
Connection close request #<SERVER {1007AB09F3}> delayed 7 for reconnects.
The text was updated successfully, but these errors were encountered:
I will take a look at this soon. In theory a disconnect for more than the set 7 seconds (that is configurable) can not be restored. If your application has long disconnects you can just set that number higher (setf clog-connection:reconnect-delay 7).
I've investigated how does CLOG tutorials work and was wondered how CLOG survives diconnections. That is how I found the problem.
(setf clog-connection:*verbose-output* t)
clog-connection::*connection-data*
in the inspector. And found there is one connectiontcpkill -i lo port 8080
to drop websocket connections.tcpkill
.clog-connection::*connection-data*
in the inspector. And it show no connections.Looking at the log, I might suppose that the cause of the problem in the order of how new connections are closed - they are dying before reconnection has happened. Also, seems the whole reconnection step should be done under the lock to protect connection-data integrity.
Full log:
The text was updated successfully, but these errors were encountered: