I have a button that calls a method from the backing Bean. This method allows to extract data from parsing html code. While the method is running i have a dialog showing a progr
ExecutorService documentation
Instead of directly calling the method, convert the method into an ExecutorService
's task.
public class SearchEmailsTask implements Runnable {
private EmailSearcher emailSearcher;
public SearchEmailsTask(EmailSearcher emailSearcher) {
this.emailSearcher = emailSearcher;
}
@Override
public void run() {
emailSearcher.searchEmails();
}
}
You can use Callable<Object>
if you want to return something.
When you want call the method, submit that task to an ExecutorService
.
ExecutorService executorService = Executors.newFixedThreadPool(4);
SearchEmailsTask searchEmailsTask = new SearchEmailsTask(new EmailSearcher());
Future<?> future = executorService.submit(searchEmailsTask);
Keep a reference to the task.
private static Map <String, Future<Object>> results = new HashMap <String, Future<Object>>();
A map should be a good idea to store multiple Future
objects. You can of course go for something better if you want.
Call cancel on the task whenever required.
future.cancel(true);
Note:
Task should have suitable checks for thread interruption for proper cancellation.
To achieve this, refer to
Good luck.
With your current architecture it's not going to be easy. By looking at your code it seems that you are calling two big operations that can't be aborted in the middle. You must break the work into small units and make the processing abortable.
The easiest solution that uses your current code could look something like this.
public class SessionScopedMailBean {
volatile boolean searchAborted;
public void searchEmails() throws Exception {
searchAborted = false;
while(!searchAborted) {
// Process a single unit of work
}
}
public void abortSearch() {
searchAborted = true;
}
}
In JSF:
<p:commandButton value="Cancel" title="Cancel" actionListener="#{mailMB.abortSearch()}" />
That said I'd recommend using executors and futures based approach for cleaner architecture. Then you can also implement a real progress bar not just an animated GIF spinner.
Another problem with performing a long operation in command handler is that eventually the HTTP request will time out.
A cleaner solution will look like this:
public class SessionScopedBean {
ExecutorService pool;
List<Future<Void>> pendingWork;
@PostConstruct
public void startPool() {
pool = Executors.newFixedThreadPool(1);
}
@PreDestroy
public void stopPool() {
if(executor != null)
pool.shutdownNow();
}
public void startSearch() {
pendingWork = new ArrayList<Future<Void>>();
// Prepare units of work (assuming it can be done quickly)
while(/* no more work found */) {
final MyType unit = ...; // Determine next unit of work
Callable<Void> worker = new Callable<Void>() {
@Override
public Void call() throws Exception {
// Do whatever is needed to complete unit
}
};
pendingWork.add(pool.submit(worker));
}
}
public int getPending() {
int nPending = 0;
for(Future<MyResultType> i: pendingWork)
if(!i.isDone()) nPending++;
return nPending;
}
public void stopSearch() {
for(Future<Void> i: pendingWork)
if(!i.isDone()) i.cancel(true);
}
}
Then use an AJAX polling component to poll getPending to determine when it's done and hide the window.
See also: