HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


Problems with the new server at Arvixe

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#104972 (In Topic #20476)
Avatar

Community saint

[sigh]

So, Arvixe has been migrating accounts from their old servers to new servers. From the email regarding the migration of the server my hosting account is on:

We have started migration for all customers on the server Sardine to a new, better, stronger server. We are proud to offer this top of the line, industry leading, configuration to the long-time clients on the Sardine server. Benefits of the move include:

1. The new server features a RAID SSD array for MySQL and OS partitions. This allows for the fastest possible access to your databases, files, and more.
2. Redundant 10 Gig hookups allowing for the least amount of network disruption possible in case of attacks or abuse.
3. The new server has three times the amount of ram than the older server. This would allow further caching of IO which is generally the bottle neck on shared hosting services.

We look forward to helping you out in making the move as painless as possible. Please remember we are doing this for the overall betterment of services and the improved network and performance of your hosting account.


Unfortunately this migration is turning into a migraine. Right from the start there was the CloudFlare IP issue that was quickly resolved by compiling mod_cloudflare into Apache, though it worries me that Arvixe is a CloudFlare hosting partner and nobody thought to configure mod_cloudflare or some other CloudFlare IP workaround on the new server. It makes me wonder how many other new servers they configured that don't have mod_cloudflare when there could be accounts on them servers that need it. Not having mod_cloudflare essentially prevents the IP bans in .htaccess from working if you are using CloudFlare as a CDN. There has been a fairly constant high load average on the server (http://stats.sardine.arvixe.com) that I initially attributed to people making changes to their accounts on the new server and any residual work that needed to be done for the migration. After being online for barely more than 24 hours, the high load was recognized by the Arvixe staff as abnormal and they issued an alert for the server (http://www.arvixe.com/alerts?key=108457-100091). The alert has been ongoing with no solution since September 29th. They have been disabling 'abuser accounts' which I don't think is the root of the problem. My server response times when loading my ocPortal-based sites are fluctuating wildly and vary from less than 5 seconds to well over 40 seconds before pages start loading in the web browser. The admin zone can be particularly brutal. It appears to be related to mySQL queries taking way too long. I'm also seeing abnormal CPU spikes in my hosting account from the Resource Usage app in cPanel, even when web site traffic is very low and I experience very slow page loading during these spikes. It seems either mySQL is causing high CPU usage and resulting in long query times, or something Apache or PHP related is causing the high CPU usage resulting in long query times. For full disclosure and additional information, I have 6 web sites in my Arvixe PersonalClass Pro hosting account: 3 closed ocPortal sites for future development and I haven't done any speed checks with these sites after the migration since they are not being used right now, 2 open and low traffic ocPortal sites (holleywoodstudio.com and tfo.net) and both are experiencing fluctuating long server response times, and 1 CMSimple site (goldncountrygifts.com) that doesn't use mySQL for displaying page content and has consistent server response times of 1 to 3 seconds. There are 2 additional domains that are setup as redirects, and they redirect with no problems.

In addition to these issues, after the migration I have noticed an ocPortal warning message that is displaying on the logon screen:
Your server is failing to connect to itself. Try enabling the "My server uses firewall and IP forwarding, or uses a Windows computer name instead of DNS" option.


If I enable the option "My server uses firewall and IP forwarding...", then that warning message goes away and I get this one in its place:
A problem has been detected with your web server that may cause your login to fail – if it does, click back and read the rest of this message. Some servers are poorly configured, and invisibly redirect traffic from one URL to another, and this invisible redirection results in lost submitted form data. Try changing your base URL in the config editor so that it doesn't contain www. then come back to this URL (make sure to refresh the page) and try again. There can be other causes, such as your server blocking web requests to itself. If problems persist, contact your web host.


Should Arvixe change something on their end to correct that, or should I adjust my ocPortal installation settings to correct for the changes on their end?

I have an open support ticket and forum post at Arvixe for these issues as well: http://forum.arvixe.com/smf/general/ticket-lws-769-85593/
Back to the top
 
Posted
Rating:
#104973
Avatar

Fan in action

Heya,

I don't think I can directly help however you helped me previously so I may as well put in my rookie 2 cents.

I see Arvixe is recommended and quite large, If the issues began when they migrated you I would think it more their problem to solve.

My webhost 'solved' some issues i was having with ocportal and mod security and also turned off php selector to solve a 503 LitespeedWS lockup issue.

ATM my Magento on subdomain is slow, but this is a DNS thing as cloudflare needs CNAME record for wildcard / subdomains.

Perhaps check your cloudflare in your cpanel app (dns settings as arvixe is CF partner) and make sure all the IPS there and in your advanced DNS editor are for the new server.

Aside from that I would think a good host who breaks things from unvoluntary migrations should be getting their lvl 2 admins or equivelant to have a look and fix it.

This being said if you are correct and they have done this to everyone the turnaround may be slow (your plan sounds like it should have good priority though). Depending on how urgent you need it fixed or if you fear they will ban you as an 'abuser' due to something they broke, depends if you should spend your own time or let them fix it eventually.

My hosts always try their best and do alot of changes for me as I don't really code but I find sometimes the offhours workers (as their 24/7) have a much lesser knowledge base to provide me with. However they are super helpful generally.

Sorry i couldn't be more help but sometimes its the simple things they have forgotten to change for migrating as my hosts have forgotten to do things several times iv been migrated lol. :)

Yours Sincerely,
Dylan
Back to the top
 
Posted
Rating:
#104976
Avatar

Hi,

For the "A problem has been detected with your web server" error, this might be mainly our fault rather than Arvixe's. Could you try the latest version of pages/modules/login.php?
https://raw.githubusercontent.com/chrisgraham/ocPortal/v9/pages/modules/login.php

I think the current version we have might have recursed a couple of times checking self-calling works and thus got filtered out on some server configurations and thus triggering that error. People have reported it a lot.
The latest git code is a little smarter, and I think for v10 we'll change it some further.

I'll point Arvixe to this topic.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#104977
Avatar

Community saint

Dylan, thanks for the input. It's always good to get ideas and input from another perspective.

ProphCore said

Heya,

I don't think I can directly help however you helped me previously so I may as well put in my rookie 2 cents.

I see Arvixe is recommended and quite large, If the issues began when they migrated you I would think it more their problem to solve.
Exactly my thoughts, with the sites performing fine under the old server and now suddenly all kinds of slowness under the new server with no site changes on my end would make it a problem that Arvixe needs to get worked out on their end. And I can say they are trying to solve the issues, but almost two weeks on a broken server and it has gotten worse instead of better over the past couple of days, so that has shaken my confidence more than just a little with Arvixe.

ProphCore said

My webhost 'solved' some issues i was having with ocportal and mod security and also turned off php selector to solve a 503 LitespeedWS lockup issue.

ATM my Magento on subdomain is slow, but this is a DNS thing as cloudflare needs CNAME record for wildcard / subdomains.
Yes, it's always a good sign when your web host will go out of their way to add/remove or enable/disable particular things for your account to add features you need or to solve problems for you. Arvixe is like that as well. Whether you are on a shared server, VPS, or dedicated server, they will do whatever they can to accommodate the needs of their customers…within reason. There are some things that just can't be reasonably done, but they do go above and beyond what some other large web hosts will do for their customers.

ProphCore said

Perhaps check your cloudflare in your cpanel app (dns settings as arvixe is CF partner) and make sure all the IPS there and in your advanced DNS editor are for the new server.
That was one of the first things I checked. The migration only resulted in the server machine main IP address changing. All other IPs were routed to the new server. Everything looks correctly configured in the Advanced DNS Zone Editor. I even disabled CloudFlare for a day on one site to see if it would improve response times and it made no difference.

ProphCore said

Aside from that I would think a good host who breaks things from unvoluntary migrations should be getting their lvl 2 admins or equivelant to have a look and fix it.
They have assured me it has been escalated to the highest level and they will continue to work on it until it's fixed. It's just taking too long to fix a problem that should never have happened to begin with. It's not like this was the first migration they've done.

ProphCore said

This being said if you are correct and they have done this to everyone the turnaround may be slow (your plan sounds like it should have good priority though). Depending on how urgent you need it fixed or if you fear they will ban you as an 'abuser' due to something they broke, depends if you should spend your own time or let them fix it eventually.
From the responses I've gotten from Arvixe, it appears they are having trouble pinpointing the root cause of the problems. I'm not in a situation where this issue is costing me money, it's just wasting alot of time waiting for pages to load and save. Sure, time is money, but most of what I do is hobby related for myself and not as a business so the need for a fix isn't critically urgent. The fear of being labeled as an abuser is a concern. It looks like Arvixe can throttle CPU and I/O usage to prevent one shared hosting account from affecting the whole server, so I'm hoping the brief spiking CPU usage in my account won't put my account under review for suspension. So far the average CPU usage for my account is very low, but that could change if one or more of my sites gets a higher than usual burst of traffic and causing more frequent high CPU usage spikes. The other areas for faults that could trigger a suspension (virtual memory usage, physical memory usage, entry processes, and processes) are all well within acceptable limits for my account. This is the Resource Usage for the past 7 days:
Back to the top
 
