You are not logged in.
Pages: 1
ReceiveTimeout doesn't work. I had to manually change the HTTP_DEFAULT_RECEIVETIMEOUT constant in source code.
Check the time elapsed on the server in each method.
Search the doc first for timeout. Use latest 1.18 version.
I could not find anything related to timeout in TSQLHttpClient which I'm using. Are you referring to KeepAliveMS property?
I'm using latest 1.18.
The http.sys kernel-mode HTTP server does not implement chunking by itself.
You can enable logging and find out what takes time in the request.
Sounds to me like if the error comes from the client side.
The error may come from the fact that socket is already closed.Which component are you using on the client?
Please make the timeout value higher on client side.
Since there is no chunking, the client may time out before it receives the whole content.
1. On the client I'm just using the interface to access the server methods.
2. In the http.sys kernel-mode can't you keep sending parts of the body? I believe you can make multiple HttpSendHttpResponseBody calls can't you?
3. How can I increase timeout in client?
4. Logging is already enabled, that's the message I get from log.
Hi, I'm using an interface-based method to execute a server-side SQL and return results. My function is as simple as this:
function Execute(const aSQL: RawUTF8; aExpectResults: boolean; const Params: RawJSON): RawJSON;
This function executes the SQL and returns the full dataset in the RawJSON result parametes. Problem is from time to time I'm having the following error:
EXC EHttpApiServer ("HttpSendHttpResponse failed: The I/O operation has been aborted because of either a thread exit or an application request (995)")
Do you have an idea why this error occurs?
It seems to me that it happens when my dataset result is very big. I'm sure the SQL is executing fast, but maybe mormot is taking too much time in building the rawjson or maybe the data is just too big for the http to handle it?
Can it maybe that mormot sends the result is separated packages, maybe chunked response, etc. (I know DataSnap can do that).
So, unless you have another idea, my guess is this error is happening because the RawJSON result is too big, then my question is: is there a easy way for mormot to handle such big results?
Thanks in advance.
I bet it is, but how do I choose it? When debugging mormot and inspecting variables, it seems there is no compression.
I changed my source code in client with this:
FClient := TSQLHttpClient.Create(AnsiString(Self.Host), AnsiString(IntToStr(Self.Port)), FModel);
FClient.Compression := [hcSynLZ, hcDeflate]; // ADD THIS
Now I see Accept header is being sent in the http request from the client, but I'm trying to debug the server and I don't see a header of Content-Encoding.
Should setting FClient.Compression be enough? Or do I have to do something else on the server, or anywhere else?
I'm using a simple method to execute SQL at server-side (based on the Sample provided):
IRemoteDatabase = interface(IInvokable)
function Execute(const aSQL: RawUTF8; aExpectResults: boolean; const Params: RawJSON): RawJSON;
I'm generating the content of RawJSON parameters using TJSONWriter and reading them using TSQLTableJson.
Are those contents being compressed for transmission, by default? If not, what is the easiest way to do it (especially the function result of course, which is the RawJSON return value).
The problem happens if you open a *different* client after timeout occurs. In the same client, you get the message you mentioned indeed. I will test your fix to see if it solves my problem as well.
By the way, about the message you mentioned: it's expected, yes, if I create a server object and take too much time to use it, it will expire and I get that message. But, what is the correct way to "recreate" the object without having that message? For example, I create an object IFoo on the server and I have the method DoSomething. Then I take too much time (timeout occurs). But nevertheless, my client calls IFoo.DoSomething and I get that message (instance not found). What is the best way to avoid this message and just reinstantiate a client object in case it happens and make DoSomething to run smoothly (reassign a newly created object to the same interface)?
Yes, using 1.18. This mentioned sample doesn't even exist in stable version, and the unit names are totally different. I'm starting a new project, doesn't make much sense to me to use a stable version if I will have to change a lot of things to use the next one.
Anyway, as I said, the sample is only available in version 1.18, so maybe it was never tested?
I'm trying to use interface-based services using sicClientDriven mode, but it seems it's not working.
Once I create an object from the client, the server will stop working after the timeout (server object expires). It's "hard" to get this bug just by testing because the timeout is big (default is 30 min). But it's easy to check if you change the timeout to a value small enough to test (like 15 seconds).
This problem can easily be reproduced using your own sample (sample 16, execute SQL via services). Steps to reproduce:
Using Sample 16:
1. Run the server
2. Run the client, execute some SQL, close the client
3. Wait for the timeout expires (31 minutes, or if you changed mormot source code, any timeout you specified)
4. Run the client again - you get AV on the server.
is this a known bug, a bug in framework, or a bug in the sample? Nevertheless, I can't make my server to be stable, it just crashes after timeout period passed.
Side question, is there a way to define a smaller timeout without changing mormot source code? I had to change this line in mormot.pas:
{TServiceFactoryServer}
constructor Create(aRestServer: TSQLRestServer; aInterface: PTypeInfo;
aInstanceCreation: TServiceInstanceImplementation;
aImplementationClass: TInterfacedClass; const aContractExpected: RawUTF8='';
aTimeOutSec: cardinal=30*60); reintroduce; //<<--- THIS LINE, replaced 30*60 by 15
Pages: 1