question on Threads

[Melinda Savoy]

I am working on a NEW application that I've inherited and have a question on threads. I am working in Eclipse and trying to watch the threads change from a RUNNING status to when they are accessed from within the application.

There are multiple threads in the application and in the DEBUG window of Eclipse it shows them all and their status where all of them state RUNNING status. Initially when I start my application I can send an ISO8583 message from an outside source which is what my application processes and it processes successfully and hits one of the threads. However, while my application is STILL running, I execute another ISO8583 message from the same application and that message NEVER hits my application. In Wireshark, I can see the message come across the network but it never makes it to the thread that is waiting on a message.

My apologies but I'm not sure what type of information you guys require to help me troubleshoot this issue. Any help would be appreciated.

Thanks.

[K. Tsang]

Don't know what you trying to do. When you send a message... you want to start another thread or tell the running thread to block or something else?

[Jayesh A Lalwani]

Trying to reverse engineer an application using a debugger, eh? Yeah that can be fun

Usually the way most applications like these are designed is that you have one thread that waits for connections from clients(let's call it connection thread). When it gets a connection, it hands off the connection to another thread(let's call it communication thread) and then goes back to waiting for another connection. The communication thread that will receive the message and handle it. Generally, if it takes time to process the message, and it has to be done in the background, there might be yet another thread (let's call it the worker thread) that the communication thread will hand the message off too. Another populat thing to do is to have thread pools. So, instead of starting and stopping a thread everytimje, the threads might be started as soon the application starts and might wait for messages to come in. In this case, the message is usually stuck in a queue, and the threads are usually waiting for messages to appear in the queue. If this is so, you will see maybe 1 connection thread, couple of communication threads, and lots more worker threads (if you need them) in your debugger. When the threads in the thread pools are idle they will be in waiting state.

Now, this is the usual way of doing things. The way your application is designed might be differrent

Thread dumps are a great reverse engineering tool. Thread dumps tell you what each thread is doing in form of a stack trace. After you send your ISO message, take thread dumps continiously till you get your response. Look at those thread dumps very closely. You might be able to figure out what the app is doing.

[Melinda Savoy]

Jayesh, thanks for the help. I will definitely try that. Your description of how this app works is pretty close to what we have. Doing thread dumps hopefully will help me find some answers. Thanks again.