Posted
Rating:
#104978
Avatar

Community saint

Chris Graham said

Hi,

For the "A problem has been detected with your web server" error, this might be mainly our fault rather than Arvixe's. Could you try the latest version of pages/modules/login.php?
https://raw.githubusercontent.com/chrisgraham/ocPortal/v9/pages/modules/login.php

I think the current version we have might have recursed a couple of times checking self-calling works and thus got filtered out on some server configurations and thus triggering that error. People have reported it a lot.
The latest git code is a little smarter, and I think for v10 we'll change it some further.

I'll point Arvixe to this topic.
Thanks Chris. I tried the updated login.php but still get the "A problem has been detected with your web server" error. I cleared the browser cache, ocPortal cache, and CouldFlare cache. Do I need to update my Base URL config setting to remove the www (I'm currently using www for the main domain URLs)? I'll look into it further when the site is responding better. Right now it's virtually impossible to get anything done. Using the View Queries option in the Select page rendering tool dropdown in the web site footer I am seeing very long query times affecting page load times: 

Main homepage @ holleywoodstudio.com - Total Queries: 217, Total Time: 87.245
Main adminzone homepage @ holleywoodstudio.com - Total Queries: 310, Total Time: 122.108

Today has been unusually bad with the response times. Sometimes it's reasonably tolerable, but most of the response times and the occasional timeouts I'm getting today have made it extremely difficult to get anything done.

From phpMyAdmin->Status->Monitor there appears to be high CPU usage:
Back to the top
 
Posted
Rating:
#104979
Avatar

Community saint

The sites are still sluggish but not as bad as before. I added some debug code to login.php to list out a couple of variables. In the login_before function, I added some code to output the $_login_url, $test, and $GLOBALS['HTTP_MESSAGE'] variables. If I'm logged out and go to http://www.holleywoodstudio.com/pg/login/misc, I get this:

_login_url = http://www.holleywoodstudio.com/pg/login/misc
test = NULL
http_message = 404

If I'm already logged in and go to that page, I get the same _login_url and test variable data, but the http_message is now 200. But if http_message is 200, wouldn't it break this if clause at ($GLOBALS['HTTP_MESSAGE']!=='200'):

Code


if ((is_null($test)) && ($GLOBALS['HTTP_MESSAGE']!=='200') && ($GLOBALS['HTTP_MESSAGE']!=='401') && ((!is_file(get_file_base().'/install.php')) || ($GLOBALS['HTTP_MESSAGE']!=='500')))
{
  if (($GLOBALS['HTTP_MESSAGE']=='no-data') && (get_option('ip_forwarding')=='0'))
    {
      attach_message(do_lang_tempcode('config:ENABLE_IP_FORWARDING',do_lang('config:IP_FORWARDING')),'warn');
    } else
    {
      attach_message(do_lang_tempcode((substr(get_base_url(),0,11)=='http://www.')?'HTTP_REDIRECT_PROBLEM_WITHWWW':'HTTP_REDIRECT_PROBLEM_WITHOUTWWW',escape_html(get_base_url().'/config_editor.php')),'warn');
    }
}

and stop the warning and my debug code from displaying? Or why would I get a 404 in one case and a 200 in the other? I'll have to trace the _http_download_file function to understand what exactly is happening behind the scenes.

I add the following debug code to the else clause in the code above, under the last attach_message line:

Code


attach_message( "_login_url = ".$_login_url, 'warn');
if ($test == NULL) $test="<null>";
if ($test == "") $test = "<blank>";
attach_message( "test = ".$test, 'warn');
attach_message( "http_message = ".$GLOBALS['HTTP_MESSAGE'], 'warn');
 


I left the debug code in login.php so you can see the result at http://www.holleywoodstudio.com/pg/login/misc.
Back to the top
 
Posted
Rating:
#104992
Avatar

It's odd that the "Work-around IP forwarding" would return 200 in some events and 404 in others. Maybe some kind of caching layer sometimes "knows" more than the full processing pipeline does, or vice-versa.

This is where it is implemented in sources/files2.php

Code

      if (($base_url_parsed['host']==$connect_to) && (function_exists('get_option')) && (get_option('ip_forwarding')=='1')) // For cases where we have IP-forwarding, and a strong firewall (i.e. blocked to our own domain's IP by default)
      {
         $connect_to=ocp_srv('LOCAL_ADDR');
         if ($connect_to=='') $connect_to='127.0.0.1'; // Localhost can fail due to IP6

However, I'd just turn it off, as there is no reason to expect the option to work on every server, it's just a tool that may or may not be of use to some people.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#105001
Avatar

Fan in action

Heya Jason,

Thanks for your detailed response even though you had checked most of my suggestions already.

As i plan to continue using and learning ocportal i'll try to contribute to the forums, even though ive never been much of a forum person lol.

I hope this issue can be resolved for you shortly and no account flagging / actual loss occurs..

 Im also having ongoing issues but its from one issue to the next lol. Atm Magento redirects arent working, all pages aside from home 404 and no extensions seem to actually work/render. I think maybe my htaccess file is broken lol.

However OCportal is working fine atm and I have everything cloudflared using CFs DNS (because I learnt hosting partners cant use CFs new free plan universal SSL, leaving ssl gap :O ). So basically i have CF and double sided ssl on both sites, just gotta figure out why magentos stuffed atm lol :P (but my webhost is getting a lvl 2 admin to investigate, yay :) )

The Joys of Webmastering :P

Goodluck Jason, hopefully Arvixe can solve the issue. You may want to address your concern to them about being flagged. That way as they acknowledge its their issue, reason implies its illogical to flag accounts when they are the ones that made them inefficient with resources and no 'abuse' actually has taken place.

Yours Sincerely,
Dylan
Back to the top
 
Posted
Rating:
#105008
Avatar

Community saint

Finally, some progress. Regarding the warnings on the login screen, it looks like Arvixe did something on their end and now those warnings are gone. The mySQL queries are running much faster and, as a result, server response and page load times look like they are back to normal.  I'll cross my fingers and hope it stays running smooth. 
Back to the top
 
Posted
Rating:
#105035
Avatar

Community saint

Well, the mySQL queries were still being intermittently delayed causing some slow pages loading, though not nearly as bad or as often as it had been. To (hopefully) solve this, Arvixe has replaced mySQL with a drop-in replacement called MariaDB. So far it looks like it is working well, with 210 to 215 main page queries executing in a total time that is mostly between .25 and .55 seconds.
Back to the top
 
Posted
Rating:
#105100
Avatar

Community saint

Chris, things are almost back to normal, but I have a couple of new issues that I'm not sure how to fix or where they came from and I'm hoping you've seen them before and can point me in the right direction. There is no hurry, the issues don't seem to be affecting regular site visitors and I can still administer my site. (If your IP address is the same, you should still be able to access my holleywoodstudio.com site as admin)

The issues only seem to be affecting one (holleywoodstudio.com) of my two main ocPortal sites. The main differences between the two are the holleywoodstdio.com site is on the most recent 9.0.14 version and it uses the Short URLs option (with mod_rewrite), the tfo.net site is on 9.0.13 and doesn't use the Short URLs option. And there are some addon differences between the two installations.

One issue is a critical error from ocPortal, but only when I logon as admin and only in certain zones. I can logon and use the CMS and Admin zones as well as other zones I have added, but the main site zone and forum give me this critical error:

Critical error – bailing out

This is an error that has been elevated to critical error status because it occurred during the primary error mechanism reporting system itself (possibly due to it occuring within the standard output framework). It may be masking a secondary error that occurred before this, but was never output - if so, it is likely strongly related to this one, thus fixing this will fix the other.

There seemed to have been a loop of resource includes (e.g. a resource, such as a page, includes itself). The loop has been stopped so the server does not crash.



 

I tried the keep_safe_mode=1 switch and the pages that were giving me critical errors are still giving the same critical error with safe mode enabled. With safe mode enabled, on zones that I have added, pages that didn't generate a critical error gave me an error "The requested page (start) is missing" instead of the normal start page. I also noticed a PHP error being logged that I think is related to safe mode being enabled but haven't done any specific testing on that yet:

PHP Fatal error: Call to undefined function ocp_setcookie() in sources/support.php on line 1913

I ran the permissions checker and file integrity scan and didn't see anything unexpected. I've tried clearing ocPortal caches, CloudFlare cache, and browser cache. I don't think I changed any settings, templates, css files, or source code that would have caused the critical error.

One other issue that has popped up over the past 10 days is PHP processes have been getting stuck. I have seen it happen with cron jobs initially where the cron job would start, use an abnormal amount of CPU and memory for about a half hour before dying off. But I've also seen it happen when trying to logon as an admin. Initially, along with a critical error I was getting a timeout error due to the PHP process getting stuck, if I refreshed the page or tried another page. I enabled the profiler in ocPortal and was able to get a profile from a stuck PHP process (but not sure of the exact steps needed to recreate, since it doesn't always get stuck) and this is as far as it got before I manually killed the process:

