You are not logged in.
Pages: 1
So... I got http and named pipes working just fine.
Now Im trying message based C/S communication.
This is how the client is instantiated:
procedure TLCSServerMessageTest.InitRestClient(VAR aSQLRestClient: TSQLRestClientURI);
begin
inherited;
aSQLRestClient:=TSQLRestClientURIMessage.Create(FModel,cLCSServerName,ClassName,1000);
end;
And this is how the server is "published" from the constructor. cLCSServerName is the same const on both sides. Obvously I am missing something, but I seem to be unable to find out what.
Win7x64, DelphiXE2
constructor TLCSRestServer.Create;
begin
FRestServersByURI := TObjectDictionary<RawUTF8,TSQLRestServerDB>.Create([]);
FRestServersByAlias := TObjectDictionary<RawUTF8,TSQLRestServerDB>.Create([]);
FServerModel := TLCSServerRootModel.Create(cLCSServerName);
FServerConnProp := CreateConnectionPropertiesForConnectionString(ExpandSNGMacros(cfpLCSServerBaseDBPath));
VirtualTableExternalRegisterAll(FServerModel, FServerConnProp);
inherited Create(FServerModel, ExpandSNGMacros(cfpLCSServerBaseSQLiteDBPath), True);
CreateMissingTables;
ServiceRegister(TLCSServer,[TypeInfo(ILCSServer)],sicShared);
ServiceRegister(TLCSAliasManager,[TypeInfo(ILCSAliasManager)],sicShared);
ServiceRegister(TLCSClientServerSession,[TypeInfo(ILCSClientServerSession)],sicClientDriven);
ExportServerNamedPipe(cLCSServerName);
ExportServerMessage(cLCSServerName);
end; {- TLCSRestServer.Create }
Offline
The InitRestCLient is a virtual method that allows different communications to be tested with the same base TTestCase . AMOF it's the onbly routine that is overriden in my derived testcase classes.
procedure TLCSServerTestBase.SetUp;
begin
inherited;
FModel := TLCSModel.Create(cLCSServerName);
InitRestClient(FSQLRestCLient); // virtual method call
CheckTrue(FSQLRestCLient.SetUser('Admin', 'synopse'), 'Authentication failed');
CheckTrue(FSQLRestCLient.ServiceRegister([TypeInfo(ILCSServer), TypeInfo(ILCSAliasManager)], sicShared),'ServiceRegister failed for ILCSServer');
CheckTrue(FSQLRestCLient.Services.Info(TypeInfo(ILCSServer)).Get(FLCSServer), 'Get(FLCSServer) failed');
CheckNotNull(LCSServer, 'LCS Server Interface not retrieved from server');
CheckTrue(FSQLRestCLient.Services.Info(TypeInfo(ILCSAliasManager)).Get(FLCSAliasManager), 'Get(FLCSAliasManager) failed');
CheckNotNull(LCSAliasManager, 'LCS Aliasmanager Interface not retrieved from server');
end;
What might help is the actual error message
No "LCSServer" window available - server may be down
The server is defenitely not down as far as I know, as the other tests (HTTP and Name pipe) run OK.
COuld it be something stupid like an invalid window name? I found int the mormot sources that actually not the window name is set but the window class name. Also, the client seems to look for the window as classname and not the actual window name, so that looks ok.
Offline
In TSQLRestServer.ExportServerMessage(), it will check for an existing fExportServerNamedPipeThread instance.
So in your case, it won't launch the GDI-based message feature.
In the current implementation, only one of the two means of communication is allowed.
This is perhaps an unnecessary limitation, since TSQLRestServer.URI() is designed to be thread-safe, so call be called by multiple protocols at once.
I've allowed TSQLRestServer.ExportServerMessage to be started in conjunction with other protocols (like named pipes).
See http://synopse.info/fossil/info/bd8fab792e
Offline
Ah that's the cause.
Thx for the quck solution.
Offline
I confirm this fixed.
My server app is a console app, waiting for a (console) readln to finish. This made the client app wait endlessly for a response.
I had to add a "MessageDlg" call to my server main routine, obvioulsy to ensure there is a message handling loop. Now it works fine.
I must say I actually expected the TSQLRestServer to implement the message loop...? - so: Is mormot missing a message handling loop, or is it WAD and did I miss something?
Offline
You should have your message loop somewhere in your code.
As stated by the documentation of ExportServerMessage:
// - the main server instance has to process the windows messages regularely
// (e.g. with Application.ProcessMessages)
This is by design, for any Windows applications, I suspect.
Since you should have only one message loop per application, does make sense to let the user implement it as expected.
Offline
OK. Thx
Offline
Just rethinking this: shouldnt there be (or is it already there) some kind of timeout on the message send/wait in the client side? Now my client "freezes", and no error is returned unti I shutdown my server.
I wouldnt want "al" my clients to freeze without an error message if my server hangs...
Offline
OK, I missed that. - Thx
Offline
Pages: 1