JMS Vs Java Pure Threads

I am building a server in J2EE environment which needs to do following tasks continously.

1. Detect files uploaded to a directory

2. Move files to a temperory working directory(FIFO order)

3. Read files and Validate records(FIFO order)

4. Read & Process files that have successfully gone through validation.(Order of processing- Priority set by business rules.)

5. Package and Move Output files to an output directory(FIFO order).

6. Send Emails.

To speed up processing I need tasks 2, 3, 4 & 5 to be done parallely with a limit on maximum number of files to be processed at a time set.

I have the luxury of utilizing a database to communicate back to main server. All database access will all be made through respecitive Entity Beans.

I have 2 options infront (May be you can suggest more).

1. Use Java Threads :

Initiate a thread (not more than x at a time) whenever 2, 3 ,5 tasks comes up.

Initiate a process(not more than x at a time) whenever task 4 comes up.

2. Use JMS :

JMS Queue PTP for tasks 2, 3, 5

JMS Topics for task 4 (This is because we have diferent types of files which has to be processed in different manner. For each type of file a seperate Topic will be created)

Note :-

A file will be of typically no more than 20MB (1,80,000 lines).

Number of files to be processed concurrently (Tasks 4) will be of the order five to eight.

My thought is like - JMS will be better in terms of maintainability and ease of design.

Performance , Reliability ?

All your suggestions are welcome to help me to decide on which method to go for.

[1684 byte] By [hotjava05a] at [2007-10-2 9:29:47]
# 1

> For each type of file a seperate

> Topic will be created)

You can create properties on the message and filter the topic such that different listeners only pick up the items that you want. You could also build the switch in your code.

> Note :-

> A file will be of typically no more than 20MB

> (1,80,000 lines).

> Number of files to be processed concurrently (Tasks

> 4) will be of the order five to eight.

I'm not sure, but if you put the data directly in the queue/topic, you should test with files this larger or somewhat larger to be sure it will handle this OK.

> My thought is like - JMS will be better in terms of

> maintainability and ease of design.

> Performance , Reliability ?

I have found that JMS is a great solution because it's very robust, offers automatic failover (as long as the JMs server is there) and when your processing fails, it handles retries. There is a downside the the last point. The way you get this is by not confirming messages until you have successfully processed them. However, if you have a bug in the code or bad input, the same file may fail over and over agin in an infinite loop. You should consider this in your design.

You can make threads work but to get all the features that come with JMS, you will have to do a lot of work.

dubwaia at 2007-7-16 23:36:18 > top of Java-index,Other Topics,Patterns & OO Design...
# 2

Use Threads. Your tasks are quite simple (processing files) and we also process many files a day in parallel via Java Threads. As you just need to take care of the type and amount of thread and the threads itself run independently (meaning: no share of same resources), writing the thread classes is simple and fast. JMS is a full blown layer that introduces errors you need to maintain or get lost because you didn't wrote it yourself. You also don't need any extra server or instances - just your own Thread classes. It's fun: [url=D:\docs\JavaTutorial\essential\threads\index.html]Threads: Doing Two or More Tasks at Once[/url].

MartinHilperta at 2007-7-16 23:36:18 > top of Java-index,Other Topics,Patterns & OO Design...
# 3

> JMS is a full blown layer that introduces

> errors you need to maintain or get lost because you

> didn't wrote it yourself.

Are you suggesting that writing something yourself produces less errors that using a standard framework that is used successfully by thousands of projects?

dubwaia at 2007-7-16 23:36:18 > top of Java-index,Other Topics,Patterns & OO Design...
# 4
Aren't components supposed to let the container manage threads in J2EE? I thought somewhere in the spec there was a explicit ban on the creation of threads.
RadcliffePikea at 2007-7-16 23:36:18 > top of Java-index,Other Topics,Patterns & OO Design...
# 5

> Aren't components supposed to let the container

> manage threads in J2EE? I thought somewhere in the

> spec there was a explicit ban on the creation of

> threads.

For a specific type of container - yes. (Can't remember the type name though, the one that does EJBs is the one.)

jschella at 2007-7-16 23:36:18 > top of Java-index,Other Topics,Patterns & OO Design...