It is just like you told me before @rlebeau
Toggles between ReadBytes(8) and ReadBytes(argConn.bufSize)
TIdTCPClient.Connected is not thread safe, I think.
A mutex needs to be added on TIdTCPClient.IoHandler.ReadBytes call in the receive thread and on TIdTCPClient.Connected in the connection thread.
I found that the client receive thread can be aborted by the exception of the calling IoHandler.ReadBytes, then the problem solved.
A mutex needs to be added on TIdTCPClient.IoHandler.ReadBytes call in the receive thread and on TIdTCPClient.Connected in the connection thread.
I found that the client receive thread can be aborted by the exception of the calling IoHandler.ReadBytes, then the problem solved.
If you don't want the thread to terminate, catch the exception
What Is wrong in this implementation?
In the client, I start a receive thread:
--the receive thread in the client:
----TIdTCPClient.IoHandler.ReadBytes
in the server:
--OnExcute:
----AContext.Connection.IoHandler.ReadBytes
If I first start the test transferring of the client sending data of < 80000 bytes to the server 10000 times and then do the same test reverse of the server sending to the client, there is nothing abnormal.
But if I first start the test of the server sending to the client and then the transferring speed becomes very low when do the test of the client sending to the server.
The test is one app sends data in size of < 7kb 100000 times to the other one.
If I never click the Server Send button to start the test of the server sending to the client and just do test the client to the server, it takes about 40~50 seconds in every test.
But if I click the Server Send once, the test of the client to the server sending will take apparently longer time than before.
If I never click the Server Send button to start the test of the server sending to the client and just do test the client to the server, it takes about 40~50 seconds in every test.
But if I click the Server Send once, the test of the client to the server sending will take apparently longer time than before.
Here is the common read write procedure
The client
well, it kind of makes sense, if you take into account that the client code is single-threaded but the server code is multi-threaded, so you are likely getting task switches during the server-to-client sending that are slowing it down compared to the client-to-server sending. Remember, TIdTCPServer runs each client in its own worker thread. Even if there is only 1 client connected, there are still other threads running (the main UI thread, the server's listening thread, etc) that the OS has to service in a timely manner.
So I guess the non-fixed bytes sending causes some threads work so hard in TIdTCPServer if the TIdContext.Connection.IoHandler cached something when Write().
I don't know what elsee to tell you. There is no memory leak in Indy. Plenty of people use Indy for a long time, a leak would have been noticed before. Something else has to be going on in your environment. Maybe your test code is fragmenting memory instead of leaking it. who knows.
The reason I ask is that when using SSL through a proxy, PassThrough is set to True, so it's impossible to catch the EIdOSSLCouldNotLoadSSLLibrary exception
At that stage, OpenSSL is simply being pre-initialized but SSL/TLS is not actually being used yet, and may or may not ever be used depending on the caller's needs, so the exception is silent caught to allow the unencrypted connection to proceed. At a later time, if PassThrough is ever set to false to activate SSL/TLS, then the exception will be raised to the caller. Even through a proxy, PassThrough has to be set to false eventually.
Hy everyone, I'm trying to overwrite a response generated by datasnap (running on TIdHTTPWebBrokerBridge). TDSRESTWebDispatcher sends eventual StatusCode 401 and to hide the annoying browser login window, I want to send StatusCode 403 instead. After trying several DataSnap specific events which show absolutely no effect, I would like to try to intercept the response on the Indy-level.
Is there a nice way to hook into the server response and overwrite every StatusCode of 401 with 403? PS: I have access to an Intercept interface.
Is there a nice way to hook into the server response and overwrite every StatusCode of 401 with 403? PS: I have access to an Intercept interface.
If you don't have access to the actual source that is populating the original HTTP response, you can't really change its behavior. With an Intercept, it might be possible to alter the data as it is being sent, but that would require parsing the HTTP data that passes through the Intercept. The data is arbitrary bytes from the Intercept's perspective, so you would need to write a stateful parser in case you get multiple OnSend events. I would be more inclined to suggest figuring out why DataSnap is sending a 401 reply to begin with and see if there is a way to change that behavior, instead of trying to modify the response data after the fact. Especially since modifying the 401 may break non-browser clients that could have logged in without prompting the user. Why are you using a web browser to access a DataSnap REST server in the first place?
Thank you for the fast answer! I'm writing a AngularJS based browser-only-app and access the backend via the rest interface. And sadly I've found no possibility to circumvent either the browser behavior (showing the login box) or that of datasnap (sending 401 if TDSAuthenticationManager is present but no login/session data).
Or, you could just use TIdHTTPServer directly and implement your own REST logic on top of it
then you can send whatever responses you want
1.1.0 was just officially released a few days ago, and 1.0.2 is not going away for several years. So there is time to migrate Indy to 1.1.0 eventually.