2

This is a high-volume production system, however, this particular code path is seldom used. Its an import feature that can potential result in a lot data coming in, but it's only occasionally used, a few times a month, perhaps.

Having a (polite) debate with a colleague. The issue is whether a simple thread created the old fashioned way:

Runnable thread = new Runnable() {
  public void run() {
    //... do the import work ...
  };
}
new Thread(thread).start();

Is sufficient, or if this requires using a thread pool.

This is happening in a service-layer class that is called from a servlet (providing a RESTful interface). The purpose being to allow the response to return and free the UI while the import happens.

As a follow on - in this situation, is using a thread pool actually just going to add more unnecessary (coding and resource use) overhead?

After EJP's comment - is there a good guideline for when it becomes 'worth having a discussion' about using pooling instead of straight thread creation?

mtyson
  • 8,196
  • 16
  • 66
  • 106
  • Yes. I agree with you. A feature used a few times a month isn't worth even having a discussion about. – user207421 May 12 '15 at 01:42
  • It's also not a big deal to use thread pool here, in case you don't want to confront your colleague too hard – ZhongYu May 12 '15 at 02:20
  • Simple: If your application _continually_ creates and destroys threads, then you should consider using a thread pool instead. If it only creates threads on start up and it only destroys them on shut down, then a thread pool is not likely to add any value. – Solomon Slow May 12 '15 at 13:26

1 Answers1

1

A threadpool would only be useful if you were planning on starting a lot of these threads, and then avoid thread creation overhead by re-using them instead of kill + re-creating them for subsequent work.

Since this code path is used so rarely, you will not need a threadpool.

However, it sounds like you are doing this heavy work in the same process that serves your REST API? You may want to consider passing this work to a worker that runs in a separate process.

Martin Konecny
  • 57,827
  • 19
  • 139
  • 159
  • Hey Martin, no the thread is created to do the import work, allowing the servlet thread to continue. – mtyson May 12 '15 at 01:43
  • A separate thread is still in the same process. It should be fine to run them in the same process, however the *right* way would be to create a separate program (which would run in a separate process) to handle this expensive work. – Martin Konecny May 12 '15 at 01:47
  • For example, when you upload a huge file to YouTube, it needs to convert it to the proper format. Google is passing this file to a separate worker program which handles the conversion (could take minutes), while keeping the server process handling the HTTP requests dedicated to handling requests. – Martin Konecny May 12 '15 at 01:49
  • I see what you are saying. So basically, something like: write the files to disk, have another program that monitors for new imports written to disk, and then handles the importing when they arrive. I can see that as a benefit because it'll keep the importing work out of the server JVM. – mtyson May 12 '15 at 01:51
  • 1
    Actually what would happen is the file is written to disk, and then the server sends a message to the Worker Process indicating the path where the file was uploaded, who owns that file, and what should be done to it. Something like RabbitMQ implements Queues that the HTTP server pushes to, and the Workers wait on until something appears. – Martin Konecny May 12 '15 at 01:57
  • I don't see the benefit of doing that - unless the worker program runs on another machine. – ZhongYu May 12 '15 at 02:22
  • Even better if you can run it on a separate machine. However even on the same machine you can give the worker process a lower CPU priority so that the scheduler favours the process serving HTTP requests. – Martin Konecny May 12 '15 at 02:33