Url could not be resolved error

Scott Forsyth

Posted on 09/03/2022 00:12:29

Hello,

I'm tracking down an issue on a site which may have existed for a few years. We find that the GeneralLog has over 60M records per month and we're running into performance and stability issues on this site, which appear to be related to the logging.

Most log entries are "Url could not be resolved". I tracked down where that is occurring and why:

(6 minute deep-dive video) https://www.dropbox.com/s/66vogo48m34vg6o/2022-03-08_17-55-01.MP4?dl=0

btw, I see another forums post about the same error: https://doc.dynamicweb.com/forum/cms-standard-features/cms-standard-features/url-could-not-be-resolved. However, that one has a different signuture with the full URL. That said, the code path would have had to hit the entry that I show in the video, so possibly they are tied together in some way.

This is not causing an obvious error, but the benign log entry (4 entires for every visit to the product page) is leading to performance issues.

Thanks!

Scott

Replies

Nicolai Pedersen

Posted on 09/03/2022 10:12:17

This post has been marked as an answer

Hi Scott

Thank you for the video. This problem has been around for a long time and we never nailed it completely. But I believe I found the issue using your video.

Your analysis is not completely correct. The log entry is there because it is an unwanted situation that we have not been able to fix - that part of the code should not be reached and that is why it is logged.

Your analysis is starting in GetFriendlyUrl(int pageID) because you call that with the json page id. Problem is that you do a .ToString() on that ID in the template - and that is what is causing this issue. You pass the ID as a string and not as an int as expected. Instead the call from the template go through GetFriendlyUrl(string internalLink) - which does end up resolving partially right after the bad log entry is being made. In my test if I pass "3408" it resolves to "/home?3408" which works - but is not correct.

You can solve the issue on your solution by casting your pageid to an int instead of a string.

In the Searchfriendly url API I have implemented a check on the internalLink to handle this scenario - so if it gets an id as a string, it will convert and pass it on to the right method. Probably better than throwing an exception which is should.

This method will still fail if it is called with something which is not a valid internal URL - i.e. "shithappens.aspx?bad=123" - that would still hit the "Url could not be resolved" logging - which it should.

Please let me know if casting to an int for pageids solves your logging issue.

Thank you very much for the video!

BR Nicolai

Votes for this answer: 1

Nicolai Pedersen

Posted on 09/03/2022 10:36:46

This post has been marked as an answer

Hi Again

Made this even more resilient to bad data:

Votes for this answer: 1

Scott Forsyth

Posted on 09/03/2022 18:15:32

Hi Nicolai,

Nice! Glad that this helped provide a repro on what sounds like a long running ghost.

Your code fix looks good to. That should do the trick.

And yes, we can cast to an int in the meantime. It's good to know what it was. Thanks for the recommendation on that.

Scott

You must be logged in to post in the forum

Developer forum

Url could not be resolved error

Replies