Re: [twsocket] Clarification of my previous question
Hi Arno, If that happens with a fast network connection (LAN) then it's a normal behavior in main, GUI thread since paint messages have less priority than messages actually posted to the message queue. Yes, it's happens on fast 1 GB Lan and very light and fast smtp server on second PC. No firewall or antivirus installed. Program works fine until message size is small (2-3-5-10 kb) and start slowing down since 40-50 kb. And hangs on 1+ mb. Is there any way to increase paint messages priority ? Or process it manually ? Or maybe increase SmtpCli send buffer size to 16384 or 32768 ? In such cases you should move the SMTP task into a worker thread Yes, current version of my main App uses SmtpCli in threads. But I want to move it outside threads and eliminate some problems with synchronization... Thanx for help ! -- 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] Clarification of my previous question
Max Terentiev wrote: Hi Arno, If that happens with a fast network connection (LAN) then it's a normal behavior in main, GUI thread since paint messages have less priority than messages actually posted to the message queue. Yes, it's happens on fast 1 GB Lan and very light and fast smtp server on second PC. No firewall or antivirus installed. Program works fine until message size is small (2-3-5-10 kb) and start slowing down since 40-50 kb. And hangs on 1+ mb. Is there any way to increase paint messages priority ? Or process it manually ? Not really. One could override Application's main message loop but I would not do that. My experience is that any attempt to change the order in which messages are processed leads to problems. Or maybe increase SmtpCli send buffer size to 16384 or 32768 ? It's not the socket send buffer that causes this but the fact that older TSmtpCli sent attachments line by line, means in chunks of around just 78 bytes, this is fixed in newer versions. In such cases you should move the SMTP task into a worker thread Yes, current version of my main App uses SmtpCli in threads. But I want to move it outside threads and eliminate some problems with synchronization... Then only a bandwidth throttle works around the problem. -- 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] Clarification of my previous question
Thanx for help, Arno ! I will try v7/throttle. -Original Message- From: twsocket-boun...@elists.org [mailto:twsocket-boun...@elists.org] On Behalf Of Arno Garrels Sent: Wednesday, November 24, 2010 3:03 PM To: ICS support mailing Subject: Re: [twsocket] Clarification of my previous question Max Terentiev wrote: Hi Arno, If that happens with a fast network connection (LAN) then it's a normal behavior in main, GUI thread since paint messages have less priority than messages actually posted to the message queue. Yes, it's happens on fast 1 GB Lan and very light and fast smtp server on second PC. No firewall or antivirus installed. Program works fine until message size is small (2-3-5-10 kb) and start slowing down since 40-50 kb. And hangs on 1+ mb. Is there any way to increase paint messages priority ? Or process it manually ? Not really. One could override Application's main message loop but I would not do that. My experience is that any attempt to change the order in which messages are processed leads to problems. Or maybe increase SmtpCli send buffer size to 16384 or 32768 ? It's not the socket send buffer that causes this but the fact that older TSmtpCli sent attachments line by line, means in chunks of around just 78 bytes, this is fixed in newer versions. In such cases you should move the SMTP task into a worker thread Yes, current version of my main App uses SmtpCli in threads. But I want to move it outside threads and eliminate some problems with synchronization... Then only a bandwidth throttle works around the problem. -- 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 -- 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] Clarification of my previous question
Max Terentiev wrote: I try to use ICS v6 TWSocket in async non-blocking mode. (IDE C++Builder 2007) You realy should use v7, *v6 is obsolete*, it's not maintained since 2008. v7 is the successor of v6 and a move should be very easy. There are more than 600 changes and fixes since v6 in the svn repository. Get current source here: http://wiki.overbyte.be/wiki/index.php/ICS_Download Hi, After some investigation I have noticed that app slowdown happens only if I send large amount of data using TSmtpCli component. In v7 the send buffer size upon sending file attachments has been increased, this increased performance a lot, especially with SSL. However message text is still sent line by line. If I try to send large message (2-3 mb) - program hangs until message body sent. If that happens with a fast network connection (LAN) then it's a normal behavior in main, GUI thread since paint messages have less priority than messages actually posted to the message queue. Paint messages are processed only when there are no messages pending in the queue (on idle), that's why your GUI can freeze. In such cases you should move the SMTP task into a worker thread or use the new throttle feature (for an example have a look the FTP server and demo). If it happens with a slow network then I guess your AV or security software is responsible for the slow down and freeze. -- 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
