Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get-hostname caches exceptions #303

Closed
xificurC opened this issue Feb 14, 2020 · 5 comments
Closed

get-hostname caches exceptions #303

xificurC opened this issue Feb 14, 2020 · 5 comments

Comments

@xificurC
Copy link

I'm interrupting a thread group and occasionally the interrupt renders most of my code unusable. The reason seems to be that get-hostname caches the InterruptedException for 1 minute.

@ptaoussanis
Copy link
Member

Hi @xificurC, with what version of Timbre are you seeing this? Are you able to provide a reproducible example?

Thanks!

@ptaoussanis
Copy link
Member

Not sure precisely what's happening in your case, but have made get-hostname a little more robust in the next release.

@xificurC
Copy link
Author

xificurC commented Sep 9, 2020

Hi @ptaoussanis , I'm sorry but I no longer have the code and version in a format where I could easily reproduce this. I think the sequence was

  • a log call is fetching the hostname
  • the thread receives an interrupt during the hostname lookup
  • the interrupted exception gets cached/memoized as the result

Any other log calls would throw at that point. However if I waited 60 seconds then the logs started working.

Does that make sense? I remember thinking a solution would be to not cache exceptions.

@ptaoussanis
Copy link
Member

@xificurC Thanks for the quick response!

Exceptions aren't cached, and actually the code to fetch the hostname also traps exceptions.
Two things I can imagine may have been happening:

  1. You were using a really old version of Timbre before hostname fetching caught exceptions.
  2. The code to create a thread was somehow throwing.

Have made a mod that will cover the second case. Beyond that will suggest that this can probably be closed for now, and someone can reopen if they run into trouble again with the upcoming release.

@ptaoussanis
Copy link
Member

Closing for now as part of issue triage, please feel free to reopen if this is still relevant!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants