Slow hostname resolution on first call, possible to disable host info?

[marksto]

Hi Peter!

I've noticed quite a while ago that calling the streams->telemere! fn to enable standard stream/s -> Telemere interop on JVM takes quite some time. It's 5 seconds on my dev machine. The problem is, when I do it unconditionally, upon my logger ns loading (as I think that this is the right way to enable such a thing), it slows down the REPL startup by that 5 seconds.

My working hypothesis was that it somehow ends up grabbing the hostname (i.e. calling (InetAddress/getLocalHost)), which is well known for taking that much time at the first call. If I make this call in advance, and then do the streams->telemere! call, the second one takes 0.385 ms.

But how does it end up making that hostname call? And why? Is there any way to avoid this? What if I don't even need this :host information in my signals in the first place, say when developing an app locally?

Any ideas on how to get around this issue are more than welcome! =)

Cheers,
Mark

[ptaoussanis]

@marksto Hi Mark, thanks for pinging about this!

So you're likely correct that it's the hostname check slowing things down. When you call streams->telemere!, a signal is created here. That's probably your first (or one of your first) signals created, so it's hitting a cold hostname cache here which by default will try wait up to 5s before giving up.

What if I don't even need this :host information in my signals in the first place, say when developing an app locally?

Good question :-) There's not currently any way to manually tune the 5s timeout or prevent a hostname check since it's considered part of the standard signal data.

In principle it wouldn't be difficult to add an option for one/both of these, but that would mean another config option so a little added complexity.

If the main problem is wanting to avoid this in dev, my first inclination would be to suggest trying to fix the cause of the slow host resolution if that's possible.

Maybe your local host config isn't mapped correctly?

Does it maybe help to add something like this to your /etc/hosts, etc.?:

127.0.0.1   localhost mymachine
192.168.1.50 mymachine.local mymachine

Please let me know if this helps, otherwise I'll give some more thought re: adding an option to change the hostname timeout and/or just disable it 👍

[marksto]

@ptaoussanis Sure, I've studied the codebase first and also hit that impl/signal! call there. But isn't this one configurable via mws/xfns? Simply dropping the :host from all signals globally in the dev env should be enough to stop this particular and all other calls from reaching to the hostname, right? Of course, postponing the streams->telemere! call to after the setup.

And, yeah, thanks for pointing to /etc/hosts file, but let's assume I can't change its contents for reasons. Mine is a bit fancy.

[ptaoussanis]

But isn't this one configurable via mws/xfns?

That's a good instinct, but unfortunately not - xfns apply after the initial signal is created (with the hostname). You'd be dropping the key, but only after paying the cost to get its val.

In most cases that's not a problem since the hostname is heavily cached - but it's relevant for the first call in your case.

And, yeah, thanks for pointing to /etc/hosts file, but let's assume I can't change its contents for reasons. Mine is a bit fancy.

If there's some reason you can't fix the host resolution, then probably I'd need to add option/s to control the timeout or just disable hostnames altogether.

Will give it some thought.

No way you can at least address the hosts issue temporarily?

[marksto]

but it's relevant for the first call in your case

Yeah. Like each and every first call — when (re)starting the REPL or when (re)running the tests.

No way you can at least address the hosts issue temporarily?

Nope. 🥲 Since there are some 10 records pointing (sub)domains to the localhost that I need for one of my projects. But just for the sake of science, I edited my local hosts to a bare minimum and didn't see any difference — it's still 5 seconds for that call.

What's worse, whenever I switch to, say, a remote dev environment, the problem may bubble up again.

Will give it some thought.

No rush on my side, mate. Sadly, there is no obvious workaround here (e.g. altering the encore/hostname var root), since all of this depends heavily on the order in which namespaces are loaded and how those namespaces actually signal things. I've already factored all logging logic into a dedicated component, but I see how things get logged before it starts up, and probably the hostname is grabbed even before the streams->telemere! call takes place. That said, the only viable solution to this issue is to have a global conditional kill switch for this feature some day...

Thanks for the input!

[ptaoussanis]

@marksto Hi Mark!

New release (Telemere v1.2) should be coming soon with a new config option to disable hostname and/or thread info in signals.

Does this look reasonable for your case? You'd be able to disable with an ENV var, JVM property, or resource (file) on your classpath (relevant details here).

[marksto]

@ptaoussanis Hi Peter!

Yay, a Christmas gift! 😅 Yes, for sure, having that new config param(s) is totally reasonable (since I have no other option) and it should work out, unless there are other places in the Telemere/Encore codebase that end up with an implicit hostname retrieval which happens before the first execution of the signal! macro's logic.

Cheers,
Mark

[ptaoussanis]

unless there are other places in the Telemere/Encore codebase that end up with an implicit hostname retrieval which happens before the first execution of the signal! macro's logic.

That's a good call-out. I don't believe there's anywhere else, though it might be worth confirming. I'll check on that 👍