0

I have a dashboard where users can do modification to their customers datas. Some modifications needs heavy processing on all those customers. I don't want to block my user waiting that the task finished so how can I manage this in background?

I saw Spring Batch but I'm not sure it's the good answer. Is there anything else?

Thanks in advance for your help.

Franck Anso
  • 1,342
  • 4
  • 17
  • 34
  • simply put, move the expensive task into a seperate thread and display the result once it is done. this way you wont block the user. there are a lot of libraries that provide such functionality but the principle is the same. – kmera Jan 20 '14 at 14:29
  • @k-mera Beware that if you are in a J2EE context you shouldn't do this: http://stackoverflow.com/questions/533783/why-spawning-threads-in-java-ee-container-is-discouraged – Jorge_B Jan 20 '14 at 14:30
  • yes but the question never said anything about J2EE :) edit: woops it mentions spring, my bad – kmera Jan 20 '14 at 14:31

4 Answers4

2

See (google) @Async and or Spring AMQP / JMS

Adam Gent
  • 47,843
  • 23
  • 153
  • 203
  • He said nothing about threads and message passing is a scalable way to handle deferred tasks. – Adam Gent Jan 20 '14 at 14:33
  • I have done similar things in the past, and my conclussion is that I left the client with a far more difficult and far less efficient environment to live with :( – Jorge_B Jan 20 '14 at 14:35
  • I will use @Async. It's the simplest. Thanks for your help. – Franck Anso Jan 20 '14 at 14:41
  • I would prefer JMS if the job is very heavy and you want to run the **really heavy** job over a distributed network. But if your job is not that heavy thread pool or scheduled task is the way to go. – TwilightSun Jan 20 '14 at 14:46
  • It doesn't have to be *really heavy* for MQ. Besides distribution, with MQ you also get reliability (retry), throttling if you like, and separation of concerns. In my opinion I try to push anything I can to the MQ (message bus) to improve performance of the front facing systems that server real-time traffic. – Adam Gent Jan 20 '14 at 19:24
0

It is not a Spring specific feature, but if you work under a commercial java application server (say websphere, weblogic), you will have some implementation of workmanagers.

http://docs.oracle.com/javaee/1.4/api/javax/resource/spi/work/WorkManager.html

These are container-managed threadpools used to send work into the background. You will find tools in your admin console to configure and fine tune them.

Jorge_B
  • 9,712
  • 2
  • 17
  • 22
0

You should have a separte process or application to process this kind of heavy task. Your main application have to communicate with this heavy-task-processor via any method like JMS, JGroups, ConcurrentLinkedQueue, or whatever you want. You can process (deque) each task one at time or using a thread pool. When the task is finish you have to implement a way to inform the main application the task has finished (JMS, subscription, etc..)

gipsh
  • 578
  • 1
  • 3
  • 20
0

You already have an accepted answer, but I wanted to throw in another option FYI.

  • If you want to run within the same JVM, @Async and a task executor will work.
  • If you have a big job that needs progress tracking, resumes, etc. and doesn't user need interaction, Spring Batch works.
  • If you have big jobs that you want to trigger remotely, or as part of a message driven architecture, Spring Batch Integration is a new effort to better combine Spring Integration and Spring Batch.
Emerson Farrugia
  • 11,153
  • 5
  • 43
  • 51
  • IMHO I find Spring Integration and Spring Batch to be bloated and over complicated libraries when an understanding of MQ library/server/broker (ie AMQP and/or JMS) to be suffficient. Also While Spring Batch does have task level status it does not have item level status (ie is this item done? did it error?) so you have to write that on your own. Honestly I think Spring Integration/Batch is still written for internal enterprise folk and not public SaaS applications where you need more dynamic flexibility (like queues on the fly... etc). – Adam Gent Jan 20 '14 at 19:15
  • Spring Integration is application layer messaging, AMQP/JMS is infrastructure messaging. That's not bloat, it's abstraction. It allows you to change how you integrate components without worrying about technology changes, and lets you follow EIP. How that gives you less flexibility than hard-coding to JMS is beyond me. As for Spring Batch, you can either implement ItemListeners or drop chunk sizes if you need that granularity. So I disagree. :) – Emerson Farrugia Jan 21 '14 at 14:16
  • Abstractions of course can be bloat (mental). Besides I implemented by own simple messaging abstraction using Guava style @Subscriber so I can plug any messaging framework I want (currently using Spring AMQP). I just found most of the things in Spring Integration/Batch to have the same problems as Spring Security: I end up constantly looking at the code and practically reimplementing half the framework not to mention annoying XML DSL (even the java config is magic aop). Its not hard to do EIP with just AMQP. Just like its not hard to do security with servlet filters :) – Adam Gent Jan 21 '14 at 16:22