Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Olivier Sannier wrote: Thanks for the information. I did moved to v6 and had to adapt a few things (would have been nice if Disposed in TIcsWndControl had been protected and not private) but it did not help at first. Why? Because as soon as all connected clients would disconnect, the handle allocated for them would be released. And the next time a client comes in, the handle cannot be created anymore because the Indy part of the process has taken it. How comes that this part grabs any handle and does not cause an 'out of handles' error itself? Do you use a thread pool that never shrinks? How many client connections are served when the error happens? What I did was to instantiate a dummy TIcsWndControl component per message pump thread instance, attach it to the thread and only release it when the thread ends. Then I made the threads start at the beginning of the process instead of on demand. There are only two of those threads, so that's not too much of a hassle. This way the handle is created at the very start, when there are still handles left for the process and is never released even if all clients disconnect. Note that I created a dummy TIcsWndControl instance as it seems the easiest way to do keep the handle opened, if you know of a better way, please let me know. It's a workaround only, since one hidden window can handle a maximum number of const WH_MAX_MSG = 100 registered message IDs only, hence it won't prevent ICS from creating new hidden windows on demand depending on the number of concurrent client instances. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Arno Garrels wrote: Olivier Sannier wrote: Thanks for the information. I did moved to v6 and had to adapt a few things (would have been nice if Disposed in TIcsWndControl had been protected and not private) but it did not help at first. Why? Because as soon as all connected clients would disconnect, the handle allocated for them would be released. And the next time a client comes in, the handle cannot be created anymore because the Indy part of the process has taken it. How comes that this part grabs any handle and does not cause an 'out of handles' error itself? Do you use a thread pool that never shrinks? How many client connections are served when the error happens? I don't know, I'm not a good expert at Indy, but it very much looks like it is using up threads and handles at an incredible rate. When the error occurs, about 70 clients are currently served but at least a thousand have been since the start of the process. What I did was to instantiate a dummy TIcsWndControl component per message pump thread instance, attach it to the thread and only release it when the thread ends. Then I made the threads start at the beginning of the process instead of on demand. There are only two of those threads, so that's not too much of a hassle. This way the handle is created at the very start, when there are still handles left for the process and is never released even if all clients disconnect. Note that I created a dummy TIcsWndControl instance as it seems the easiest way to do keep the handle opened, if you know of a better way, please let me know. It's a workaround only, since one hidden window can handle a maximum number of const WH_MAX_MSG = 100 registered message IDs only, hence it won't prevent ICS from creating new hidden windows on demand depending on the number of concurrent client instances. Yes, I noticed that as well. But what I don't understand is the need to allocate the messages everytime a socket is created. I mean, there are the same messages, used for the same thing. What's the point in registering and unregistering them over and over again? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Olivier Sannier wrote: It's a workaround only, since one hidden window can handle a maximum number of const WH_MAX_MSG = 100 registered message IDs only, hence it won't prevent ICS from creating new hidden windows on demand depending on the number of concurrent client instances. Yes, I noticed that as well. But what I don't understand is the need to allocate the messages everytime a socket is created. I mean, there are the same messages, used for the same thing. What's the point in registering and unregistering them over and over again? It's required since multiple instances share the same window, the message IDs must be unique otherwise they couldn't be mapped to the right destination instance. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Olivier Sannier wrote: Arno Garrels wrote: Fastream Technologies wrote: Upgrading might be simpler than you think. Just rename ICSv5 folder, unzip and install v6 package and then rename all ICS unit names so that they start with OverbyteIcs Indeed it is easy, however if you have derived classes with overidden WndProc-methods and custom messages it's a little bit more complicated than just to rename unit names in the uses clause. Please read the comments in OverbyteIcsWndControl.pas. Thanks for the information. I did moved to v6 and had to adapt a few things (would have been nice if Disposed in TIcsWndControl had been protected and not private) but it did not help at first. Why? Because as soon as all connected clients would disconnect, the handle allocated for them would be released. And the next time a client comes in, the handle cannot be created anymore because the Indy part of the process has taken it. What I did was to instantiate a dummy TIcsWndControl component per message pump thread instance, attach it to the thread and only release it when the thread ends. Then I made the threads start at the beginning of the process instead of on demand. There are only two of those threads, so that's not too much of a hassle. This way the handle is created at the very start, when there are still handles left for the process and is never released even if all clients disconnect. Note that I created a dummy TIcsWndControl instance as it seems the easiest way to do keep the handle opened, if you know of a better way, please let me know. Anyone? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Arno Garrels wrote: Fastream Technologies wrote: Upgrading might be simpler than you think. Just rename ICSv5 folder, unzip and install v6 package and then rename all ICS unit names so that they start with OverbyteIcs Indeed it is easy, however if you have derived classes with overidden WndProc-methods and custom messages it's a little bit more complicated than just to rename unit names in the uses clause. Please read the comments in OverbyteIcsWndControl.pas. Thanks for the information. I did moved to v6 and had to adapt a few things (would have been nice if Disposed in TIcsWndControl had been protected and not private) but it did not help at first. Why? Because as soon as all connected clients would disconnect, the handle allocated for them would be released. And the next time a client comes in, the handle cannot be created anymore because the Indy part of the process has taken it. What I did was to instantiate a dummy TIcsWndControl component per message pump thread instance, attach it to the thread and only release it when the thread ends. Then I made the threads start at the beginning of the process instead of on demand. There are only two of those threads, so that's not too much of a hassle. This way the handle is created at the very start, when there are still handles left for the process and is never released even if all clients disconnect. Note that I created a dummy TIcsWndControl instance as it seems the easiest way to do keep the handle opened, if you know of a better way, please let me know. Regards Olivier -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
DZ-Jay wrote: On May 26, 2008, at 09:55, Arno Garrels wrote: There is a maximum number of user handles, per-process (default 1), and system-wide (AFAIK $), so this error seems perfectly OK. Maybe your application leaks handles? If not, you may want to try to increase the maximum number of user handles in the registry here (untested): HKLM/Software/Microsoft/Windows NT/CurrentVersion/Windows/USERProcessHandleQuota Also move to ICS v6 that shares hidden windows, thus allocates far less handles under heavy load. I saw this problem once. It turned out that the message queue was not being pumped for all handles, and it caused the message queue for the process to max out (10,000 messages, I think). Make sure that in your custom message pump you are addressing all threads and all window handles you have created. In my case, I had the message pump of one thread mistakenly reading only messages for a specific handle (using a non-zero handle when calling GetMessage() function). I hadn't noticed that the thread was receiving other messages and they were accumulating and filling up the queue. I fixed this by changing the GetMessage() call to receive all thread messages, handling the ones I needed to handle, and calling the default WndProc for the rest (or something like that -- it's been a while). dZ. Thanks for these details, but I was already pumping out all messages regardless of the handle. But it was nice knowing this information as well. Olivier -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
On May 26, 2008, at 09:55, Arno Garrels wrote: There is a maximum number of user handles, per-process (default 1), and system-wide (AFAIK $), so this error seems perfectly OK. Maybe your application leaks handles? If not, you may want to try to increase the maximum number of user handles in the registry here (untested): HKLM/Software/Microsoft/Windows NT/CurrentVersion/Windows/USERProcessHandleQuota Also move to ICS v6 that shares hidden windows, thus allocates far less handles under heavy load. I saw this problem once. It turned out that the message queue was not being pumped for all handles, and it caused the message queue for the process to max out (10,000 messages, I think). Make sure that in your custom message pump you are addressing all threads and all window handles you have created. In my case, I had the message pump of one thread mistakenly reading only messages for a specific handle (using a non-zero handle when calling GetMessage() function). I hadn't noticed that the thread was receiving other messages and they were accumulating and filling up the queue. I fixed this by changing the GetMessage() call to receive all thread messages, handling the ones I needed to handle, and calling the default WndProc for the rest (or something like that -- it's been a while). dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Hi, ICSv6 beta is stable. We have been using it since 2006 and our customers are fully taking advantage of it with hundreds of GBs of serving in months of running... Upgrading might be simpler than you think. Just rename ICSv5 folder, unzip and install v6 package and then rename all ICS unit names so that they start with OverbyteIcs Best Regards, SZ On Mon, May 26, 2008 at 4:46 PM, Olivier Sannier [EMAIL PROTECTED] wrote: Because all my development was made with v5, that I do not want to move to v6 right now as it is still a beta, and that I think there must be something I did wrong to get this error message. Sure, it would be nice to use v6, but it's not possible right now. Fastream Technologies wrote: Hi, Why don't you upgrade to v6? It was designed for sharing hidden Windows. Best Regards, SZ On Mon, May 26, 2008 at 3:23 PM, Olivier Sannier [EMAIL PROTECTED] wrote: Hi all, I have a server here with parts of it written using Indy and parts of it written using ICS. The two parts are distinct, listen on different ports and do not share any resources. Basically, I'm looking at replacing Indy with ICS and would like to have both technologies in one service to be able to connect to one or the other at will. On my development machine this works just fine, just the same as it works fine on our test environment. However, when put on a production server where most of the clients connect to the Indy port, I'm seeing something very annoying when connecting to the ICS port. Here is what happens on a working connection: I connect using Telnet to the port I type garbage The server replies to me and closes the connection because I did not send the right command However, after about ten minutes, here is what happens: I connect using Telnet to the port I type garbage No reply ever comes from the server, no matter the amount of garbage I send. I went further and traced it to the XSocketAllocateHWnd method that returns 0 when called from the TCustomWSocket.Create constructor for my client class. Using GetLastError, I get the following message after the failure of the call to CreateWindowEx: Espace insuffisant pour traiter cette commande which in English should be the equivalent of Not enough storage to complete this command And once this error has happened, the server stops working unless I restart the process. In turn, this triggers an aexception in TCustomWSocket.AllocateSocketHWnd with the following call stack: Exception raised: ESocketException, Cannot create a hidden window for TWSocket. Exception address: 0239F906 --- Stack list [0239F901] WSocket.TCustomWSocket.RaiseException (Line 1867, WSocket.pas + 4) + $E [023A15C2] WSocket.TCustomWSocket.AllocateSocketHWnd (Line 3573, WSocket.pas + 11) + $9 [023A171B] WSocket.TCustomWSocket.Create (Line 3646, WSocket.pas + 3) + $5 [023A831D] WSocket.TCustomLineWSocket.Create (Line 6847, WSocket.pas + 1) + $4 [0239AE8F] MyServer.TMyClientSocket.Create (Line 545, uROIcsAsyncSuperTcpServer.pas + 2) + $5 [0239D4C1] WSocketS.TCustomWSocketServer.TriggerSessionAvailable (Line 367, WSocketS.pas + 22) + $A [023A25A8] WSocket.TCustomWSocket.Do_FD_ACCEPT (Line 4342, WSocket.pas + 2) + $8 [023A29F9] WSocket.TCustomWSocket.WMASyncSelect (Line 4460, WSocket.pas + 88) + $6 [023A0CE5] WSocket.TCustomWSocket.WndProc (Line 3291, WSocket.pas + 7) + $5 [023A8452] WSocket.TCustomLineWSocket.WndProc (Line 6882, WSocket.pas + 14) + $5 [0239D2C1] WSocketS.TCustomWSocketServer.WndProc (Line 314, WSocketS.pas + 14) + $5 [0239A810] MyServer.TMyWSocketServer.WndProc (Line 400, uROIcsAsyncSuperTcpServer.pas + 6) + $4 [023A1137] WSocket.XSocketWindowProc (Line 3362, WSocket.pas + 14) + $7 [0239C1CF] MyServer.TMessagePumpThread.Execute (Line 1006, uROIcsAsyncSuperTcpServer.pas + 12) + $4 [00430A96] Classes.ThreadProc (Line 9866, classes.pas + 7) + $5 [00405450] System.ThreadWrapper (Line 12127, system.pas + 33) + $0 As you can see, I'm using my own message pump because all this is implemented in a service that has no GUI whatsoever. I don't think this can be the problem and in the end, I can't figure out why creating a window would return this type of error. I mean, I can start other processes just fine. To me, this looks like the side effect of some other problem, but I can't figure out which. Any help is most welcome Cheers Olivier -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Hello Olivier, I went further and traced it to the XSocketAllocateHWnd method that returns 0 when called from the TCustomWSocket.Create constructor for my client class. There is a maximum number of user handles, per-process (default 1), and system-wide (AFAIK $), so this error seems perfectly OK. Maybe your application leaks handles? If not, you may want to try to increase the maximum number of user handles in the registry here (untested): HKLM/Software/Microsoft/Windows NT/CurrentVersion/Windows/USERProcessHandleQuota Also move to ICS v6 that shares hidden windows, thus allocates far less handles under heavy load. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Because all my development was made with v5, that I do not want to move to v6 right now as it is still a beta, and that I think there must be something I did wrong to get this error message. Sure, it would be nice to use v6, but it's not possible right now. Fastream Technologies wrote: Hi, Why don't you upgrade to v6? It was designed for sharing hidden Windows. Best Regards, SZ On Mon, May 26, 2008 at 3:23 PM, Olivier Sannier [EMAIL PROTECTED] wrote: Hi all, I have a server here with parts of it written using Indy and parts of it written using ICS. The two parts are distinct, listen on different ports and do not share any resources. Basically, I'm looking at replacing Indy with ICS and would like to have both technologies in one service to be able to connect to one or the other at will. On my development machine this works just fine, just the same as it works fine on our test environment. However, when put on a production server where most of the clients connect to the Indy port, I'm seeing something very annoying when connecting to the ICS port. Here is what happens on a working connection: I connect using Telnet to the port I type garbage The server replies to me and closes the connection because I did not send the right command However, after about ten minutes, here is what happens: I connect using Telnet to the port I type garbage No reply ever comes from the server, no matter the amount of garbage I send. I went further and traced it to the XSocketAllocateHWnd method that returns 0 when called from the TCustomWSocket.Create constructor for my client class. Using GetLastError, I get the following message after the failure of the call to CreateWindowEx: Espace insuffisant pour traiter cette commande which in English should be the equivalent of Not enough storage to complete this command And once this error has happened, the server stops working unless I restart the process. In turn, this triggers an aexception in TCustomWSocket.AllocateSocketHWnd with the following call stack: Exception raised: ESocketException, Cannot create a hidden window for TWSocket. Exception address: 0239F906 --- Stack list [0239F901] WSocket.TCustomWSocket.RaiseException (Line 1867, WSocket.pas + 4) + $E [023A15C2] WSocket.TCustomWSocket.AllocateSocketHWnd (Line 3573, WSocket.pas + 11) + $9 [023A171B] WSocket.TCustomWSocket.Create (Line 3646, WSocket.pas + 3) + $5 [023A831D] WSocket.TCustomLineWSocket.Create (Line 6847, WSocket.pas + 1) + $4 [0239AE8F] MyServer.TMyClientSocket.Create (Line 545, uROIcsAsyncSuperTcpServer.pas + 2) + $5 [0239D4C1] WSocketS.TCustomWSocketServer.TriggerSessionAvailable (Line 367, WSocketS.pas + 22) + $A [023A25A8] WSocket.TCustomWSocket.Do_FD_ACCEPT (Line 4342, WSocket.pas + 2) + $8 [023A29F9] WSocket.TCustomWSocket.WMASyncSelect (Line 4460, WSocket.pas + 88) + $6 [023A0CE5] WSocket.TCustomWSocket.WndProc (Line 3291, WSocket.pas + 7) + $5 [023A8452] WSocket.TCustomLineWSocket.WndProc (Line 6882, WSocket.pas + 14) + $5 [0239D2C1] WSocketS.TCustomWSocketServer.WndProc (Line 314, WSocketS.pas + 14) + $5 [0239A810] MyServer.TMyWSocketServer.WndProc (Line 400, uROIcsAsyncSuperTcpServer.pas + 6) + $4 [023A1137] WSocket.XSocketWindowProc (Line 3362, WSocket.pas + 14) + $7 [0239C1CF] MyServer.TMessagePumpThread.Execute (Line 1006, uROIcsAsyncSuperTcpServer.pas + 12) + $4 [00430A96] Classes.ThreadProc (Line 9866, classes.pas + 7) + $5 [00405450] System.ThreadWrapper (Line 12127, system.pas + 33) + $0 As you can see, I'm using my own message pump because all this is implemented in a service that has no GUI whatsoever. I don't think this can be the problem and in the end, I can't figure out why creating a window would return this type of error. I mean, I can start other processes just fine. To me, this looks like the side effect of some other problem, but I can't figure out which. Any help is most welcome Cheers Olivier -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] Not enough storage error in XSocketAllocateHWnd
Hi all, I have a server here with parts of it written using Indy and parts of it written using ICS. The two parts are distinct, listen on different ports and do not share any resources. Basically, I'm looking at replacing Indy with ICS and would like to have both technologies in one service to be able to connect to one or the other at will. On my development machine this works just fine, just the same as it works fine on our test environment. However, when put on a production server where most of the clients connect to the Indy port, I'm seeing something very annoying when connecting to the ICS port. Here is what happens on a working connection: I connect using Telnet to the port I type garbage The server replies to me and closes the connection because I did not send the right command However, after about ten minutes, here is what happens: I connect using Telnet to the port I type garbage No reply ever comes from the server, no matter the amount of garbage I send. I went further and traced it to the XSocketAllocateHWnd method that returns 0 when called from the TCustomWSocket.Create constructor for my client class. Using GetLastError, I get the following message after the failure of the call to CreateWindowEx: Espace insuffisant pour traiter cette commande which in English should be the equivalent of Not enough storage to complete this command And once this error has happened, the server stops working unless I restart the process. In turn, this triggers an aexception in TCustomWSocket.AllocateSocketHWnd with the following call stack: Exception raised: ESocketException, Cannot create a hidden window for TWSocket. Exception address: 0239F906 --- Stack list [0239F901] WSocket.TCustomWSocket.RaiseException (Line 1867, WSocket.pas + 4) + $E [023A15C2] WSocket.TCustomWSocket.AllocateSocketHWnd (Line 3573, WSocket.pas + 11) + $9 [023A171B] WSocket.TCustomWSocket.Create (Line 3646, WSocket.pas + 3) + $5 [023A831D] WSocket.TCustomLineWSocket.Create (Line 6847, WSocket.pas + 1) + $4 [0239AE8F] MyServer.TMyClientSocket.Create (Line 545, uROIcsAsyncSuperTcpServer.pas + 2) + $5 [0239D4C1] WSocketS.TCustomWSocketServer.TriggerSessionAvailable (Line 367, WSocketS.pas + 22) + $A [023A25A8] WSocket.TCustomWSocket.Do_FD_ACCEPT (Line 4342, WSocket.pas + 2) + $8 [023A29F9] WSocket.TCustomWSocket.WMASyncSelect (Line 4460, WSocket.pas + 88) + $6 [023A0CE5] WSocket.TCustomWSocket.WndProc (Line 3291, WSocket.pas + 7) + $5 [023A8452] WSocket.TCustomLineWSocket.WndProc (Line 6882, WSocket.pas + 14) + $5 [0239D2C1] WSocketS.TCustomWSocketServer.WndProc (Line 314, WSocketS.pas + 14) + $5 [0239A810] MyServer.TMyWSocketServer.WndProc (Line 400, uROIcsAsyncSuperTcpServer.pas + 6) + $4 [023A1137] WSocket.XSocketWindowProc (Line 3362, WSocket.pas + 14) + $7 [0239C1CF] MyServer.TMessagePumpThread.Execute (Line 1006, uROIcsAsyncSuperTcpServer.pas + 12) + $4 [00430A96] Classes.ThreadProc (Line 9866, classes.pas + 7) + $5 [00405450] System.ThreadWrapper (Line 12127, system.pas + 33) + $0 As you can see, I'm using my own message pump because all this is implemented in a service that has no GUI whatsoever. I don't think this can be the problem and in the end, I can't figure out why creating a window would return this type of error. I mean, I can start other processes just fine. To me, this looks like the side effect of some other problem, but I can't figure out which. Any help is most welcome Cheers Olivier -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Yes, Arno is right, I forgot that even though we did those overriding in our codes. Sorry. Regards, SZ On Mon, May 26, 2008 at 6:00 PM, Arno Garrels [EMAIL PROTECTED] wrote: Fastream Technologies wrote: Upgrading might be simpler than you think. Just rename ICSv5 folder, unzip and install v6 package and then rename all ICS unit names so that they start with OverbyteIcs Indeed it is easy, however if you have derived classes with overidden WndProc-methods and custom messages it's a little bit more complicated than just to rename unit names in the uses clause. Please read the comments in OverbyteIcsWndControl.pas. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html Best Regards, SZ On Mon, May 26, 2008 at 4:46 PM, Olivier Sannier [EMAIL PROTECTED] wrote: Because all my development was made with v5, that I do not want to move to v6 right now as it is still a beta, and that I think there must be something I did wrong to get this error message. Sure, it would be nice to use v6, but it's not possible right now. Fastream Technologies wrote: Hi, Why don't you upgrade to v6? It was designed for sharing hidden Windows. Best Regards, SZ On Mon, May 26, 2008 at 3:23 PM, Olivier Sannier [EMAIL PROTECTED] wrote: Hi all, I have a server here with parts of it written using Indy and parts of it written using ICS. The two parts are distinct, listen on different ports and do not share any resources. Basically, I'm looking at replacing Indy with ICS and would like to have both technologies in one service to be able to connect to one or the other at will. On my development machine this works just fine, just the same as it works fine on our test environment. However, when put on a production server where most of the clients connect to the Indy port, I'm seeing something very annoying when connecting to the ICS port. Here is what happens on a working connection: I connect using Telnet to the port I type garbage The server replies to me and closes the connection because I did not send the right command However, after about ten minutes, here is what happens: I connect using Telnet to the port I type garbage No reply ever comes from the server, no matter the amount of garbage I send. I went further and traced it to the XSocketAllocateHWnd method that returns 0 when called from the TCustomWSocket.Create constructor for my client class. Using GetLastError, I get the following message after the failure of the call to CreateWindowEx: Espace insuffisant pour traiter cette commande which in English should be the equivalent of Not enough storage to complete this command And once this error has happened, the server stops working unless I restart the process. In turn, this triggers an aexception in TCustomWSocket.AllocateSocketHWnd with the following call stack: Exception raised: ESocketException, Cannot create a hidden window for TWSocket. Exception address: 0239F906 --- Stack list [0239F901] WSocket.TCustomWSocket.RaiseException (Line 1867, WSocket.pas + 4) + $E [023A15C2] WSocket.TCustomWSocket.AllocateSocketHWnd (Line 3573, WSocket.pas + 11) + $9 [023A171B] WSocket.TCustomWSocket.Create (Line 3646, WSocket.pas + 3) + $5 [023A831D] WSocket.TCustomLineWSocket.Create (Line 6847, WSocket.pas + 1) + $4 [0239AE8F] MyServer.TMyClientSocket.Create (Line 545, uROIcsAsyncSuperTcpServer.pas + 2) + $5 [0239D4C1] WSocketS.TCustomWSocketServer.TriggerSessionAvailable (Line 367, WSocketS.pas + 22) + $A [023A25A8] WSocket.TCustomWSocket.Do_FD_ACCEPT (Line 4342, WSocket.pas + 2) + $8 [023A29F9] WSocket.TCustomWSocket.WMASyncSelect (Line 4460, WSocket.pas + 88) + $6 [023A0CE5] WSocket.TCustomWSocket.WndProc (Line 3291, WSocket.pas + 7) + $5 [023A8452] WSocket.TCustomLineWSocket.WndProc (Line 6882, WSocket.pas + 14) + $5 [0239D2C1] WSocketS.TCustomWSocketServer.WndProc (Line 314, WSocketS.pas + 14) + $5 [0239A810] MyServer.TMyWSocketServer.WndProc (Line 400, uROIcsAsyncSuperTcpServer.pas + 6) + $4 [023A1137] WSocket.XSocketWindowProc (Line 3362, WSocket.pas + 14) + $7 [0239C1CF] MyServer.TMessagePumpThread.Execute (Line 1006, uROIcsAsyncSuperTcpServer.pas + 12) + $4 [00430A96] Classes.ThreadProc (Line 9866, classes.pas + 7) + $5 [00405450] System.ThreadWrapper (Line 12127, system.pas + 33) + $0 As you can see, I'm using my own message pump because all this is implemented in a service that has no GUI whatsoever. I don't think this can be the problem and in the end, I can't figure out why creating a window would return this type of error. I mean, I can start other processes just fine. To me, this looks like the side effect of some other problem, but I can't figure out which. Any help is most welcome Cheers Olivier -- To unsubscribe or change your settings for TWSocket mailing
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Hi, Why don't you upgrade to v6? It was designed for sharing hidden Windows. Best Regards, SZ On Mon, May 26, 2008 at 3:23 PM, Olivier Sannier [EMAIL PROTECTED] wrote: Hi all, I have a server here with parts of it written using Indy and parts of it written using ICS. The two parts are distinct, listen on different ports and do not share any resources. Basically, I'm looking at replacing Indy with ICS and would like to have both technologies in one service to be able to connect to one or the other at will. On my development machine this works just fine, just the same as it works fine on our test environment. However, when put on a production server where most of the clients connect to the Indy port, I'm seeing something very annoying when connecting to the ICS port. Here is what happens on a working connection: I connect using Telnet to the port I type garbage The server replies to me and closes the connection because I did not send the right command However, after about ten minutes, here is what happens: I connect using Telnet to the port I type garbage No reply ever comes from the server, no matter the amount of garbage I send. I went further and traced it to the XSocketAllocateHWnd method that returns 0 when called from the TCustomWSocket.Create constructor for my client class. Using GetLastError, I get the following message after the failure of the call to CreateWindowEx: Espace insuffisant pour traiter cette commande which in English should be the equivalent of Not enough storage to complete this command And once this error has happened, the server stops working unless I restart the process. In turn, this triggers an aexception in TCustomWSocket.AllocateSocketHWnd with the following call stack: Exception raised: ESocketException, Cannot create a hidden window for TWSocket. Exception address: 0239F906 --- Stack list [0239F901] WSocket.TCustomWSocket.RaiseException (Line 1867, WSocket.pas + 4) + $E [023A15C2] WSocket.TCustomWSocket.AllocateSocketHWnd (Line 3573, WSocket.pas + 11) + $9 [023A171B] WSocket.TCustomWSocket.Create (Line 3646, WSocket.pas + 3) + $5 [023A831D] WSocket.TCustomLineWSocket.Create (Line 6847, WSocket.pas + 1) + $4 [0239AE8F] MyServer.TMyClientSocket.Create (Line 545, uROIcsAsyncSuperTcpServer.pas + 2) + $5 [0239D4C1] WSocketS.TCustomWSocketServer.TriggerSessionAvailable (Line 367, WSocketS.pas + 22) + $A [023A25A8] WSocket.TCustomWSocket.Do_FD_ACCEPT (Line 4342, WSocket.pas + 2) + $8 [023A29F9] WSocket.TCustomWSocket.WMASyncSelect (Line 4460, WSocket.pas + 88) + $6 [023A0CE5] WSocket.TCustomWSocket.WndProc (Line 3291, WSocket.pas + 7) + $5 [023A8452] WSocket.TCustomLineWSocket.WndProc (Line 6882, WSocket.pas + 14) + $5 [0239D2C1] WSocketS.TCustomWSocketServer.WndProc (Line 314, WSocketS.pas + 14) + $5 [0239A810] MyServer.TMyWSocketServer.WndProc (Line 400, uROIcsAsyncSuperTcpServer.pas + 6) + $4 [023A1137] WSocket.XSocketWindowProc (Line 3362, WSocket.pas + 14) + $7 [0239C1CF] MyServer.TMessagePumpThread.Execute (Line 1006, uROIcsAsyncSuperTcpServer.pas + 12) + $4 [00430A96] Classes.ThreadProc (Line 9866, classes.pas + 7) + $5 [00405450] System.ThreadWrapper (Line 12127, system.pas + 33) + $0 As you can see, I'm using my own message pump because all this is implemented in a service that has no GUI whatsoever. I don't think this can be the problem and in the end, I can't figure out why creating a window would return this type of error. I mean, I can start other processes just fine. To me, this looks like the side effect of some other problem, but I can't figure out which. Any help is most welcome Cheers Olivier -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Not enough storage error in XSocketAllocateHWnd
Fastream Technologies wrote: Upgrading might be simpler than you think. Just rename ICSv5 folder, unzip and install v6 package and then rename all ICS unit names so that they start with OverbyteIcs Indeed it is easy, however if you have derived classes with overidden WndProc-methods and custom messages it's a little bit more complicated than just to rename unit names in the uses clause. Please read the comments in OverbyteIcsWndControl.pas. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html Best Regards, SZ On Mon, May 26, 2008 at 4:46 PM, Olivier Sannier [EMAIL PROTECTED] wrote: Because all my development was made with v5, that I do not want to move to v6 right now as it is still a beta, and that I think there must be something I did wrong to get this error message. Sure, it would be nice to use v6, but it's not possible right now. Fastream Technologies wrote: Hi, Why don't you upgrade to v6? It was designed for sharing hidden Windows. Best Regards, SZ On Mon, May 26, 2008 at 3:23 PM, Olivier Sannier [EMAIL PROTECTED] wrote: Hi all, I have a server here with parts of it written using Indy and parts of it written using ICS. The two parts are distinct, listen on different ports and do not share any resources. Basically, I'm looking at replacing Indy with ICS and would like to have both technologies in one service to be able to connect to one or the other at will. On my development machine this works just fine, just the same as it works fine on our test environment. However, when put on a production server where most of the clients connect to the Indy port, I'm seeing something very annoying when connecting to the ICS port. Here is what happens on a working connection: I connect using Telnet to the port I type garbage The server replies to me and closes the connection because I did not send the right command However, after about ten minutes, here is what happens: I connect using Telnet to the port I type garbage No reply ever comes from the server, no matter the amount of garbage I send. I went further and traced it to the XSocketAllocateHWnd method that returns 0 when called from the TCustomWSocket.Create constructor for my client class. Using GetLastError, I get the following message after the failure of the call to CreateWindowEx: Espace insuffisant pour traiter cette commande which in English should be the equivalent of Not enough storage to complete this command And once this error has happened, the server stops working unless I restart the process. In turn, this triggers an aexception in TCustomWSocket.AllocateSocketHWnd with the following call stack: Exception raised: ESocketException, Cannot create a hidden window for TWSocket. Exception address: 0239F906 --- Stack list [0239F901] WSocket.TCustomWSocket.RaiseException (Line 1867, WSocket.pas + 4) + $E [023A15C2] WSocket.TCustomWSocket.AllocateSocketHWnd (Line 3573, WSocket.pas + 11) + $9 [023A171B] WSocket.TCustomWSocket.Create (Line 3646, WSocket.pas + 3) + $5 [023A831D] WSocket.TCustomLineWSocket.Create (Line 6847, WSocket.pas + 1) + $4 [0239AE8F] MyServer.TMyClientSocket.Create (Line 545, uROIcsAsyncSuperTcpServer.pas + 2) + $5 [0239D4C1] WSocketS.TCustomWSocketServer.TriggerSessionAvailable (Line 367, WSocketS.pas + 22) + $A [023A25A8] WSocket.TCustomWSocket.Do_FD_ACCEPT (Line 4342, WSocket.pas + 2) + $8 [023A29F9] WSocket.TCustomWSocket.WMASyncSelect (Line 4460, WSocket.pas + 88) + $6 [023A0CE5] WSocket.TCustomWSocket.WndProc (Line 3291, WSocket.pas + 7) + $5 [023A8452] WSocket.TCustomLineWSocket.WndProc (Line 6882, WSocket.pas + 14) + $5 [0239D2C1] WSocketS.TCustomWSocketServer.WndProc (Line 314, WSocketS.pas + 14) + $5 [0239A810] MyServer.TMyWSocketServer.WndProc (Line 400, uROIcsAsyncSuperTcpServer.pas + 6) + $4 [023A1137] WSocket.XSocketWindowProc (Line 3362, WSocket.pas + 14) + $7 [0239C1CF] MyServer.TMessagePumpThread.Execute (Line 1006, uROIcsAsyncSuperTcpServer.pas + 12) + $4 [00430A96] Classes.ThreadProc (Line 9866, classes.pas + 7) + $5 [00405450] System.ThreadWrapper (Line 12127, system.pas + 33) + $0 As you can see, I'm using my own message pump because all this is implemented in a service that has no GUI whatsoever. I don't think this can be the problem and in the end, I can't figure out why creating a window would return this type of error. I mean, I can start other processes just fine. To me, this looks like the side effect of some other problem, but I can't figure out which. Any help is most welcome Cheers Olivier -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
