500 - DB functie is mislukt met het volgende foutnummer 2006
MySQL server has gone away SQL=SELECT a.`userid` as _userid , a.`status` as _status , a.`points` as _points, a.`posted_on` as _posted_on, a.`avatar` as _avatar , a.`cover` as _cover , a.`thumb` as _thumb , a.`invite` as _invite, a.`params` as _cparams, a.`view` as _view, a.`friends` as _friends, a.`groups` as _groups, a.`events` as _events, a.`friendcount` as _friendcount, a.`alias` as _alias, a.`profile_id` as _profile_id, a.`storage` as _storage, a.`watermark_hash` as _watermark_hash, a.`search_email` as _search_email, s.`userid` as _isonline, u.* FROM `cca_community_users` as a LEFT JOIN `cca_users` u ON u.`id`=a.`userid` LEFT OUTER JOIN `cca_session` s ON s.`userid`=a.`userid` AND s.`client_id` !='1' WHERE a.`userid`='0'

also getting this:

JUser: :_load: Gebruiker bestaat niet

(User does not exist)

Hi Andrew,

Pls ask your hosting support to double increase the 'max_allowed_packet' at MySQL configuration.

Cheers,
Albert

We are hosting with SiteGround and have not experienced this error until we did the upgrade to 3.1.1. Why are we getting this issue now? I really need to get an explanation of this.

Pls, this is urgent!

Thanks

Hi Andrew,

you must set max_allowed_packet=64M at MySQL config.

The reason it too technical:
max_allowed_packet sets an upper limit on the size of any single message between the MySQL server and clients, including replication slaves. If you are replicating large column values (such as might be found in TEXT or BLOB columns) and max_allowed_packet is too small on the master, the master fails with an error, and the slave shuts down the I/O thread. If max_allowed_packet is too small on the slave, this also causes the slave to stop the I/O thread.

Row-based replication currently sends all columns and column values for updated rows from the master to the slave, including values of columns that were not actually changed by the update. This means that, when you are replicating large column values using row-based replication, you must take care to set max_allowed_packet large enough to accommodate the largest row in any table to be replicated, even if you are replicating updates only, or you are inserting only relatively small values.

Simple say:
This issue happen because your site DB still growing (getting much) and our query getting complex to handle big DB.

Regards,
Albert

This can not be true, I'm sorry. Well not in our case!

1) Our database is not that big, especially not for JomSocial part
2) This was not an issue before 3.1.1
3) It only happens in the two places, Edit My Profile - Profile & Details
4) It does not happen anywhere else on our site, even in areas which has a lot more data e.g. jReviews, EasyBlog, etc...

The changes can not be made at SiteGround as we are already on a Joomla Optimized hosting solution with SiteGround.

Please escalate and get back to me urgently.


Thanks

Urgent help required on this please.

This is becoming a bigger issue, can someone from JS Support please get back to me on this issue urgently?

Hi Andrew,

Do you have the live copy/mirror site at you localhost? (using same DB data with live site)
if yes, this error happen in your localhost?

I saw your akeeba backup filesize. Main site database only file size 122 MB, that very big DB.

Can you hosting provider changing this settings:

php.ini
max_execution_time = 120
max_input_time = 120

my.cnf
wait_timeout = 120
connect_timeout = 120
max_allowed_packet = 64M

We have a copy of the site, however it is NOT using the same database.

my.cnf CANNOT be changed as we are on SiteGround hosting account.

Do you want to tell me that 122MB database is very big? Well, that is not that big in my opinion. We are still going to add a lot more data to it.

Can you give me a clear, detailed and direct explanation why we have this issue?

Now the strange thing is that this was never an issue until we did the update to 3.1.1. I can not believe that it would be so much more resource hungry than 3.1.0.4, that the same hosting setting would fail.

We have jReviews and EasyBlog which have a lot more data in MySQL than what JomSocial has on our current site, and we have absolutely no issues anywhere else on the site except for these two pages:

www.opgroeigids.nl/mijn-details/profiel/edit

www.opgroeigids.nl/mijn-details/profiel/editDetails


This is just very strange as it does not give us any errors anywhere else on the site not even in JomSocial.

Further info:

We have a dev site running on the same server with the same database and pretty much an exact copy of the live site. Also upgrade JomSocial to 3.1.1 and it works there so something went wrong during the update on our live site...

Can we reinstall 3.1.1 without affecting our site in anyway, e.g. loosing changes, etc... We have custom default avatars, custom profile images for Male, Female, Groups, Events, etc...

Hi, Andrew.

I confirm, when I browse to profile edit, page become offline (see att.)
here is 504 explained: www.checkupdown.com/status/E504.html

Could you ask your hosting company for assistance? Could they (and maybe you have access to it) share server logs. Then we'll see what exactly throws that error.

PLEASE read the ticket, the full detail I sent. We have spoken to our host (Siteground) already (as per details).

We have also a DEV site on the same server, same account and same Host (Siteground), the DEV site works perfectly. It is only the live site which has the issue.

Can you please make this issue a priority and help us resolve it today. We have been struggling the whole week to get this resolved.

We also have Cloudflare and Siteground now looking into this issue. I will update you as soon as I know more.