merijnb

Hmm, I just found this comment on this thread: Are these changes related to my question?

Hello all, I'm using a TSslWebSocketCli and I'm currently testing what happens when the websocket connection cannot be created. I can use a situation where the server has a maximum number of connections allowed. See this snippet: fWSClient := TSslWebSocketCli.Create(nil); fWSClient.OnWSConnected := WSConnected; fWSClient.OnWSDisconnected := WSDisconnected; fWSClient.OnWSFrameRcvd := WSFrameRcvd; fWSClient.OnHTTPRestProg := WSHTTPRestProg; fWSClient.OnRestRequestDone := WSHTTPRequestDone; // ... fWSClient.URL := 'someurl'; fWSClient.WSConnect(true); // True = async When making this connection, I get log through the OnHTTPRestProg event saying: " Request completed: 503 Number of active WebSocket requests has reached the maximum concurrent WebSocket requests allowed." However, I don't see how I properly detect this issue is going on. OnWSConnected and OnWSDisconnected aren't called in this case. I do get OnRetRequestDone, but it doesn't contain the error code (503). What is the best way to detect this is going on?

{ user may check and close connection in event handler, log stuff, etc } TriggerClientConnect(Client, Error); { The event handler may have destroyed the client ! } if FClientList.IndexOf(Client) < 0 then begin Client.Free; { V9.5 } Exit; end; This is a snippet from OverbyteIcsWSocketS from the method TCustomWSocketServer.TriggerSessionAvailable. The line Client.Free is added in 9.5 (as seen in the comments for that line). Was this intended? If the client actually is freed in TriggerClientConnect(), it is removed from FClientList (in TCustomWSocketServer.Notification), which means this call op Client.Free will be on an object which is already freed.

Hey all, See this function in OverbyteIcsWsocket.pas P should be an PAnsichar here (I'm guessing this function is older then Delphi 2009 and never updated). {* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} function DataToString(Buf : Pointer; Len : Integer) : String; var P : PChar; begin P := PChar(Buf); Result := ''; while Len > 0 do begin if Word(P^) in [Ord(#32)..Ord(#126)] then Result := Result + P^ else Result := Result + '$' + IntToHex(Ord(P^), 2) + ' '; Inc(P); Dec(Len); end; end;

Well even if they are part of the problem, it might be to deep in the call stack to make sense. If most of the time goes to allocating memory, I'd like to know which parts of my code is allocating memory. I can look at all the calls tot GetMem and check their callstacks, but I'd rather just filter out system.pas overall. V-Tune does know which unit the call came from, so I'm surprised that it doesn't seem possible to filter in that way?

Inspired by @Stefan Glienke's talk on the Delphi Summit in Amsterdam I've tried using the v-tune profiler. We had a performance issue and solved it, and I tried using that case to 'reverse test' using v-tune. In other words, I already know what the issue was, how could I have found this using v-tune? The issue I'm running into is that there is too much noise to see what I'm looking for, I understand that (for example) EurekaGetMem (from Eurekalog) is called many times, but that's -at this point- not interesting to me. I'd like to filter on certain source files, like tell me what took the most times if you only look at the code I've written, nothing from Delphi, Eurekalog, FastMM, etc. Is this possible?

While updating to 12 I found out this feature request is still open, so I patched my GX_OtaUtils and build a new DLL locally. Can I get these changes into the trunk somehow for the future? I've attached a the newly patched version on sourceforge again.

@Brian Evans I use cnpack next to gexperts, but have been doing so for years, so no idea why that would be a problem now. Also, the keys don't actually seem to do something when gexperts can't use time. I understand @dummzeuch proposal is the easiest solution, for me currently also the least desired one though 🙂 I'll keep poking to see if I can find the cause.

I don't think this is a gexperts problem, but this might be the best place to look for info. Since upgrading to 11, the shortcut keys to previous and next identifier reference (ctrl alt up and ctrl alt down) keep breaking. When I look in the configuration, they're still there and when I reset them (as in, set them again), they work again, after a reboot it's broken again. Anyone a tip how to solve this?

I can't find it where, but somewhere I read Embarcadero accepted this being a bug in the IDE, I hope it's fixed soon because it's really annoying.

Hey Angus, I have no need for the name (I wondered why it was set), the reason THttpAppSrv doesn't have this error is because the class definition is not part of another class definition.

I just noticed the title of this thread isn't what it's supposed to be, it should be bug in OverbyteIcsHttpSrv.THttpServer.Create 🙂

One of the first things the constructor of THttpServer does is setting FName of FWSocketServer, using the current ClassName as a basis: constructor THttpServer.Create(AOwner: TComponent); begin inherited Create(AOwner); CreateSocket; {$IFDEF NO_ADV_MT} FWSocketServer.Name := ClassName + '_SrvSocket' + IntToStr(WSocketGCount); {$ELSE} FWSocketServer.Name := ClassName + '_SrvSocket' + IntToStr(SafeWSocketGCount); The name of a component can only consist of 'A'..'Z', 'a'..'z', '_', '0'..'9' as can been seen in System.SysUtils.IsValidIdent() (called from System.SysUtils.TComponent.SetName()) If you define a class, overriding form THttpServer as part of another class: type TMyClass = class(TObject) private type TMyHttpServer = class(THttpServer) The ClassName of TMyHttpServer will become TMyClass.TMyHttpServer, so it contains a dot, hence breaking the constructor of THttpServer. Fix could be to do a StringReplace() to eliminate dots in the constructor: constructor THttpServer.Create(AOwner: TComponent); begin inherited Create(AOwner); CreateSocket; {$IFDEF NO_ADV_MT} FWSocketServer.Name := StringReplace(ClassName + '_SrvSocket' + IntToStr(WSocketGCount), '.', '', [rfReplaceAll]); {$ELSE} FWSocketServer.Name := StringReplace(ClassName + '_SrvSocket' + IntToStr(SafeWSocketGCount), '.', '', [rfReplaceAll]);

I totally agree, unfortunately in this case I don't have any other option.

If I see correctly ReuseAddr isn't used, that means that TFtpClient itself cannot be the cause of reusing a port, you agree? As I said, I have ways around this, this is more to satisfy my curiosity. When you say I'm not using the component properly, what do you mean exactly? It's now allowed to use multiple instances of TFtpClient at the same time? I understand there are ways around this, but is there a technical reason you say this?