Deprecate java.util.Timer
Description
Environment
is related to
Activity
Rod Widdowson April 17, 2019 at 2:23 PM
Bumping into V4 so we can see it, discuss it and do it or close it.
Rod Widdowson June 27, 2018 at 3:39 PM
I've forgotten why we cared about this
Rod Widdowson June 26, 2015 at 9:52 AM
Moving the conversation from where Scott said:
> Seems likely that we'll never be successful making all their code paths stop
> hanging, so probably the "real fix" here is just simply moving to a timer that
> uses cancellable work threads.
I'd concur with the some concerns
I'd need to be convinced that cancellation involves "doing the right thing" with respect to unwind (we do not want a thread to exit with a lock held and have to rely on GC to release it)
Its not immediately apparent to me what conditions we place on cancellation (when the next refresh is due)
Finally, just because we cancel the thread, this doesn't mean that the operation won't just wedge in the same place next time.

Ian Young April 27, 2015 at 10:13 AMEdited
The reference in MDA is in net.shibboleth.metadata.query.QueryController
, which is part of aggregator-web-service. This is not part of the product yet, and will probably be replaced in some way by the mdq-server project code (which uses ScheduledThreadPoolExecutor
).
I don't think there's a need to update the MDA code.
Details
Details
Assignee
Reporter

Deprecate java.util.Timer.
The IdP does not use Timers directly, but OpenSAML and java-support (as well as the MDA) do.
http://marc.info/?l=shibboleth-dev&m=142617931120380&w=2
Replacements include java.util.concurrent.Executor and related as well as Quartz.