Code

URL: http://www.holleywoodstudio.com/index.php?page=start

_do_template(x1)                                       0.0004s  COMCODE_BOLD.tpl
_do_template(x2)                                       0.0060s  SCREEN_TITLE.tpl
_do_template(x3)                                       0.0052s  COMCODE_SURROUND.tpl
_do_template(x4)                                       0.0040s  COMCODE_URL.tpl
_do_template(x5)                                       0.0005s  COMCODE_ALIGN.tpl
_do_template(x6)                                       0.0003s  COMCODE_ITALICS.tpl
_do_template(x7)                                       0.0022s  COMCODE_FONT.tpl
_do_template(x8)                                       0.0010s  COMCODE_TAB_BODY.tpl
_do_template(x9)                                       0.0069s  COMCODE_TAB_HEAD.tpl
_do_template(x10)                                      0.0028s  COMCODE_TAB_CONTROLLER.tpl
comcode_to_tempcode/LONG(x1)                           0.5039s  owned by member #6
_do_template(x11)                                      0.0054s  TAGS.tpl
_do_template(x12)                                      0.0125s  COMCODE_PAGE_SCREEN.tpl
_do_template(x13)                                      0.3982s  GLOBAL_HTML_WRAP.tpl
_do_template(x14)                                      0.0192s  MENU_BRANCH_zone.tpl
_do_template(x15)                                      0.0004s  MENU_zone.tpl
_do_template(x16)                                      0.0012s  MENU_STAFF_LINK.tpl
_do_template(x17)                                      0.0071s  BANNER_IMAGE.tpl
_do_template(x18)                                      0.0002s  COMCODE_TEXTCODE_LINE.tpl
_do_template(x19)                                      0.0043s  OCF_NOTIFICATION.tpl
_do_template(x20)                                      0.0002s  COMCODE_TEXTCODE_TAB.tpl
_do_template(x21)                                      0.0056s  HYPERLINK.tpl
http_download_file(x1)                                 12.0713s  http://www.holleywoodstudio.com/**censored**
http_download_file(x2)                                 2.6766s  http://www.holleywoodstudio.com/**censored**
http_download_file(x3)                                 1.5614s  http://www.holleywoodstudio.com/**censored**
http_download_file(x4)                                 2.8844s  http://www.holleywoodstudio.com/**censored**
comcode_to_tempcode/LONG(x2)                           176.1292s  owned by member #6

