HTTP Background Service

moctes · 2014-08-20 18:19:36

Hi,

I took the sample "10 - Background Http service" as a basis for a Windows service, for manual testing and debugging I am running the project with the "-c" parameter, and I have no problem at all, but I can see a weird behavior when I press the Enter key on the console window sometimes the window won't close right away and I need to keep pressing the enter key a few more times until the window is closed and the process terminated, although it is a little annoying I don't have a problem with that, but what really bothers me is that when I try to run the project again the Delphi IDE will complain it can't create the .exe file which seems to be still in use, I can go to the .exe folder and manually delete the file but if I refresh the folder, then the exe "magically" appears and I can keep deleting the file and it will keep appearing for a while, eventually it would be effectively deleted and I would be able to run it again, I have checked with the Unlocker utility and it doesn't report that te file is blocked by any application :-|

Anyone else is seeing this behavior ? May be is something normal but it hinders the work :-( I would like to know if it is a problem that can be solved or is simply the way that things work.

P.S. Environment: Delphi XE3, Windows 7 64, Testing is done compiling for 32 bits.

ab · 2014-08-20 19:01:59

Yes, in console mode, the key has to be fetched directly from our loop.
It is mandatory to let Synchronize() work as expected, i.e. let some process be executed in the main thread.

You could change the ConsoleWaitForEnterKey; call by a Readln; if you do not use any option to force execution in the main thread.

About the "file still in use" I've never seen this.
Could you try with the ProcessExplorer tool (from SysInternals) to find out what is happening at this time.
Also enable the logs and check what is on, according to the timestamp.

moctes · 2014-08-20 22:32:58

ab wrote:

Yes, in console mode, the key has to be fetched directly from our loop.
It is mandatory to let Synchronize() work as expected, i.e. let some process be executed in the main thread.
You could change the ConsoleWaitForEnterKey; call by a Readln; if you do not use any option to force execution in the main thread.

Tested, with readln the application ends immediately

ab wrote:

About the "file still in use" I've never seen this.
Could you try with the ProcessExplorer tool (from SysInternals) to find out what is happening at this time.
Also enable the logs and check what is on, according to the timestamp.

Will check with ProcessExplorer, sometimes I can run the project twice on a row but a third try gives me

[dcc32 Fatal Error] F2039 Could not create output file '.\Win32\Debug\httpservice_lx.exe'

Some lines that came to my attention on the log file:

20140820 16543205  +    	TSQLDBZEOSStatement(0092D410).007DE22C 
20140820 16543205 SQL   		TSQLDBZEOSStatement(0092D410) CREATE UNIQUE INDEX NDXPaisID ON public.Pais(ID)
20140820 16543205 EXC   		EZSQLException ("SQL Error: ERROR:  Relation «ndxpaisid» already exists") at 0073C170  stack trace API 00520B5C 
20140820 16543205  -    	00.002.897

This is appearing on the second and subsequents runs (the first run created the tables) I suspect

RestServerDB.CreateMissingTables(0);

is the culprit, I getting this for every table index of the model per database/schema (it isn't causing troubles but is in the log) and that includes the Authorization tables.

The following code :

Server := TSQLHttpServer.Create('8080',aServidores,'+',useHttpApiRegisteringURI);
TSQLLog.Add.Log(sllInfo,'Server % started by %',[Server.HttpServer, Server]);

register this on the log:

20140820 16552547 info  	Server null started by null

I don't know if "null" is what should be on the log, btw "Server" is not null

The server does run and also get the job done, just wanted to point your attention to the previous messages, maybe I'm still missing something.

ab · 2014-08-21 04:28:57

This SQL error is expected to potentially appear...
Sometimes, the metadata returned by ZDBC does not indicates that a field is already indexed, so the ORM tries to create the index. It fails, but the exception is catch, and everything continue to work.
Nothing terrible here...

EgonHugeist · 2014-08-21 08:04:48

Arnaud,

i think we're running into UpperCase/LowerCase/MixedCse trouble again:

Table Pais should be IdentifierQuoted as "Pais" and Zeos successfully would return the indexinfo. Otherwise Zeos does LowerCase the tablename. We had SOOOOO many bugreports in the past accordingly such determinations.
MetaData.GetTables returns all Tables like the users did create them. Using as syntax like

YourStringValue := StringToUTF8(MetaData.GetIdentifierConverter.Quote(TableName));

could prevent this case. What i don't know is: would thes quote chars like

´´ for MySQL
[] for MSSQL/ADO
"" for FB/PostgreSQL
....

make trouble in your JSON parser?

ab · 2014-08-21 12:59:54

" would break any JSON content.

But the table name won't be part of the JSON itself, but on the request, and our framework should break all the generated JSON as expected.

AFAIR we already used such table name quoting for most external database SQL generation.
Perhaps the metadata does not use this table name quoting, so it does not find the existing index.
I would check it.
But in all cases, this exception is not a big issue!

mORMot Open Source

#1 2014-08-20 18:19:36

HTTP Background Service

#2 2014-08-20 19:01:59

Re: HTTP Background Service

#3 2014-08-20 22:32:58

Re: HTTP Background Service

#4 2014-08-21 04:28:57

Re: HTTP Background Service

#5 2014-08-21 08:04:48

Re: HTTP Background Service

#6 2014-08-21 12:59:54

Re: HTTP Background Service

Board footer