• Post Reply Bookmark Topic Watch Topic
  • New Topic

Using ThreadPool

 
Karthik Veeramani
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had posted a similar question a few weeks back, but this is a bit different...
My idea is to receive datagrams continously frm udp port, process and write them to a file. I have a class UdpReader (extends Thread) to read them.
I downloaded a ThreadPool class (that implements a thread pool). This thread pool has a runTask method, that'll accept a Runnable object, and invoke its run method. It'll do the scheduling between the threads it maintains, internally.
In order to pass to this thread pool, I have a PacketProcessor class (implements Runnable) that will process the datagram and write to file.
In my UdpReader class, I receive a datagram, instantiate a PacketProcessor object for every datagram, and pass the object to the runTask method of the ThreadPool.
I find that, if I use a thread pool of 5 threads, its working fine upto a certain rate of incoming messages, but failing after that (failing means, not all the messages are seen in the file). Similarly, if i use 10 threads, the rate of acceptance is higher, still that also fails at one point.
Please tell me if the way i have designed the program is wrong. Do let me know if any info is needed. One more thing, I have synchronized the method that writes to the file (and some more code blocks).
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hard to say. The basic approach sounds fine. Two possible causes I can think of offhand
  • The thread pool's job queue is not properly implemented and may overwrite an old job that is still waiting with a new job.
  • The file-writing method is part of PacketProcessor, in which case sychronizing won't have bought you anything (refactor into a separate class or make the method static).
  • There are probably a gazillion other possible causes. Any ideas, anyone?
    - Peter
     
    Ellen Zhao
    Ranch Hand
    Posts: 581
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Not sure whether my guess makes sense:
    Some potential deadlock plus some timeout-that means, deadlock exists( but not really often happens ), but also some timeout treatment doesn�t let the deadlock lock forever. So that some packets might not been processed during the deadlock. Try to comment out all the timeout treatment from your code and see what happen.

    Regards,
    Ellen
    [ January 17, 2003: Message edited by: Ellen Fu ]
     
    Karthik Veeramani
    Ranch Hand
    Posts: 132
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for ur responses. Yes, the file writing method is a part of PacketProcessor class, and ive synchronized it. Why is that it wont b of any use? anyway, i'll try to make it static as u said.
     
    Peter den Haan
    author
    Ranch Hand
    Posts: 3252
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    That's not of any use because a synchronized method acquires a lock on that particular instance. You've got a large number of threads, each operating on their own instance of PacketProcessor, and they will all be able to successfully call their own file writing method at the same time because all these methods acquire different locks.
    Making the method synchronized and static will force all the threads to acquire a lock on the PacketProcessor Class object. There's only one of those, so one thread executing the file writing method will now lock out all the others.
    Architecturally, it's not a particularly pretty solution though; it would probably be better to create a class that encapsulates access to the file, synchronize the method(s) on that class, instantiate one FileAccess object and give that object to all PacketProcessors.
    - Peter
    [ January 18, 2003: Message edited by: Peter den Haan ]
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!