There were a couple of other profiles from stuck PHP processes and I think they all stopped with a comcode_to_tempcode/LONG line.

With the replacement of mySQL with MariaDB, the database queries are running faster. But with all of the reconfiguring and recompiling I'm wondering if these issue are related to some of these recent changes on the shared server.
Back to the top
 
Posted
Rating:
#105102
Avatar

Ok quick summary for myself:
  • "There seemed to have been a loop of resource includes"
  • Safe mode issues
  • Slow-down / profiler results

Will reply soon.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#105103
Avatar

This is odd stuff.

I doubt it is much to do with the hosting though.

"There seemed to have been a loop of resource includes"
This wasn't a very clear error message of ours. changes.zip will make it clear, say what the last level of the looping is.

It might be caused by something like the main_include_module block accidentally triggering a loop. I can't think what it could be specifically, I think I would need to test. My IP has changed, if I left a backdoor_ip line accidentally in info.php then please remove that.

If you want to open a free bug report ticket for me to investigate please go ahead. Will need FTP (or similar) details.

The safe mode issues are mostly expected/known. A custom page wouldn't load in safe mode. I think you probably have the Facebook addon installed which has caused some problems with safe mode in the past as it overloads some critical files used at startup and ocPortal gets a bit confused occasionally (because safe mode is permission-dependent, and permission associated files are overridden). I might have fixed this in v10, if I get a clear reproduction case in v9 I would fix too, but sounds like very much a corner case here.

Regarding the slow-down, I am not particularly surprised the host would be a bit erratic on recursive requests, which you can see with http_download_file in the profiler log. It leads to quite high load. However the log is indicating that this is from Comcode parsing (link checking specifically), so should not be routine. Make sure the Comcode page cache is enabled. Also make sure in sources/global2.php the is_browser_decacheing function looks like this:

