Re: [twsocket] ICS V7 bug ?
Just wondering about the implications of this thread to ICS in general. As a Delphi user of ICS, are there DLL concerns for other non-SSL parts of ICS? Francois PIETTE wrote: Altough using in in Delphi is even more interesting, I was just thinking about publishing the procedure to rebuild OpenSSL DLL with C++Builder 2007 and 2009. -- 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] [Fwd: Re: Conflicts between multiple instances]
I am aggressively debugging the application. The root problem at this point seems to be a server background exception event. ICS sample code has comments, Should normally never occur and Hoping that server will still work. But, I am able to make it happen quite often and, though my handler has CanClose := False;, the server does not work after this event. What causes background exceptions? Arno Garrels wrote: Mike Lenox wrote: That's good information. I am not surprised if the TTimer is mine. BUT, the issue is still that I only get the error when I have both ICS components running. This implies that they are somehow interacting. Why don't you debug the application? I guess an exception or access violation is raised, isn't it? The call stack window of the IDE should contain useful information to track it down. What is the exception message? Another debug utility is MadExcept which is AFAIK still available as a free version for non-commercial use or as a 30-days trial version. It generates a bug report with call stack information including the source code line numbers, which you may want to post to this list. Another great free tool is FastMM in full debug mode. -- 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.13.16/2241 - Release Date: 07/16/09 05:58:00 -- 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] [Fwd: Re: Conflicts between multiple instances]
Finally! A very simple bug causing very strange symptoms. I had overridden Destroy in my ClientInstance object and neglected to include a final call to the inherited Destroy. Arno Garrels wrote: Mike Lenox wrote: I am aggressively debugging the application. The root problem at this point seems to be a server background exception event. ICS sample code has comments, Should normally never occur and Hoping that server will still work. But, I am able to make it happen quite often and, though my handler has CanClose := False;, the server does not work after this event. What causes background exceptions? For example any unhandled exception raised in one of the event handlers. However when you debug the application in the IDE those exceptions should raise, no matter whether OnBgException was assigned or not. BTW: Make sure that WSocketServer.ClientClass is properly set. If it is not you will get hard to debug AVs. -- Arno Garrels Arno Garrels wrote: Mike Lenox wrote: That's good information. I am not surprised if the TTimer is mine. BUT, the issue is still that I only get the error when I have both ICS components running. This implies that they are somehow interacting. Why don't you debug the application? I guess an exception or access violation is raised, isn't it? The call stack window of the IDE should contain useful information to track it down. What is the exception message? Another debug utility is MadExcept which is AFAIK still available as a free version for non-commercial use or as a 30-days trial version. It generates a bug report with call stack information including the source code line numbers, which you may want to post to this list. Another great free tool is FastMM in full debug mode. -- 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.13.16/2241 - Release Date: 07/16/09 05:58:00 -- 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.18/2243 - Release Date: 07/17/09 06:08:00 -- 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] [Fwd: Re: Conflicts between multiple instances]
In my current app, I only have a main thread. So, does this, ...this may cause a lot of trouble, apply? I should expect trouble if I have multiple ICS components all executing on the main thread? Original Message Subject:Re: [twsocket] Conflicts between multiple instances Date: Thu, 16 Jul 2009 08:58:49 +0200 From: Francois Piette francois.pie...@skynet.be Reply-To: ICS support mailing twsocket@elists.org To: ICS support mailing twsocket@elists.org References: 4a5e4805.5060...@ezriver.com Is there a problem having multiple instances of ICS socket objects on the same thread? Defenitely no problem. The most frequent error when using ICS components in a thread is to forget you must create the component from with the thread's execute method. If you create the component from the thread's constructor, then all events will be executed in the context of the creating thread (usually the main thread). And this may cause a lot of trouble. -- francois.pie...@overbyte.be Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.13.16/2240 - Release Date: 07/15/09 17:58:00 -- 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] [Fwd: Re: Conflicts between multiple instances]
I guess I am not being very clear. I am not creating other threads. I only have one ... the main Delphi thread. I am creating different ICS components, a TTnCnx client and a TWSocketServer in separate parts of my application. There are no shared global variables and the two instances are in different units so no shared local variables. BUT, the two objects seem to be interacting with each other as I get a TTimer access error ONLY when both objects are active and I make an actual connection to the server. Yes, since you are creating new threads. If you create the components in the thread constructor (or drop it on the form), their event handler will run in the main thread context which is the active thread when the constructor is called. You /MUST/ create the component from the Execute method (or any method called from the Execute), and destroy it from the Execute method. You cannot have on ICS component (let's talk about FTP as an example) dropped on a form and the create a few threads, each one using the same component to do file transfer. That will /not/ work. You need a separate component for each concurrent file transfert no matter if you use threads or not. -- 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] [Fwd: Re: Conflicts between multiple instances]
That's good information. I am not surprised if the TTimer is mine. BUT, the issue is still that I only get the error when I have both ICS components running. This implies that they are somehow interacting. Is there any possibility of that or any past complaints of such behavior? Arno Garrels wrote: Mike Lenox wrote: BUT, the two objects seem to be interacting with each other as I get a TTimer access error ONLY when both objects are active and I make an actual connection to the server. Both TWSocketServer and TTnCnx do not use a TTimer. If your code uses a TTimer what is the event handler doing? -- 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.13.16/2240 - Release Date: 07/15/09 17:58:00 -- 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] Conflicts between multiple instances
Is there a problem having multiple instances of ICS socket objects on the same thread? I have a Delphi app (single threaded) with different ICS-based objects in various units. I saw today what looked like crossover functionality between some of them. I'm getting TTimer access violation errors that only occur if I am simultaneously running a TTnCnx client in one unit and a TWSocketServer server in the other ... AND ... the errors only occur after I have made and closed a connection to the server. If the TTnCnx client is not active, I can make and break connections to the sever indefintely without any TTimer issues. If the server is not running, TTnCnx works fine indefinitely. But, if both are active and I make and break a single server connection, after a predictable amount of time (~3min) I will get repetitive TTimer access violations. Does ICS use any singletons in a thread (globals) or anything that might tie these two uses together somehow? -- 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] Telnet Client
More info concerning my original problem which is ...
My application uses a TTnCnx client object to connect (hundreds of times
per day) to a remote device to retrieve data. On rare occasions the pair
seem to get stuck in a connected state and stay there indefinitely.
The normal procedure is to call SendMsg which calls Connect.
OnConnection, write the outgoing message. When a response is received,
call ClosePort. If no response, MsgTimeout.
{As I write this I see one problem, I don't call Close in the timeout
procedure. Yet, after several failures, I would still call
NewTelnetClient which I would expect to get me out of the hung state}
See any other obvious issues? Any problem calling Free immediately after
Close in FreeTelnetClient?
Mike
procedure TTLS350E.SendMsg(Msg: string);
begin
try
if assigned(TelnetClient) then
begin
TxTCPBuffer := Msg;
if TelnetClient.IsConnected = True then begin { connection is
already active }
WriteToTelnet(Msg);
end else begin { got to get a connection }
TelnetClient.Connect;
end;
end;
except
ShowNewMessage( 'Exception handled in TCP SendMsg');
end;
end;
procedure TTLS350E.ClosePort;
begin
TelnetClient.Close;
end;
procedure TTLS350E.MsgTimeout(Sender: TObject);
begin
inc(PortRebuildCount);
if PortRebuildCount = TLS350_TIMEOUTS_RESET then begin
PortRebuildCount := 0;
NewTelnetClient;
end;
end;
procedure TTLS350E.FreePort; // This should only be called from Destroy
begin
FreeTelnetClient;
end;
procedure TTLS350E.FreeTelnetClient;
var
tmpTelnet: TTnCnx;
begin
if assigned(TelnetClient) then begin// if TCP client exists, kill it
tmpTelnet := TelnetClient;
tmpTelnet.Close;
tmpTelnet.Free;
TelnetClient := nil;
end;
end;
// The following function is called only after multiple
// message failures.
// build a new Telnet object
procedure TTLS350E.NewTelnetClient;
begin
FreeTelnetClient;
TelnetClient := TTnCnx.Create(Application.MainForm);
TelnetClient.OnDataAvailable := TnCnxDataAvailable;
TelnetClient.OnSessionClosed := TnCnxSessionClosed;
TelnetClient.OnSessionConnected := TnCnxSessionConnected;
TelnetClient.Port := IntToStr(MyConfig.GetPort);
TelnetClient.Host := MyConfig.GetIP;
end;
--
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] TTnCnx
I have an application that uses a TTnCnx object to repetitively retrieve data from a remote device. The application keeps a TTnCnx object and alternately Connects and Closes. I am having an occasional problem with the connection getting latched up, that is, it doesn’t seem to close properly and since the receiving device only supports one session, communication is stopped. Is there a problem with calling Connect again too soon after a Close? Is there some status I should be monitoring? Thank you, Mike -- 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] TTnCnx
Francois, Thanks you for the quick reply. I do not call Connect from the Close event but, the events that cause data to be requested are asynchronous and a request could occur almost immediately after a Close. So, I am wondering of I should be concerned that my TTnCnx object is still in the process of handling a call to Close when I issue a call to Connect. Another thought, could my problems be related to the fact that, when a Windows socket is closed it does not close immediately but hangs around for a while (I say this based on watching Netstat results). Any other thoughts on how a TTnCnx connection might stay up even though Close has been called? Mike Francois Piette wrote: I have an application that uses a TTnCnx object to repetitively retrieve data from a remote device. The application keeps a TTnCnx object and alternately Connects and Closes. I am having an occasional problem with the connection getting latched up, that is, it doesn’t seem to close properly and since the receiving device only supports one session, communication is stopped. Is there a problem with calling Connect again too soon after a Close? Is there some status I should be monitoring? Maybe the device doesn't like a reconnect too fast ? I don't know how you coded the application. If you call Connect from close event handler, try to pass by an intermediate custom message to let the component stop closing completely before doing anything else. -- francois.pie...@overbyte.be Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.287 / Virus Database: 270.12.10/2088 - Release Date: 04/30/09 06:01:00 -- 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] TTnCnx
This problem happens randomly and not very often on systems in the field. I am not able to duplicate a failure in a development environment ... yet. That is why I am seeking assistance to imagine situations where a problem might be occurring. Francois PIETTE wrote: Would be interesting that you publish the call stack at the time when you cann connect after the close. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: Mike Lenox mle...@ezriver.com To: ICS support mailing twsocket@elists.org Sent: Thursday, April 30, 2009 5:08 PM Subject: Re: [twsocket] TTnCnx Francois, Thanks you for the quick reply. I do not call Connect from the Close event but, the events that cause data to be requested are asynchronous and a request could occur almost immediately after a Close. So, I am wondering of I should be concerned that my TTnCnx object is still in the process of handling a call to Close when I issue a call to Connect. Another thought, could my problems be related to the fact that, when a Windows socket is closed it does not close immediately but hangs around for a while (I say this based on watching Netstat results). Any other thoughts on how a TTnCnx connection might stay up even though Close has been called? Mike Francois Piette wrote: I have an application that uses a TTnCnx object to repetitively retrieve data from a remote device. The application keeps a TTnCnx object and alternately Connects and Closes. I am having an occasional problem with the connection getting latched up, that is, it doesn’t seem to close properly and since the receiving device only supports one session, communication is stopped. Is there a problem with calling Connect again too soon after a Close? Is there some status I should be monitoring? Maybe the device doesn't like a reconnect too fast ? I don't know how you coded the application. If you call Connect from close event handler, try to pass by an intermediate custom message to let the component stop closing completely before doing anything else. -- francois.pie...@overbyte.be Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.287 / Virus Database: 270.12.10/2088 - Release Date: 04/30/09 06:01:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.287 / Virus Database: 270.12.10/2088 - Release Date: 04/30/09 06:01:00 -- 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
