Bug vBCredits II & xCache

[Munkii]

This isn't a very easy "bug" to explain, but I'll try my best.

I have the Lite versions of both vB Optimise and vBCredits II, and they run fine for the most part. The only problem I've encountered is after a period of time the credits on my forum disappear. I don't believe it's a conflict with any other mod because they show up perfectly fine for hours at a time, then disappear and eventually come back later on. I've figured out that when they do disappear, if I "Flush Cache" for vB Optimise they come back as if they were never gone.

I'm not talking about missing credits, or not getting what I earned, etc, but the actual display of credits is what's disappearing randomly. Also, when they aren't visible, under "Multiple Currency Information" in the AdminCP they also disappear. I only have 1 currency, which is the default currency from upgrading from the old vB3 mod. Just so I can add as much detail as possible, the transaction page at credits.php also doesn't display correctly, transactions are blank and it doesn't display any credits there either.

I customized 2 template edits to use custom hooks and templates to display credits in a custom dropdown, but I'm pretty sure it still had the problem before that, and it's still an issue since the other pages also mess up.

Postbit example with points gone:


Postbit example after Flushing Cache:


If it matters, I'm using xCache.

 

[Darkwaltz4]

This sounds like the start of a long and fun debugging time, especially since Deceptor isn't around to help with vboptimize.

Does this affect other addons, especially ones that use template hooks? Can you give a screenshot of the multiple currency integration page and credits.php transaction pages during the bug? Almost sounds like a datastore issue at that point, but can't imagine how it would have blanks vs flat out crashing, and those two don't have anything to do with template hooks.

 

[Munkii]

This sounds like the start of a long and fun debugging time, especially since Deceptor isn't around to help with vboptimize.

Does this affect other addons, especially ones that use template hooks? Can you give a screenshot of the multiple currency integration page and credits.php transaction pages during the bug? Almost sounds like a datastore issue at that point, but can't imagine how it would have blanks vs flat out crashing, and those two don't have anything to do with template hooks.

As I was typing a reply saying that I'd get them as soon as it happened again.. It started acting up again. This time I also noticed an error on the credits.php page.

Warning: Invalid argument supplied for foreach() in [path]/credits.php on line 188

And I made a mistake earlier, the currency shows in the Multiple Currency Integration page, but when I click Events, and also when I click Activity Amounts Configuration & Automatic Template Edits.. They redirect to the "Create New Currency" form..

Screenshot of dropdown before and after flush:


Screenshot of credits.php page before and after flush:





Screenshot of Multiple Currency Integration:


After flushing the cache, everything on the AdminCP side returns to normal.


Edit: And no, it only effects this modification.

 

[Darkwaltz4]

Yeah, this completely sounds like the datastore is losing the single entry for vbcredits, which contains pretty much everything needed to work

does it happen within a set period of time? To verify, can you try disabling vboptimize long enough to verify if it doesnt die after the usual interval? are you using a different method for datastore other than the database?

 

[Munkii]

Yeah, this completely sounds like the datastore is losing the single entry for vbcredits, which contains pretty much everything needed to work

does it happen within a set period of time? To verify, can you try disabling vboptimize long enough to verify if it doesnt die after the usual interval? are you using a different method for datastore other than the database?

I'll disable vB Optimise for now, and I haven't figured out exactly how long between working and not working, etc. I'm using xCache as the datastore type in vBulletins config.php, aswell as in the vB Optimise settings.

Edit: Actually, I'll just disable the datastore option for vB Optimise for now. If that fixes the error happening, then I'm okay with leaving that disabled. If it still happens though, I'll disable vB Optimise completely and get back to you on that. =)

 

[Darkwaltz4]

Well, I am using the datastore in a completely basic manner within the normal controls for access/saving. Is there a whitelist/expiration settings per datastore item? The entry is simply 'vbcredits'. Admittedly, I haven't used either of those for testing, but I heard once of it happening, but with something else.

 

[Fillip H.]

There's no cache whitelist, but I do know for a fact that such issues could occur if you're using vBulletin's vB_Datastore_XCache class in config.php. If so, try commenting it out.

 

[Darkwaltz4]

I am using build_datastore() and populating $specialtemplates, which is the absolute generic method vb is supposed to then choose where/how it gets/sets the data according to your settings.

 

[Fillip H.]

Yeah I'm saying that when using vBOptimise, using the config.php class is not recommended.

 

[Munkii]

I'm sorry for the delay in getting back to this thread, I've been dealing with some out of control server issues, so I wasn't able to monitor this properly to try and determine more information.

I do have an update though. It turns out, this error occurs regardless of having vBOptimise enabled or disabled. So I'm pretty sure I got it wrong for it being a vBOptimise conflict..

After disabling vBOptimise, the error still occurs. I use the xCache datastore option with my forum, in config.php, and when the error last occured.. I checked into the xCache administration page to look up the vbcredits var data entry, and this is what's displayed:



And this is what it is after clearing the cache (via xCache and not vBOptimise):



The reason I thought it had to do with vBOptimise, was because I was using the Flush Cache option to empty the cache.. What I didn't realize, was that flushed the entire var data cache, and not just what was being used by vBOptimise.

