Timeline for Custom, simple cache with load timeout and expiry; thread safety, tests
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 19, 2014 at 17:17 | history | edited | Jamal | CC BY-SA 3.0 |
Rolled back invalidating edits from answer
|
| Jun 17, 2013 at 21:29 | comment | added | fge |
Well, this is a message provider API, the end user calls .getMessage() from another class, not this method. And there are providers which are static and can therefore not throw that exception, except on purpose.
|
|
| Jun 17, 2013 at 21:28 | comment | added | bowmore | That would be ok, but it's probably better to let clients know they're calling a blocking method and add InterruptedException to the method sig, and not catch it yourself. | |
| Jun 17, 2013 at 21:13 | vote | accept | fge | ||
| Jun 17, 2013 at 20:44 | history | edited | fge | CC BY-SA 3.0 |
added 95 characters in body
|
| Jun 17, 2013 at 20:38 | comment | added | fge |
@bowmore uh OK, that is a brain fart from my part :/ So, basically, I Thread.currentThread.interrupt() before I return the value and that should be OK?
|
|
| Jun 17, 2013 at 20:36 | history | edited | fge | CC BY-SA 3.0 |
fix assylias' spelling
|
| Jun 17, 2013 at 20:32 | comment | added | bowmore | How would the Future raise it? | |
| Jun 17, 2013 at 19:39 | comment | added | fge | @bowmore uh, I'd like to avoid that if I can :/ Is there a way to distinguish between the future raising it or the client actually being interrupted? If I add the exception to the signature, this also means I have to add the exception on all the call chain (given that the library provides log messages, that is rather a pain!) | |
| Jun 17, 2013 at 19:28 | comment | added | bowmore |
@assylias You're actually right. The client calling getMessageSource() is blocking on the Future.get(). If that client is interrupted, the interrupted flag is not set when exiting getMessageSource() and the client will not know it got interrupted, and needs to clean up. Proper solution here seems to simply add InterruptedException to the method signature : clients have a right to know they're calling a blocking method.
|
|
| Jun 17, 2013 at 18:53 | history | edited | fge | CC BY-SA 3.0 |
added 422 characters in body
|
| Jun 17, 2013 at 18:35 | comment | added | assylias | You are right, only you have access to the ExecutorService and the tasks so an interruption would come from your class and you can ignore it. My mistake. | |
| Jun 17, 2013 at 18:32 | comment | added | fge |
In "your code", you mean the Callable in Future or the call to .getMessageSource()?
|
|
| Jun 17, 2013 at 18:24 | comment | added | assylias |
It is possible that the scheduled thread starts before your constructor finishes (unlikely but possible). If that happens, sources might not be initialised yet.
|
|
| Jun 17, 2013 at 18:21 | comment | added | fge |
@assylias (as to sources) really? Uh! How is that possible? (as to interrupting) I am not sure I am following you here? I catch InterruptedException here as a possible result of the FutureTask's .get() call
|
|
| Jun 17, 2013 at 18:05 | comment | added | assylias |
Just 2 comments: (i) Technically (although unlikely), sources could be null in setupExpiry as your constructor has not completed yet. (ii) In case of InterruptedException, you could probably reinterrupt Thread.currentThread.interrupt(), as a courtesy to the calling code.
|
|
| Jun 17, 2013 at 17:55 | answer | added | bowmore | timeline score: 3 | |
| Jun 16, 2013 at 17:26 | history | edited | fge | CC BY-SA 3.0 |
Code update to the latest HEAD
|
| Jun 16, 2013 at 16:18 | history | asked | fge | CC BY-SA 3.0 |