File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Threads and Synchronization and the fly likes question on Threads Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "question on Threads" Watch "question on Threads" New topic

question on Threads

Melinda Savoy
Ranch Hand

Joined: Jun 21, 2005
Posts: 387

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.

K. Tsang

Joined: Sep 13, 2007
Posts: 3132

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?

K. Tsang JavaRanch SCJP5 SCJD OCPJP7 OCPWCD5 OCPBCD5 OCPWSD5 OCMJEA5 part 1 part 2/3
Jayesh A Lalwani
Saloon Keeper

Joined: Jan 17, 2008
Posts: 2746

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
Ranch Hand

Joined: Jun 21, 2005
Posts: 387

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.
I agree. Here's the link:
subject: question on Threads
It's not a secret anymore!