On Tue, Nov 6, 2018 at 6:39 PM Christopher Schultz < ch...@christopherschultz.net> wrote:
> > Otherwise, at the moment, the behavior is the same as before: if > > an exception remains uncaught like your OOM or ThreadDeath or > > whatever, it will cancel the scheduling (and I haven't added the > > code to add it back). I have chosen to use scheduleWithFixedDelay > > (subtle tweaks can be made here: some of the calls could use > > scheduleAtFixedRate instead, maybe like the connector async > > timeout) > > I think scheduleWithFixedDelay makes more sense. If an application > ties-up the background thread, you could have multiple background > threads running on top of each other. Theoretically, everything those > threads are doing should be thread-safe, but I think it's probably > best to have only one running at a time. > scheduleAtFixedRate does not concurrently execute, it is possible it runs late. Also, the container background threads are exclusive (they avoid entering a container which has one enabled too). As a result, it should be ok. I think scheduleAtFixedRate is only good for that async timeout though. > > > , and the javadoc says: If any execution of the task encounters an > > exception, subsequent executions are suppressed. > > > > So you think adding back the scheduling after a problem is better > > ? > > Yes, I think so. The container should protect itself from > applications, and this is a case where a misbehaving application can > break the correct operation of the container. > Ok, so it's harder, there's no API for it. I'll try to find a good solution. Rémy
