Home/ Questions/Q 7014865
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T22:34:37+00:00

I need to develop a simple daemon in java that takes files from a

  • 0

I need to develop a simple daemon in java that takes files from a folder, analyse their contents and stores some info in a database. There are inevitably bursts of activity (for instance when files have accumulated whilst the demon was not running) and I am looking for the most efficient threading model to process this backlog as quickly as possible.

I’m currently considering several options.

  1. JBoss AS (v7 ?) with Quartz.
  2. JBoss AS (v7 ?) with just JBoss threads
  3. Pure java 5 task execution framework (ThreadPoolExecutor)

Can someone comment on the pros and cons of these options.

On a side note, I’m also interested in the following related consideration

  • Respective merits regarding how IBM/Sun JDK really manage to make the best of multi core processors. I’m planning to run on either an IBM or a Sun java 7 jvm.
  • Whether JBoss uses or not (and since what version) the java 5 threading model.

EDIT A few remarks following Enno Shioji’s kind answer.

  1. The reason why JBoss in the picture is because the data stored in the DB is made available through a webapp. So that my customer might ask “why is the file parsing not in the AS as well?”.
  2. I agree that the process is probably IO bound rather than CPU bound. However, what I’m eager to avoid is a situation whereby a poor thread scheduling logic across the whole os/pthread/jvm/javalib multi-layers vanilla slice would slow down the acquisition of incoming files.
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    JBoss AS is just an application server. Unless you want to use its service (like JMS, WS, EJB, JPA etc.) you don’t want to involve JBoss at all. It would just make things complicated and likely slower.

    Using Quartz may be a good idea depending on what you want to do. This is not because of performance though — just because it might make your implementation easier. If your app is functionally simple, just using ThreadPoolExecutor is fine (and is as performant as it gets on JVM).

    Unless you do really heavy number crunching when you analyze your files, CPU isn’t going to be the bottleneck of your app. My (wild) bet is it would be the DB access. So I wouldn’t worry about CPU efficiency (or on what JVM the app. runs) unless you test the app. and determine that is being a bottleneck.

    UPDATE:
    Oh ok. My recommendation in that case would be having a periodic check using EJB Timer, which submits messages/jobs to JMS with Message Driven Bean or the new light weight asynchronous service which was added in EJB 3.1. As long as you do that (as opposed to spawn a bunch of threads on your own etc.), I really wouldn’t worry about thread scheduling because JBoss will take care of the proper threading design (primarily how many thread to spawn and how to share them among tasks etc.).

    In fact, you probably want to first try letting the Timer do all the job (as opposed to using the fancy JMS with MDB/async service stuff) unless you test and find out that it doesn’t perform enough. That’s way simpler, and usually sufficiently performant.

    Almost all thread scheduling problems comes from bad concurrency design (i.e. programmer’s mistake). Unless you are fine tuning a CPU intensive parallel computation or something like that I really wouldn’t worry about JVM’s scheduling mechanism. That would be like worrying if the bridge will hold when you are about to do a bungee jump from there with an experimental equipment… (you wanna worry about the equipment first)

    • 0