I just started my blog, using contentbox.
Its going ok so far, but apparently, there are some quirks.
When I post my blog article, I check the entries, make sure it looks good, and then I copy paste the link into twitter, and then usually go to sleep.
During the night, people click away on the links, and several people have posted they’re having an issue.
They click on Article A, the URL expands from twitters tiny url to the Full Article A url, and the content in the page is Article B.
Adam Cameron was of the people, so he helped me determine it was expanding correctly… and he said it was weird, for about 30 mins or so, and then after that, it was working correctly again.
Brad mentioned it might be a cache issue, but I’m usually asleep when it happens… so I cannot log in and check the cache.
Its happened a few times, with a few people and a few different articles.
Anyone else come across this, and anyone has any idea why?
I will add that someone reported this to me as happening on the ContentBox blog this week so I don’t think it’s an issue unique to Gavin. It might have been introduced in a recent update though since I know we’ve been using ContentBox for quite some time and this was the first I heard of it.
Just happened again right now, as one of my followers went to go check out my VOTE FOR CFOBJECTIVE entries and got my Git for Dummies one.
I uploaded the screenshot.
Brad told me to check the cache.
I did, and I saw the cb-content-entry-cfobjective-2014-make-your-vote-count-now entry, with 6 or 7 hits… and it looks like it should have been the right cache.
I clicked on it, to see what was cached, and it said UNKNOWN and then the cache was gone… so i guess i got it in the middle of it dumping it and getting a new one.
I reloaded the page on the front end, now it is working, go to the back end, and now i see the cb-content-entry-14 (the blog id) and its working fine.
So, why does the slug sometimes grab the wrong one and cache that… and then not at other times?
I saw it with my own eyes this time, screenshot proves it.
The weird thing is, it looks to grab the 2nd article, instead of the first… so not sure if that helps you guys debug it.
Btw I have been able to duplicate this, well not to the point that I know 100% what is causing it. But what I can guess at is there are cases where the key hash being created is identical to a key already created.
I am still looking into it, but rest assured I have now see it first hand.
I should also point out that I am able to reduplicate it every time now, the only catch is that I can’t duplicate it in development and can only duplicate it in production, with the cache using the diskstore.
I wasn’t able to reproduce but I updated the caching algorithms to match more closely ColdBox internal event caching. Cchanges committed and 1.6 is coming to the be channel this week for testing.
That was my thought too Brad and I went through the code and couldn’t see anything that might stick out.
The trick is that the first content that you browse, has to never been cached and as you hit it, hit it with another browser. Because for some reason ORM objects take around 600-900ms on production on my server, it is very easy to duplicate.
In fact if you want to setup a connect session, I can very easily demonstrate it.
There is only one, what I have seen is that the cached version for the content was there and is replaced with the new one. I was able to verify this by going to the cached content and having a look at its contents. Sure enough it has the wrong cached information.
That ticket looks to be targeted for our 1.6.0 release, but since it’s open and resolved it’s certainly not finished yet. There’s probably a good chance it will be pulled from this release but Luis can confirm.
