HFS stops receiving connections until program restarted

[amolina]

Hello,

I've been having issues with HFS as of lately, and need help to sort it out. Almost daily server stops receiving connections without any error displaying or anything alike. Version is 2.3m. I only have to restart the application and it starts working ok until it "crashes" again.

I have HFS as an http server for some users to get some files automatically. there should be around 1 to 5 requests to the server per second, and they are usually served without issues, but for some reason after some time, those request are not even seen in the log screen, and files are not being received by users. After application is restarted then I start seeing request and responses again with current time stamps.

[NaitLee]

Actually your problem is usual among all HFS users.

You can try danny's WatchDog/WatchCat to keep HFS alive
They're useful to such kind of problem.

[Mars]

I did not look into the question, but under the conditions mentioned is it necessary in this case to kill the HFS process or is the interface still functional?
 use the F4 key to stop and restart the server part is it sufficient to resolve?
 it in the log then there should be lines which inform of the change of state --> in this case are the remote connections operational again?

to check that the program continues to react despite the fact that remote connections are no longer possible, just add an event in hfs.events file to write to the log,

[every 10 min]
{.add to log |% timestamp%.}

- if hfs gets stuck, it will be easy to determine for how long, within 10 minutes

- if the blocking does not cause the crash of hfs, and a STOP/START using F4 is sufficient, it is also possible by an event to force it automatically if no external  request is made in a given time interval

my response to come depending on what your observations will give

[NaitLee]

Because I've also met this problem several times, I can give some details.

This problem happens when there are many connections (requests?) received by HFS and/or the network flow is too much, then HFS' network function "stopped working".

use the F4 key to stop and restart the server part is it sufficient to resolve?
 it in the log then there should be lines which inform of the change of state --> in this case are the remote connections operational again?

The answer is Yes. The HFS UI is still alive, the only thing doesn't work is the network function -- No one can connect to that HFS site.
And switching F4 can solve the problem manually.

[LeoNeeson]

to check that the program continues to react despite the fact that remote connections are no longer possible, just add an event in hfs.events file to write to the log

Very smart idea! And this gives me another one idea: how about "add to log" every 10 seconds the number of active connections?. This will give us a more 'close' detail of the limit before it crash.

[Mars]

hfs.events

[every 10]
{.add to log|%connections%.}

the timing is not very precise, it is necessary to take into account an offset and to put 9 instead of 10 is preferable

look at http://www.rejetto.com/wiki/index.php?title=HFS:_Template_symbols

we must be careful that during the processing of such an event hfs does nothing else which can slow down its operation on its other tasks

[danny]

On very fast internet connections the speed-limit is especially likely to cause the quasi-off condition.
However...
One limit increases reliability:
Max simultaneous downloads from single address  (is good)
Use only that one.   Try setting it to 1 or 2

My suggestion doesn't stop the old retry-flood = exit, nor the newer quasi-off condition.   We still need a "watchdog" in Events, which would test the loopback 127.0.0.1 for alive (with .load 127.0.0.1/favicon?); and if no response, server off, then slightly into the future server on. 

Edit:  5 second time before server on, so that the overload cause/bot has given up or gone elsewhere?
Edit2:  Also, server off server on = server off.  (not useful)  So, I think that we have to quote server on to make it run last.
Maybe this:  server off, if not server off then server off, else {:server on {.if not server on then {:server on:}.}:} can run in the correct order to change the quasi-off condition to server on?   For server on, it may be necessary to check&loop until server is really on?
The key is this order:  server off, Look Over There!!!, server on{:server on:}
Edit3:  Only the .load macro + loopback can be used for watchdog purpose (must make an http request for watchdog test).