Hi all,

After a bit studying fpWeb package, especially the FCGI application, I have a feature request to it. Would you (Joost? Michael?) please add auto shutdown (after some idle time) feature to TFCGIApplication? If you had looked at ExtPascal's FCGI implementation, it offers this feature. This feature is to prevent the FCGI app keep always running when it actually does nothing (idle). For some situations, this feature is usefull and handy. I saw the CGI gateway already able to execute local FCGI app if it fails to connect to it.

I know I should supply a patch for this. But I'm not that confident to do it because I don't think I already got a good grasp to the code. The class hirarchy and dependency is quite complex, at least to me. I'm afraid I'm gonna mess them up. :D Or, if you don't have time to do it, please give me some lights about how to implement this feature correctly (how and where).

For any response, I thank you in advance. :)

-Bee-

Unless Joost does it first, I'll have a look at it next week. But it will be under control of an option, and this option will be 'off' by default.

Michael.

Michael Van Canneyt wrote

Unless Joost does it first, I'll have a look at it next week. But it will be under control of an option, and this option will be 'off' by default.

Of course. I agree with that. It'd be nicer if the option can be set from the config file, just like the way I implemented it in ExtPascal. Thank you. :)

-Bee-

The FCL FastCGI class does not have a config file.

If you want that, you must implement that yourself.

It is one of the flaws of ExtPascal's implementation: everything is tied together, using fixed formats for config files. When it would be far better to provide properties which can be set/unset at will: A modular design, allowing to re-use the components in setups that the implementor didn't think of.

Michael.

Michael Van Canneyt wrote

The FCL FastCGI class does not have a config file. If you want that, you must implement that yourself.

Alright then.

It is one of the flaws of ExtPascal's implementation: everything is tied together, using fixed formats for config files.

Whether it's a flaw or not, it just a matter of POV. Wanderlan seems to be a KISS concept lover. When a simpler way could get the job done, then be it. If then something more complex is needed, then improve it when the need is here. He's a very pragmatic developer, I would say.

When it would be far better to provide properties which can be set/unset at will: A modular design, allowing to re-use the components in setups that the implementor didn't think of.

ExtPascal's code, despite the flaws as you said, is very easy to be understood because of its simplicity. Somehow I think it's good to attract new contributors because s/he doesn't need too learn a huge beast OO framework beneath it. I only needed a mere couple of hours to get a good grasp of it. If the code become more complex, a refactoring effort can be done easily. Besides, it's (always) a work in progress. I believe it'll evolve, just like the other open source projects. ;)

-Bee-

Yes, but he chooses a very restrictive approach. As it is, you must convince him to change something. With the modular component approach, you don't need to wait. You develop whatever extensions you need on top of existing components. This is not doable with ExtPascal.

Anyway, I don't want to criticize him too much. He had some very good ideas in ExtPascal, and they are certainly worth looking at.

Let us hope so :-)

Michael.

Michael Van Canneyt wrote

Yes, but he chooses a very restrictive approach. As it is, you must convince him to change something. With the modular component approach, you don't need to wait.

Why should I have to wait? I got the source code, all of them. If I need some new features and I'm able to implement it myself, nobody could prevent me to do it. That's why the simplicity of ExtPascal code does matter in some cases.

He had some very good ideas in ExtPascal, and they are certainly worth looking at.

Yes, before I knew ExtPascal, I never thought such tool can be build (pascal vs js ui framework integration). Even Morfik is unable to do it, at least not easily. :)

Let us hope so :-)

Well... it's happening. :)

-Bee-

Michael Van Canneyt wrote

I'll have a look at it next week. But it will be under control of an option, and this option will be 'off' by default.

Another thought about this feature. I think it'd be nice if there's an option to shutdown the app gracefully. What I mean by gracefully is when the app get a shutdown request, and the option is 'on', then the app doesn't suddently terminate itself but it waits until all currently active sessions got closed and also doesn't accept new sessions. This condition (waiting for termination) status can be read by the app through a read-only flag so the app can raise an alert to end users announcing that the app is about to close so the users are asked to immediately finish their job and quit (logout). So, the app doesn't need to wait forever.

What do you think, Michael?

-Bee-

You'll have to program that yourself, because I think it is a security leak.

But if you want it, it's really easy to do in fcl-web. Create a webmodule, implement the OnRequest handler of the module, and add

   Application.Terminate:=True;
   Handled:=True;

in the handler. Then register the module with the name 'shutdown'.

then
http://www.yourhost.com/shutdown
will nicely shut down your app after handling the request properly.

Obviously, I'd add some security mechanism, like

   If ARequest.Query['password']'mysecret' then
     Raise Exception.Create('Wrong password. Please go away.');

if the wrong password is given ,then the exception will be translated to a webpage and sent back to the client.
But the url
http://www.yourhost.com/shutdown?password=mysecret will still shutdown your app.

Michael.

Michael Van Canneyt wrote

But if you want it, it's really easy to do in fcl-web. Create a webmodule, implement the OnRequest handler of the module, and add Application.Terminate:=True; Handled:=True; in the handler. Then register the module with the name 'shutdown'.

Ok, thanks for the hint.

Obviously, I'd add some security mechanism

Of course. Absolutely, Michael. :)

But the url http://www.yourhost.com/shutdown?password=mysecret will still shutdown your app.

Plus SSL. ;)

-Bee-

I am new to this technology... I was using isapi, with and isapoloader dll, that was responsible of the upgrade of the application. The isapiloader before sending the request to the actual isapi application, it tried to find if there is a new version of it, with the same name of the dll but with extensión .new, and if it finded it, it unload the real application dll, replace it with the .new one, and load it again. This way it is possible to replace the application without stoping the web server.
Something like this is necessary with fcgi? Does the cgi gateway do this also?
What could be even better is the possibility to save all the users active sessions data to same temporary file before unload (or kill) the running application module, and to be loaded after the new one is loaded so the users do not even note that the version changed, and do not get them out.

I expect you understand what I mean... but I don´t know if all this is doable, or available in the current fpweb fcgi implementation.

Thanks

Horacio