Showing server output in OpenPetraWebServer

pokorra

Hello Alan,
I wonder it it would be good for us developers to see the output in the server, as we used to with the server that is currently in trunk, and my TinyWebServer also did that.

One option is to use AttachConsole. See also stackoverflow.com/a/8741008/1632368

--- csharp/ICT/BuildTools/OpenPetraWebServer/Program.cs 2014-04-03 08:19:17 +0000
+++ csharp/ICT/BuildTools/OpenPetraWebServer/Program.cs 2014-04-05 04:55:18 +0000
@ @ -98,7 +98,9 @ @
static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
[DllImport("User32.dll", CharSet = CharSet.Auto, SetLastError = true)]

private static extern IntPtr SendMessage(IntPtr hwnd, uint Msg, IntPtr wParam, IntPtr lParam);
[DllImport("kernel32.dll")]
public static extern Boolean AllocConsole(int dwProcessId);

+

private static Form myForm = null;
 /// <summary>
@ @ -183,6 +185,7 @ @
new Thread(stopThread).Start();
}

AllocConsole(-1);
TLogging.Log("Ict.Tools.OpenPetraWebServer is now running on port " + commandLineArgs.Port.ToString() + "...");
TLogging.Log(" Command line was: " + Environment.CommandLine);
Application.EnableVisualStyles();

This will open a console window, and log all the output, eg. when clients log in, and any TLogging.Log call from within OpenPetra on the server side.
When you close the console window, the whole server stops.
But that used to be the behaviour of our development server anyway.

An alternative would be to somehow catch all console output and redirect it to the OpenPetraWebServer window.

What do you think? Are you happy with a console window?
Or is it worth the effort to embed the console output into the main GUI window of the OpenPetraWebServer?

All the best,
Timotheus

christiankatict

Hi Timo,

I always found it a very helpful feature to be able to show output directly and not just having the option of writing to a log file.

I don't mind which of the methods you mentioned is used.
However, if there is a way in which the output could be captured and be displayed inside the OpenPetraWebServers' window then that would also open up the option of making that available remotely so that it can be accessed via a (secured) web page from anywhere, I guess. That could prove very helpful, but is of course not essential.

Kind regards,

ChristianK

alanjfpaterson

Hi there,

I'm sorry - I got behind with keeping up to date with forum posts and have just noticed this one.

I have started adding logging to the web server GUI. (Not by attaching a console window).

I checked Christian's launchpad and decided that I knew where the latest code for the OP Web Server was. It seems to have 3 modified files compared with the code I checked in. When I was looking for differences I discovered that I had made one small change to the code on my laptop that I never posted back to Timo. It related to discovering if the specified port was already in use. I think that I found that the method that is in your code was not reliable as a means of detecting an in-use port - and hence deciding whether to close the app and leave the job to the already-running instance. So that reminds me that you said that you had multiple instances open when you were running the Nant tests. Maybe this would have fixed that? If so I am very sorry if that gave you problems.

Anyway. I will hope to finish this logging today.

Alan

alanjfpaterson

Hello again,

Good news! I managed to get logging to a Windows Forms form working inside the web server. Also I implemented HttpRequest logging for each web site so you can see exactly which url's were requested in what order.

It took me all day up till bedtime - more on the request logging than our own logging - because you are trying to get a worker thread to do logging and there are a lot of restrictions as to what access the Http runtime has to the file system. So it isn't very much code - the issue is what the code should be and where can it go without getting deadlocked. Of cource you can either open the request log in Notepad - or browse to it!

Regarding the TLogging logging. I made a very small change to the TLogging class so as not to write to the error console but to accumulate the log in a string, accessible to a Forms-type application and with a callback whenever a new message is logged. It behaves like a console window would - it lets the string grow to a maximum of 16K and then truncates it back to 8K. TLogging manages this process. (Of course the file log has everything as usual.)

I've just got a bit of tidying to do and I can add a bit more logging to the web app. I haven't tried it yet to see what happens when we get server exceptions, but I imagine that you are right - we should pick them up into the same log. I have added some more command line options for where the log path is, whether to do HttpRequest logging or not - and this all is integrated into both the full GUI and the Small GUI. The startup options are read from TAppSettingsManager first and then from the command line itself (which our common nant targets can use - or as web server developer (like me) by specifying them in the IDE.

Christian - when you are feeling better I will talk to you about merging this code ....

Best wishes

Alan

alanjfpaterson

More news about the OP development web server....

I finished off the logging of server activity and also of page requests. The page requests is useful because it does show very easily if we are sending duplicate messages to the server as a result of client events being duplicated. My web service branch is quite old (it goes back to before Christian merged trunk into Timo's branch) and we have done work during that time to try and get rid of these duplicate calls, but in my branch I see a lot of them!

Anyway, I had a good look through the changes in Christian's branch relating to the OP web server and the way it is called from nant and realised that you have included the command line option to set a maximum lifetime (by default 120 minutes) and recalled seeing comments in this forum about problems you were having with Windows Jenkins. As I said in an earlier post, you were working with code that was not reliable in checking to see if a server had already captured the OP port (9000) so you could end up with multiple server apps running. But that may not be anything to do with your problem. Anyway, from the point of view of a developer, it would be really annoying to have the server disappearing under your feet after 2 hours!

I decided that there was a requirement for a 'server manger' application (since the design of the application is to be able to run multiple web sites, say for different software versions). Since the whole thing is Windows and for Windows developers I have written this application over the extended Easter weekend.

Like the web server app itself, it has a interactive GUI and a command line GUI. For the Jenkins server you will be able just to execute 'Ict.Tools.OPServerManager.exe -op:shutdown -port:9000' and that will immediately shutdown the server that is on the standard port. Or a developer can run the application from OPDA and not have to go digging in the system tray. There are commands to shutdown all or a selected server, or to start or stop a server. The maximum lifetime option is still available but this way Jenkins can call this nant target at the start of a build job to clear the server.

Of course Windows Jenkins should be using IIS but that will need a bit of work to develop a setup for that - but we will need one for our installer. I have worked on an installer for IIS and could help with that too in the future.