I am facing a strange problem. After a variable amount of time, my quickfixj session simply hangs without any error. The session seems to be locked because I cannot write anything to it (without exceptions on the log file) nor the server sends anything to me. The thread socket initiator shows that the sessions is logged in, but I cannot write anything on the socket because it seems to be locked.
Any suggestions?
Related
TL;DR: Rails-server restarts aren't handled gracefully in Action Cable, resulting in corrupted state. How to fix that?
I run a Rails server which uses Action Cable, among other things.
When I change a file, the server restarts as expected. But it doesn't exactly restart gracefully.
The Action Cable connection logs {"type":"disconnect","reason":"server_restart","reconnect":true} in the established socket. Then the socket appears to be cut and my channel's unsubscribed method does not run. Upon reconnect, however, the subscribed method does run—as it should, but now we have an asymmetry. Something as simple as keeping track of the number of connected clients has become unreliable because upon a server restart that number will now double although the true number remained the same. That's because it gets to increment the count when subscribed is called, but decrementing the counter happens in unsubscribed, which is not called when the server restarts.
If this only happened in development, it wouldn't be a huge issue, but it happens in production as well during server restarts caused by deployments.
How do I tell Rails to restart the server gracefully, by which I mean it should also run the unsubscribed method in my channel instead of just cutting the connection?
EDIT: I've also filed an issue with Rails: https://github.com/rails/rails/issues/41005
I have google'ed a lot on this question but haven't found an answer. I have a Guacamole server that connects to a local VNC session and I would like for it to disconnect the user session if it detects no activity for an hour.
What I've tried and attempted
used xprintidle to show idle time of the user, this works so will be put in a script that might be used later to terminate an idle session.
I have looked at Guacamole's api-session-timeout and set it for a minute, I had hoped it would not reconnect to the same session once the VNC server stops abruptly. It seems this did not work.
I have tried to use guacamole's user-mappings.xml to specify the parameter "autoretry" and set that to "1". Restarted and this did not work, I'm thinking its not used this way.
I have went to the guacamole postgres database and manually inserted the entry for autoretry into the parameter table. Restarted, but this did not work.
I have went to the VNC side (I use TurboVNC) and looked at the flag -idletimeout and configuration option max-idle-timeout. This terminates the TurboVNC service when there are no active connections. It is not what I am after, I'm trying to only disconnect the session when the user is idle.
I figured that the VNC side would not work because even if the VNC session is terminated Guacamole would keep on retying forever to reconnect to that session.
From some posts on the Guacamole mailing list it seems that disabling auto reconnect is not possible without a recompile from source.
Is there a way to disconnect an active session after an idle timeout period? or maybe a way to stop Guacamole from reconnecting?
I'm getting 'Incomplete response received from application' when testing my rails application. It disappears when I refresh the page..
I check my apache error logs and I found this line:
[ W 2018-08-06 07:55:32.1636 126806/T8 age/Cor/Con/InternalUtils.cpp:96 ]: [Client 1-4] Sending 502 response: application did not send a complete response
Any one faced the same issue ?
This issue has some history. Best you can do is add some debug to your application.
This happens when your application exits prematurely. To understand what this means, consider that Passenger works by sitting between the client and the app. Passenger acts like a reverse proxy, so it forwards the request to your app, then processes the response that the app sends.
client <-----> Passenger <-----> app
If, after Passenger has sent the request, the app crashes or otherwise exits before sending a response, then you will see "application did not send a complete response".
So the question is actually: why does the application exit? Unfortunately I do not know, and neither does Passenger. Passenger only starts your app and expects your app to respond to requests as normal. Maybe there is a bug in the app, or the app encountered some sort of fatal error. Normally the app will print an error message when that happens, but Passenger did not encounter any such messages, or it would have printed them.
So the best thing I can recommend you to do is that you insert debugging statements inside your app and find out what makes it exit.
I'm using the Wink API to control lights and thermostats etc. In the API you can subscribe to device topics to receive events such as when a light is turned on or off. This is handled through PubNub. I have this all working except that the events stop being sent if I leave the system overnight.
If I try to "manually" toggle a light by tapping the physical switch then normally an event is fired and received by my application via PubNub. Restarting my application and thus reconnecting to PubNub does NOT resolve the issue. The only way I've found to resolve the issue is to open the Wink app itself. Nothing else needs to be done but to open the Wink app. Then if I manually toggle the switch the event will show up and be received by my application. This solution works even if I don't restart my application.
There appears to be some sort of wake or keep-alive going on. Although I don't see anything in the Wink API docs that state such. There is also nothing sent from PubNub during this downtime. I have logging being sent out for the status(), message(), and presence() callbacks and nothing is logged from these overnight. Therefore taking all the above into account I believe the issue resides on the Wink side of things.
Unfortunately, Wink does not provide developer support. The Wink app is obviously doing something but because the transactions are encrypted it is unknown what it is doing. Also my test cycle is 8 hours long currently so it is difficult to debug this by trial and error. I'm working to see if this "timeout" is shorter than the overnight 8 hours I've experienced so far. i've also tried power cycling my Wink Hub yesterday but that did not resolve the issue.
Anyone else run into this issue? How do you keep subscriptions alive so that they are always sent?
I'm writing an app using Parse which saves data to the server over a connection with unknown stability. As such I'm using saveEventually.
I'm trying to deal with the situation where the app is minimised, and then terminated by the system before a save is complete. The trouble is, when
opening the app afresh, I issue a logout command, since users are required to log in. It appears that this logout command can overtake the save commands, removing the session from the server, causing the queued save commands to fail. (I also can't see any way of handling these failures after an app restart, since I don't see any delegate based handlers, and blocks are cleared.)
I can't see any user-facing solutions to this either, since there is no guarantee when saveEventually might decide to run, and I can't block the user indefinitely.
Has anybody dealt with this? Any suggestions are most welcome.