🚀 go-pugleaf

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:44f86462$1@newsgroups.borland.com...
>
> "Andre' Burke" <no.spam@spam.no> wrote in message
> news:44f7ef1a@newsgroups.borland.com...
>
>> What I can't figure out is why the OnDataAvailable would
>> deadlock, or for that matter the thread that is calling it.
>
> I see that you have the TIdTelnet::ThreadedEvent property set to true. 
> That
> makes the OnDataAvailable event handler code run in the context of the
> reading thread, so you have to make sure that its code is thread-safe.  Is
> your logger thread-safe?  What kind of container are you using for your
> Incoming_Queue, and is it thread-safe?  I do notice that you are accessing 
> a
> couple of counter-related variables in the event handler without 
> protection.

Logger, should be thread safe, it has a single critical section which is 
only locked while actually writing to the file.
It is used in a number of other multi-threaded apps without a problem.
Incoming_Queue is a TThreadList.  All I do in the OnDataAvailable is Add, 
which is supposed to completely thread safe.
In my data processing code I have changed it around so that I only lock the 
Incoming queue inside the loop and then unlock it again immediately, so I 
dont have it locked for any long periods of time.

counter gets set to zero in the OnDataAvailable, this is simply used to see 
when last I recieved data from the server.
Timer2Counter gets set as well, this is to force the timer code to do some 
extra processing.
Neither of these *should* cause a lockup (but you never know).


>
>> When this happens, I dont even get this message in the log-file, so
>> its not even getting into the code of the OnDataEvent.
>
> Since you have the ThreadedEvent property set to true, then that is only
> possible if the reading thread is not receiving any data, meaning that it 
> is
> blocked in an idle reading operation.  If actual data is received, then
> there is no way the reading thread can become blocked before triggering 
> the
> OnDataAvailable event.
>
> With that said, there is another possibility to consider - since you are
> using a Telnet component, what does the actual transmitted data look like?
> Although it is probably not the case in this situation, it is technically
> possible that the data itself could be interpreted entirely as Telnet
> control sequences with no application data available.  If that were to
> happen, then there would be no reason for the OnDataAvailable to be
> triggered.

Well, from the test server that I have, I am actually sending the same data 
over and over again.
Data looks like this:

E 022 00 T010267 1165567 02/20 14:44:31 00:01:02.0\r\n

&0124607806XXXXXX 3905XXX 000 000\r\n

& 000 01 0\r\n

\r\n

N 021 00 1165545 A012022 02/20 14:39:39 00:04:52.0 A00833014904\r\n

& 000 000\r\n

& 000\r\n

\r\n

S 023 00 T010170 4830 02/20 14:43:45 00:00:48.0\r\n

&0184410151XXXXXX 4830XXX 000 000\r\n

& N 000 01 0\r\n


These 3 records get sent over and over again, in different order at random.
The server will send the following string when its finished sending (decided 
randomly):

TotalRecords\r\n

And also randomly decided it will sometimes send the following instead of 
the above records:

NO DATA\r\n


The server is written in BCB6, with an Indy Telnet Server component.


When the lockup occurs I can see that the server has sent the data to the 
client, but the client doesnt seem to register it.
I can't trace into it either because sometimes it runs for hours before this 
happens.
:-(



>
>
> Gambit
>
>