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

502 error on Migrate #211

Open
ranjit0829 opened this issue Jan 7, 2021 · 13 comments
Open

502 error on Migrate #211

ranjit0829 opened this issue Jan 7, 2021 · 13 comments

Comments

@ranjit0829
Copy link
Contributor

ranjit0829 commented Jan 7, 2021

Hello Geta Team,

We have latest version of BVN and Geta nuget packages.
Geta.404Handler.1.2.1
BVN.404Handler.11.4.0

It work fine on local dev and our development server. But fails to run on Test and UAT.
We get the following error when we try to run migrate in Admin tool.
Only difference that we see on both environments are Test and UAT are on load balancing environment.

Please see the screen shot of the error we get.
103883216-f1983280-5102-11eb-9b10-19af4439d2ad

Please suggest!

Thank you in advance!

Regards,
Ranjit

@marisks
Copy link
Member

marisks commented Jan 7, 2021

Please check your logs on the server to see what exactly failed.

@ranjit0829
Copy link
Contributor Author

@marisks we do not see anything in episerver log file in regard to this error. Also now we experiencing tool not loading in dashboard.
Please see the screen shot:
image

This is from test server.

Kindly advise.

Thank you!

Ranjit

@marisks
Copy link
Member

marisks commented Jan 7, 2021

According to the exception, you have an old version of 404 handler. Please verify that you have deployed the right version.

@ranjit0829 ranjit0829 changed the title 503 error on Migrate 502 error on Migrate Jan 7, 2021
@ranjit0829
Copy link
Contributor Author

Hi @marisks

We verified the deployed versions and latest version are in place. Now we are getting server error 502 as previous screen shot.
also verified the logs but nothing found in regard to this exception. I understand we are using epi ILogger in the tool but still nothing in the log.

Please suggest!

Thanks,
Ranjit

@marisks
Copy link
Member

marisks commented Jan 7, 2021

Sorry, but without more details, I am not able to help. You could try configuring Episerver log to include exceptions from 404 handler.
Another option - use an older version of your application and the production DB to export redirects and then import in the new version.

@ranjit0829
Copy link
Contributor Author

As per your suggestion, I tried adding appender to EPiServerLog.config. log4net created a file but did add logs to it.

I have checked sourecode, you do not use any logger name while instantiating ILogger instance.
Is something I am missing?

Thanks,
Ranjit

@ranjit0829
Copy link
Contributor Author

ranjit0829 commented Jan 8, 2021

Hi @marisks

We have noticed logging has already been working for 404 handler, as we have seen an entry when we added a new redirect dev server. So if same has been deployed on test and uat ideally in case of exception that should also be logged, if I am not wrong. Also to mentioned we have set log level debug.

Thanks,
Ranjit

@ranjit0829
Copy link
Contributor Author

ranjit0829 commented Jan 12, 2021

Hello @marisks

As per your suggestion, we replaced the database that did not run the migration before and added following entry to EPiServerlog.config:

<logger name="BVNetwork.NotFound"
            additivity="false">
    <level value="All" />
    <appender-ref ref="debugLogAppender"/>
</logger>

After we ran the migration. We are still getting this error screen shot:
104320160-f9dbdd80-5507-11eb-8909-820d7cdea234

Also there are not entries in the EPiServerErrors.log

Please see, if you can point us to resolve this.

Thank you!

Regards,
Ranjit

@ranjit0829
Copy link
Contributor Author

ranjit0829 commented Jan 20, 2021

Hi @marisks

After lot of investigation, we came to a point were thinking about some incorrect urls saved in the db might be failing the tool to load the list.

We attempt to truncate the table "BVN.NotFoundRequests" and tool started working. We also looked at the source code in brief but just wanted to be 100% sure about the impact before we do this on main servers.

Please advise!

Thanks,
Ranjit

@evest
Copy link
Contributor

evest commented Jan 20, 2021

The data in that table is historic 404 requests, which are used to display the top not found urls. For a system that has lived for a long time, it might get big. How many rows do you have in that table?

You can safely delete the content, but it you'll lose the suggestions for new 404 redirects. Old log entries have less value, so you might want to delete entries from the table that are older than a few months for an example.

@ranjit0829
Copy link
Contributor Author

ranjit0829 commented Jan 20, 2021

Hi @evest

We have almost: 805623 rows in this table.
As I understand we can safely delete entries that are older and 6 months approx, right?

Thanks,
Ranjit

@evest
Copy link
Contributor

evest commented Jan 20, 2021

That is correct, you can safely delete old entries from that table.

For context, if you're moving things around, or migrate from some other system to Episerver, you'll see an uptick in the logging to this table, as old non-working urls are being logged as 404s. These are important to add redirects for to ensure your SEO rating isn't impacted too much (some is to be expected if you move to another system).

After some time, you'll see less new entries in this log, and mostly junk as Bots keep requesting old ones and automatic checks for Wordpress login and admin pages.

In fact; from time to time; you could clear the the table completely, as junk entries tend to rise to the top over time if you're not marking them as ignored. This will ensure that new fresh 404s that you care about is handled correctly.

@ranjit0829
Copy link
Contributor Author

Hello @evest, @marisks,

We have performed the truncate table activity on servers on 'BVN.NotFoundRequests' table and later tool worked fine. We were getting 502 error as mentioned in the screenshot due to heavy data in this table for around 12+ million records.

Possibly, If you could let us know what would you suggest for below question..

  1. What is it we can do to handle this and stop breaking the tool in near future. Is truncate only the option?
  2. If we have a old and new urls in the tool already for sometime. By when we can be sure that this particular entries will not be used anymore and are good for clean-up?

Kindly suggest!

Thank you for all your help on this. :)

Regards,
Ranjit

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

No branches or pull requests

3 participants