I'm really stumped on this, and I use xCache in place of my database to help performance, I can't disable that.

Thanks again for any help =)

 

[Darkwaltz4]

I've reopened and updated the description for us.

It is possible that this is a vBulletin error because vbulletin will actually silently rebuild your datastore if it finds it missing during a pageload, masking any xcache loss that might be happening.
Before we apply similar monitoring/fallbacks, have you noticed similar breakages in other addons you have installed? Can you try to monitor exactly when it breaks, reset it, then wait for it to break again?

perhaps Fillip H. knows more about xcache expiration settings than i do as well.

 

[Munkii]

I've reopened and updated the description for us.

It is possible that this is a vBulletin error because vbulletin will actually silently rebuild your datastore if it finds it missing during a pageload, masking any xcache loss that might be happening.
Before we apply similar monitoring/fallbacks, have you noticed similar breakages in other addons you have installed? Can you try to monitor exactly when it breaks, reset it, then wait for it to break again?

perhaps Fillip H. knows more about xcache expiration settings than i do as well.

I'll do my best to monitor it properly now, and I've asked a member of my staff to monitor it as well.

I haven't noticed anything else break randomly, and I've tried it with both default xCache expires, and customized extended expires. What I'd like to figure out while monitoring it, is if it's occuring only when the total time the var entry can "live" for expires. I feel that would help greatly in trying to pinpoint exactly what the cause is.

 

[Darkwaltz4]

Anything useful yet? Do you set expiration dates for each item in the datastore? The only one added new by vbcredits is simply 'vbcredits'.

As a last resort I will add in what vb does when it finds it is missing caches - silently rebuild them. I want to avoid it because you really shouldnt have to, it is not good for performance, and it would mask when the actual problem occurs.

 

[Munkii]

Anything useful yet? Do you set expiration dates for each item in the datastore? The only one added new by vbcredits is simply 'vbcredits'.

As a last resort I will add in what vb does when it finds it is missing caches - silently rebuild them. I want to avoid it because you really shouldnt have to, it is not good for performance, and it would mask when the actual problem occurs.

I lowered the overall expires in the xCache php.ini so I could get a better idea of if it's happening when it expires, but so far it hasn't acted up since doing that.

I didn't have any sort of individual expirations, just what was set in my php.ini

If you're familiar with xCache settings, these were my previous settings for the expiration times:

xcache.var_size = 20M
xcache.var_count = 2
xcache.var_slots = 8K
; default ttl
xcache.var_ttl = 7200
xcache.var_maxttl = 10800
xcache.var_gc_interval = 300

I have a datastore prefix for my forum in config.php, so vbcredits winds up being yh1vbcredits, but I don't think that would cause a problem with this.

I'm really not sure about what's triggering it, and at this point, seeing as how nobody else has had this specific issue.. I'm more interested in a temporary fix without having to disable the datastore option in config.php.

 

[Darkwaltz4]

Well, I would say that only a very small percentage of vbulletin owners attempt to use xcache with it, and id hate for this to be a problem with all of them (and I think someone else had a similar experience).

If you say that lowering the expiration time has resulted in it continuing to work, then i would say that is your temporary fix (as long as performance doesnt seem to be negated). does that sound accurate?

 

[Munkii]

Well, I would say that only a very small percentage of vbulletin owners attempt to use xcache with it, and id hate for this to be a problem with all of them (and I think someone else had a similar experience).

On vBulletin.com when requesting Server Configuration help, the opcode cache that's preferred by their team is actually xCache.

If you say that lowering the expiration time has resulted in it continuing to work, then i would say that is your temporary fix (as long as performance doesnt seem to be negated). does that sound accurate?

It still happens, but I'm pretty sure it fixes itself faster since the total cached time is maxed at 30 minutes, instead of previously being 3 hours. I don't have anything to back that up though.

 

[Darkwaltz4]

Oh okay, I was going by what you said "so far it hasn't acted up since doing that."

and I meant I'm sure the majority of vbulletin owners arent trying to install any opcode caching with it

try this out... edit (forum)/dbtech/credits/credits_core.php find:

if (is_array($vbulletin->vbcredits['display']))

add above

if (empty($vbulletin->vbcredits)) vbcredits_cache();

then find

if (defined('VB_AREA') AND VB_AREA == 'AdminCP')

add two slashes to the front like

//if (defined('VB_AREA') AND VB_AREA == 'AdminCP')

finally, find

build_datastore('vbcredits', serialize($cache), true);

add beneath

$vbulletin->vbcredits = $cache;

again an ugly bandaid - but see if that fixes it for you.

 

[Munkii]

I applied the fix and cleared all caches, I'll let you know if it happens again =)

I have a question about vBCredits II, and I've searched the forums here and on vB.org and haven't come up with a detailed answer.. Should I ask here, PM, or?

Thanks!

 

[Darkwaltz4]

Probably best to start a question thread in this forum if its unrelated to this bug report

 

[Munkii]

Just thought I should stop by and say I haven't had the problem since applying the above fix!

I'm not sure if that will help in fixing the issue in a future version, but atleast it'll help those that have the problem so they can use this mod without losing any performance improvements.

Thanks again.