So I have this Java piece of code where I need to do some work on a bunch of items. I decided to parallelize this to get some extra boost and I though to use a ThreadPoolExecutor. The problem is that the work I need to do can throw an exception...
Now I would like to shutdown the entire job to stop as soon as an error is encountered and report it back so I can handle it. Looking online, I found that the normal way this should be done is via ExecutorCompletionService and analyzing the Future results. However, this won't let me shut everything down when the first error comes by, as there is no way to loop over based on which task finishes first...
So I did something that I thought was rather hacky and I'm curious if there is a better way to handle this. What I did was:
1) Have each Runnable that I will execute have a field for the Throwable that it might execute.
2) Override the TPE's "afterExecute" method and check if any checked exception got thrown (which gets recorded in the Runnable) or any unchecked one gets thrown (which should be reported in the second parameter of this method). If any did, then I issue a shutdownNow() on the TPE.
Again, this seems a bit hacky and I am wondering if there is something I am missing. Thanks in advance!
Look at ExecutorService.invokeAny:
Executes the given tasks, returning the result of one that has completed successfully (i.e., without throwing an exception), if any do. Upon normal or exceptional return, tasks that have not completed are cancelled. The results of this method are undefined if the given collection is modified while this operation is in progress.
It looks it does the exact same thing you are trying to do... if I understood your problem correctly.
However for cancel to do anything, you have to make your Callable tasks interrupt aware. But that applies no matter how you try to cancel your tasks.
EDIT:
This is not what you need; I misread the javadoc. Here's another solution: you could put all your Future's in a list and then have a semi-busy while loop where you check periodically on each futureList.get(i).get(100, TimeUnits.MILLISECONDS) and you can catch an exception and act accordingly. However, this no more "elegant" than your solution. It seems that afterExecute was made to do what you want anyway.
Related
I am try to do something like
Optional<Order> orderDetails = orderRepository.findById(orderId);
if (orderDetails.isEmpty())
throw new OrderNotFoundException("Order not found!");
Optional<User> UserDetails = userRepository.findById(userId);
if (UserDetails.isEmpty())
throw new UserNotFoundException("User not found!");
List<OrderItem> ItemDetailsList = orderItemRepository.findByOrderIdOrderByItemIdAsc(orderId);
Where I want to call these three Services methods together in a non-blocking way, but I want to throw error if any one of those call fails and dont proceed furthur.
If all of the above works, then execute the later logic.
I am thinking of using allOff() then after that use get on the Futures and do the above logic of throwing error when the Optional is empty?
Is there better way of doing it ? i.e if one of them fails and others are still running, throw error and abort the other running tasks.
CompletableFuture is the wrong tool for the job here. And the main problem is that you want:
"...throw error and abort the other running tasks"
If you read what CompletableFuture::cancel documentation says, you will see that:
mayInterruptIfRunning – this value has no effect in this implementation because interrupts are not used to control processing.
So, even if you call cancel, this will not interrupt your tasks, they will still continue to completition. As such, your fundamental requirement can not be met.
There is a way with creating a custom pool of threads for that CompletableFuture that you want to cancel and shut down the pool, as an example here. But this is not trivial to do and your threads need to respond to interrupts properly.
I'm using AspectJ to monitor my application performance. E.g. start time, end time, memory consumption, etc.
I have a threadpool in my main package with 4 fixed threads executing a particular function. I need to check the thread ids of these threads when the particular function executes. I have a pointcut on this method, but I'm not sure how to get the thread id.
I know that I can use the after returning advice and the get the returned object in my advice. Is there a way to get all the objects created in a method. I'm assuming I'd need an after advice. But I'm not sure how to proceed further.
How about
Thread.currentThread().getId()
There is really nothing special in AspectJ with regard to threading. Aspect code is executed in the same thread it was woven into.
If I do not understand your question correctly and the above does not answer it, please just update your question and provide an SSCCE in order to make the audience see and understand what the point is.
I'm working on a Java project and I've come upon an interesting design issue. It's not exactly a problem, but it is a bit ugly with the obvious solution.
I have a class implementing Callable, although with the current implementation it could just as easily be a Runnable as I'm not interested in the outcome, at least not as far as the calling thread is concerned. The calling thread will drop a number of these into a thread pool. Each of these Callables will have a batch of data that was obtained from an external service. The Callables will perform a number of actions, many of which involve making further calls to external services. As a result, there are a good number of places where various Exceptions could be thrown.
The issue I find is that depending on where the Exception occurs, I may need to take different actions. If it happens at point A, then delete the data on the external service. If it happens at point B, move the data to a different location on the server. If it happens at point C, just log it and do nothing further, etc. Any number of Exception types could be thrown at multiple points, although I don't think I'll need to do much filtering on the type itself, but more that one occurred.
The Callable itself isn't terribly huge, so there's not a great deal of code to mess with. However, I am hesitant to kludge it up with a ton of try/catch blocks to handle every possible point/Exception that may need different handling. I realize that this may really be the only viable solution. I don't really have control over most of the Exceptions that will be thrown (maybe a handful) without catching an existing one and rethrowing my own, which seems a bit redundant. I'm wondering if there's a good pattern or method to handle this sort of thing.
I've considered an exception handling class, but I'd still need to catch each Exception somehow and pass it to the handler as the point at which the Exception was thrown is important. I could break the Callable down into more atomic classes, each with their own small block and handling, but that would be trading one kludge for another. Catching everything in the call() method outright or by grabbing the Exception from the Future in the calling thread really isn't an option as this will lose the data on where it occurred unless I want to parse the stack trace, which isn't exactly viable.
Can anyone shed some light? Maybe I'm just quibbling over the try/catch blocks and should just go ahead with it, but I feel like there must be a better way...
Hmmm, it does occur to me that annotations on methods might help here. I could break down all methods until there's only one possible exception-throwing piece of code in each. Annotate each of these with a custom annotation that dictates what is done when that method throws an exception. I'm not sure if it is possible (an exception would somehow need to be caught right there as it may happen within a loop going over each piece of data and only one piece may be problematic, or at least somehow mark that piece for processing further up the chain), but perhaps this could mitigate the need for lots of try/catch blocks and instead handle the behavior with a single annotation and a handler class to deal with the exceptions. I don't believe it's possible to dictate behavior this way with an annotation, but I'd be happy to be wrong on that.
Is there a way for the debugger to pause a specific thread while letting the other ones run? I want to verify some locks I have are working properly and Im not sure how to induce certain conditions. Note that all the threads run through the same code, so any changes to the code will affect all threads, where as I only want to stop one thread.
You might want to look at testing frameworks like MultithreadedTC - which lets you programmatically control flow through the different threads during the test so you can cause race conditions and timeouts during testing.
If you have a convenient point in your code to set a breakpoint for that single thread, you can change the Suspend Policy of that breakpoint in its properties to only stop the current thread instead of the whole VM.
You can add a method to do a sleep in the thread. Then you can call that method with junit or a simple POJO.
I was able to sort of fix my own problem by basically putting the following code in the thread code -
if(Thread.currentThread.getName()="thread1"){
Thread.currentThread.sleep(5000);
}
This way only thread 1 sleeps. It worked well enough that I saw my locks working, but this isnt really a good solution I feel. Perhaps someone can make something better?
I've searched this along the way on the net but i haven't found an answer yet.. maybe someone of you guy knows this.
I'm developing a swing desktop like application; since I know that swing is not thread-safe (and if I call a method on a JComponent outside the EDT there is always the chance to get a deadlock with the EDT itself), I would like to have an exception thrown by the thread that is trying to call that method.. let me explain better:
suppose I have 2 threads: the EDT and a background worker ("BW").
If I call, for instance, JButton.setText(), or JButton.setIcon() within the BW there is a chance to get a deadlock with the EDT. Now I would like that when the BW calls JButton.setText() and exception is thrown to indicate that I'm doing very wrong..
I see that C# on VS2008 does this by default (I don't know if there is a way to disable this behaviour, but I think it is very useful to detect bad code). Is there a way to achieve a similar effect in java?
Take a look at this article which describes a RepaintManager which checks Swing threading violations. It will not catch all violations, but most of them.
You can easily adjust that class to throw Exceptions iso just printing a stack trace
Take a look at SwingUtilities.isEventDispatchThread. Calling this will return true if the call is made from within EDT, false otherwise.
It will do exactly what you want, the problem is you will probably have to make such calls in multiple places of your code; it's more work.
Wrap each swing object you have in a Proxy, generated with reflection. Make that proxy compare the thread to the known good EDT thread. If doesn't match throw a RuntimeException.