Code

/**
 * Find whether the browser session is set to be doing a hard cache-empty refresh.
 *
 * @return boolean      Whether the browser session is set to be doing a hard cache-empty refresh
 */
function is_browser_decacheing()
{
   global $BROWSER_DECACHEING;
   if ($BROWSER_DECACHEING!==NULL) return $BROWSER_DECACHEING;

   if (is_null(get_value('ran_once'))) // Track whether ocPortal has run at least once
   {
      set_value('ran_once','1');
      return true;
   }

   return false;   // This technique stopped working well, Chrome sends cache-control too freely

   /*$header_method=(array_key_exists('HTTP_CACHE_CONTROL',$_SERVER)) && ($_SERVER['HTTP_CACHE_CONTROL']=='no-cache') && (ocp_srv('REQUEST_METHOD')!='POST') && ((!function_exists('browser_matches')) || (!browser_matches('opera')));
   $BROWSER_DECACHEING=(($header_method) && ((array_key_exists('FORUM_DRIVER',$GLOBALS)) && (has_actual_page_access(get_member(),'admin_cleanup')) || ($GLOBALS['IS_ACTUALLY_ADMIN'])));
   return $BROWSER_DECACHEING;*/
}
We added the "return false;" recently because Chrome started sending decache headers on every request, which led to very excessive load.

Attachment
» Download: changes.zip (54 Kb, 147 downloads so far)


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#105107
Avatar

Community saint

Thanks Chris! That helps narrow it down to likely being a notification that is causing a problem:

"There seemed to have been a loop of resource includes of block=main_pt_notifications"

I checked and verified the comcode page caching was enabled and the global2.php file was also correct. I cleared the ocPortal caches after uploading the files from changes.zip and was able to briefly get into the main homepage and forum zone without trouble while logged in as admin. I had some unread notifications waiting in the forum zone and clicked "Ignore" on the first batch of notifications. Refreshing the page to get the next batch of notifications is when the problems started again and I got the critical error message relating to main_pt_notifications. I think I also narrowed down the timeout part of the issue being caused by clearing the ocPortal caches and viewing the affected pages before the cache is regenerated.

I'm out of time for tonight. Tomorrow I'll try to get the list of notifications from the database that haven't been read yet and see if there is anything unusual there and post what I find.
Back to the top
 
Posted
Rating:
#105108
Avatar

Ah, excellent -- this makes a lot of sense. Working on it...


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Item has a rating of 5 (Liked by GuestLiked by Guest)  
Rating:
#105109
Avatar

Good, reproduced. This can happen if error message notifications go to a PT, and the error message notification is embedding the Tempcode of a failing page after also embedded a closing html tag forcing Comcode's full parser on. The failing page's Tempcode includes the panel_top which includes the notifications, and that's where it loops.


Last edit: by Chris Graham


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Important!
Posted
Item has a rating of 5 (Liked by GuestLiked by Guest)  
Rating:
#105110
Avatar

Automated fix message

Jason Verhagen said

Thanks Chris! That helps narrow it down to likely being a notification that is causing a problem:

"There seemed to have been a loop of resource includes of block=main_pt_notifications"

I checked and verified the comcode page caching was enabled and the global2.php file was also correct. I cleared the ocPortal caches after uploading the files from changes.zip and was able to briefly get into the main homepage and forum zone without trouble while logged in as admin. I had some unread notifications waiting in the forum zone and clicked "Ignore" on the first batch of notifications. Refreshing the page to get the next batch of notifications is when the problems started again and I got the critical error message relating to main_pt_notifications. I think I also narrowed down the timeout part of the issue being caused by clearing the ocPortal caches and viewing the affected pages before the cache is regenerated.

I'm out of time for tonight. Tomorrow I'll try to get the list of notifications from the database that haven't been read yet and see if there is anything unusual there and post what I find.
This issue has been filed on the tracker as issue #1707, with a fix.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Important!
 
Posted
Item has a rating of 5 (Liked by GuestLiked by Guest)  
Rating:
#105115
Avatar

Community saint

Thanks Chris! The fix worked to break the loop and display the warning message on the main homepage. But it didn't work on some other pages like the forum zone or on the Users Online page and resulted in either timeouts or blank pages instead of the critical error I was getting before. I manually sanitized a few of the notifications in the database and was able to get access to the rest of the site.
Back to the top
 
1 guests and 0 members have just viewed this: None
Control functions:

Quick reply   Contract

Your name:
Your message: