David..

5 hours ago, Marc Stridgen said:

Please disable all 3rd party items, not just that one. We have many many people use these login methods, so it doesnt appear to be a widespread issue on this one

I did try this. Disabled everything via support and the issue was still present. I am not asked for a display name.

1 hour ago, Marc Stridgen said:

It should indeed ask for a display name. On taking a look at your system, I would advise on disabling all 3rd party items and then testing this again. Especially the OAuth one you have there, as that would touch all the same areas. 

I tried disabling the OAuth you mentioned, and the issue is still present.

Are you able to reproduce on test environments perhaps?

If someone visits x website and tries to create a social login account via the Oauth connected to the community, the account creation flow is interrupted and it does not ask for display name, rather just asks to allow the scopes and redirects back to the website.

This in turn seems to cause incomplete members which will eventually be deleted by the system.

When creating a new account via /oauth/authorize/ URL, the account creation flow should still ask for our display name/email. This does not happen when using social logins under "Sign In Faster".

Just now, Jim M said:

You would need to restore any modified files, fix or disable third party applications/plugins logging items, fix the database table engine, and anything else mentioned under support for us to move forward with our investigation.

Can we schedule a 1 hour timeframe to do this? Undoing modifications and disabling plugins will basically force me to keep the community offline.

So when that is done, and clearincompletemembers task is still causing issues, I can notify IPS support that the issue is still present and a review would begin shortly after.

40 minutes ago, Jim M said:

Unfortunately, the only solution would be to get the community in a place which we can investigate further. There are no means to disable one background task.

Would IPS be satisfied enough to review the issue if:

• I turn off Oauth completely (turning it off completely is the fastest solution given the current information)
• I convert that single MyISAM table to InnoDB (ipb__core_store at 12MB)
• I resolve any other issues appearing under the support page

And still clearincompletemembers task would cause these slowdowns?

Would doing the above be enough for IPS to review the issue?

5 minutes ago, Marc Stridgen said:

I understand you dont believe it to be related, but we must remove the obvious causes here before we proceed any further

That is not likely something that can be solved within a few hours or days in this case. It is not a viable solution given the current slowdowns.

Is there a way to disable clearincompletemembers task while we work on resolving the issue(s) you mentioned?

3 minutes ago, Marc Stridgen said:

The reality is, if something is hitting your database constantly and causing errors, that is going to have an impact on your mysql instance. Since the problem you have here appears to be performance, I would advise on sorting that oauth thing out

I understand. But I don't think it is related.

That Oauth issue has also been there through the years and only generates one log per minute currently. Based on this, I don't see how this would cause clearincompletemembers task to cause this big of a slowdown on the entire community.

2 minutes ago, Marc Stridgen said:

Taking a look at your system there, you need to the address the items showing up in System>Support in your admin CP. Its showing that you have issues with database tables and that some are not INNODB. This will certainly impact performance. In addition you have 3rd party items there that are logging issues constantly on your server, and cloudflare is currently in use. I would advise on starting with these before anything else

Only 1 single empty table is not InnoDB. My backup was complaining about that so I had to switch.

Those seem to be Oauth issues, which should be unrelated to clearincompletemembers task, I believe.

As for Cloudflare, that should not be an issue. We’ve been using it for years and we know what not to enable in Cloudflare for IPS to function.

@Jim M I can confirm now that the slowdowns are being caused by clearincompletemembers task.

Are you able to look into solving this matter please?

Another issue that may be related is that the clearincompletemembers task is constantly locking for me and failing to process or complete.

Could that be related to the above query/issue? I think it may be. As soon as I manually run the task, the query seems to pop up and cause a slowdown. Any way to resolve this?

@Jim M So as you saw, the community is quite snappy.

The issue here is that as soon as this query comes up in the MySQL processlist, the whole community starts to slow down.

IPS\Content\Search\Mysql\_Index::removeClassFromSearchIndex:279

The issue here is that the query never seems to go away once it comes up (or it does and just keeps looping? I noticed the number changes from 279 to 278 to 265 randomly). But it always is there, running.

To solve this issue, a simple MySQL restart does it, until the query comes back eventually.

I've never had this issue before. It only started once I attempted to use Elastic Search which did not work well for me so I switched back. Another thing that may be contributing is the recent switch to a new server, but would it be related if a simple restart and clearing of processes fix it?

5 minutes ago, Jim M said:

You will want to take a look at your server performance if this is taking some time.

I'll investigate this again and get back to you.

41 minutes ago, Jim M said:

That would be something that you would need to analyze on your server, unfortunately. If there are any slow query logs we can take a look at, please let us know.

It’s happening again now and I notice in processlist the query is present. I won’t restart until you’ve reviewed, if you have time.

2 minutes ago, Jim M said:

Content being removed from the search index are not exclusive to the rebuild process of moving from or to MySQL. They would happen in a natural environment as content is hidden, deleted, moved, etc...

What we're trying to ascertain here is if it is from the move back to MySQL or not. 

Should that be causing such a massive slowdown to the entire community then?

For now, I will keep monitoring for when the issue returns and reply to this topic informing you. Hopefully you would be able to check as soon as possible as the slowdowns are quite infuriating for everyone.

Just now, Jim M said:

Things would be removed from the index as required by processes, tasks, or actions. Could you please wait a little to see if this is happening after these complete?

Additionally, you mentioned performance issues, are you still seeing this? Things seem quite snappy on your community for viewing, getting search results, etc...

Shouldn't the rebuild process take care of these? Are there after-tasks that need to be done once the rebuild is done?

As mentioned above, the issue seems to go away after restarting MySQL. But it eventually comes back and that is the problem.

9 hours ago, Marc Stridgen said:

No problem. Please let us know

It has not been solved. 

I rebuilt both ES & MySQL search and for some reason the queries in the above screenshot keep coming back.

Can someone take a look into this?

I left it running for a few more hours and it seems to have been completed now as there’s no tasks in ACP.

However, there are 0 improvements or changes to search results as compared to searching while it was still rebuilding. It’s still really bad for me.

Switching back to MySQL now and hopefully no issues.

12 hours ago, Marc Stridgen said:

No problem. Hope this resolves the issue for you

After rebuilding forever, at the 80% mark I am now receiving a PHP memory exhaustion message. Is 512M not enough?

Something feels wrong here. My access details are up to date.

4 hours ago, Marc Stridgen said:

Its not very clear here what state you are at. Do you still have those errors, or did it resolve completely with the restart?

It is the second time it comes back. But it does resolve after a restart so far.

I'll do what you recommend and get back to you.

10 minutes ago, Randy Calvert said:

The post table does not contain the the topic title, but remember...  the index is looking for information expected in there to make judgements on other areas to look at.  

Yes.  I would highly recommend letting the process actually fully complete before judging efficacy.  If it does not provide the results you want afterwards, switch back.  🙂. 

Will do. Waiting on a reply from IPS to decide as I don't want to make matters worse.

Does the posts table contain topic titles?

So to resolve this would be to rebuild for ES and wait for it to complete. Then the issue should be theoretically fixed then I can decide on whether to stay with ES or switch back to MySQL?

1 minute ago, Randy Calvert said:

When you move from mySQL to ElasticSearch, it has to actually build an index in ElasticSearch with information from all of the content from your site.  That will involve making lots of queries that are done as background tasks over the course of several hours.  You have to wait for that process to complete before all of the results will properly show.  You should not judge the results until the indexing is fully complete.  

 

Now...  if your site is slowing down dramatically, it most likely means your server is running close to capacity anyway.  You might try doing it during a slow time in the middle of the night OR you might consider turning your board offline for several hours while the indexing process is done if there are not sufficient resources to do it and serve your normal traffic.  

I understand. The rebuild took quite a while and everything completed except for posts. Topic titles are most important in our case, and when searching using ES, status updates appeared way too many times - sometimes even above actual topics. This was not the case with MySQL search.

Right now, nothing is processing in ACP. MySQL search is working, but it seems like there may be an underlying issue from switching to ES and back to MySQL which may need reviewing. Especially since a simple SQL restart solves the issue and clears out the process list.

I tried moving from MySQL search to Elastic Search and midway I noticed that Elastic Search results were pretty bad, so during the rebuilding of posts, I moved back to MySQL search as the results are much better. 

Everything was fine, but now I noticed the forum loading very slowly and checking processlist shows me this:

If I reboot my database, the slow loading times are instantly fixed. So this leads me to believe that the issue is in the screenshot above. Could any staff please review and hopefully fix?

I have my access information up to date

This is a thing? 
 

This definitely needs fixing ASAP.

I received this email today. What am I supposed to do?

Hello,

Full enforcement of the European regulatory requirement Strong Customer Authentication (SCA) started on 14 March, 2022 in the UK. This is your final notice from us to update your Stripe integration to avoid declined payments.

Now that the SCA deadline has passed, two-factor authentication for online payments in the UK is fully enforced and, because your WalkingWater Account account is not SCA ready, we estimate that you could lose £18.27 in revenue over the next 4 weeks.

We strongly recommend updating your Stripe integration to avoid having further declined payments. Stripe’s payments APIs and SCA-ready products are available from the Dashboard and our docs, and will help you make the required changes to your integration.

Please visit our support site for answers to common SCA questions and to get in touch with us.

Thanks,
The Stripe team