My service, which communicates using ICS, is "flakey" for some customers. I've got quite a bit of exception handling and logging, and there was nothing indicating an exception was occurring.
I finally pinpointed an exception that one customer was getting. I hooked TWSocket.OnDataAvailable and was doing custom processing, and the exception occurred in my code. However, the OnBgException event never fired. ASyncReceive is swallowing my exception. I searched my twsocket list archive, and found the message below from two years ago. Then I checked the latest sources in SVN and found that this code has not changed. Does anyone know why ASyncReceive is swallowing the exception and not calling HandleBackgroundException? Thanks! On Sun, Dec 2, 2007 at 2:20 AM, Arno Garrels <arno.garr...@gmx.de> wrote: > DZ-Jay wrote: > > On Dec 1, 2007, at 13:36, Arno Garrels wrote: > > > >> Have you got any exception that was raised from TWSocket internaly? > >> I mean outside of your handler? > > > > Well, I noticed the issue because my handler raised an unhandled > > exception and the application then behaved in a strange manner because > > it was never caught (just absorbed by ASyncReceive). > > Yes, I noticed that yesterday as well when I was debugging a client > pool. I got an error on ReallocMem() in TriggerDataAvailable in > TCustomLineWSocket, the the destructor was called and raised an > EInvalidPointer on FreeMem(), most likely due to the attempt to > access and free an already freed object (most likely my fault in > this case) but it took me several hours yesterday to find the problem > since clients just disapeared silently unless I ran the server in > the debugger. > > > But then looking > > deeper, I found that at least SmtpProt and FtpProt *can* raise > > exceptions in the WSocketDataAvailable event (not that they have). In > > particular, the obvious exception they raise is if the FNext pointer > > is NULL and its processing ExecAsync. > > > > Admittedly that should never happen, but ignoring it is just asking > > for trouble (which is why I think Francois added the check and the > > exception there). Also, the buffer manipulations performed there > > could theoretically fail, and an exception would not be caught, yet > > the component would be in a strange state. > > Yes, for instance ReallocMem() may raise EOutOfMemory, got this > twice yesterday while stressing a server application with thousands > of connections. > > > > > Perhaps wrapping those handlers in a try..except block would be > > better. > > It's something Francois should have a look at when he has some time. > > -- > 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
