Merged Last post date "42 years ago" - access denied to topic - database errors

I'm reporting this problem with the smallest frequency, and off hand, I see a big difference in the max execution time. Could a process be being cut off by the server settings and preventing the data gathering?

You try to increase it to see if it's changing something

Well, since I'm the least affected, that isn't going to show much, but if the others increase to my level, they might see a noticeable improvement which shows something is processing too slowly.

We've been kicking this topic around a lot in our discussions behind-the-scenes and, while we don't have a satisfactory explanation for what's causing the problem in the first place, these are our suspicions:

(1) In this case, the cause of "access denied" to the topic is, unquestionably, the result of bad data. Key data is missing at the time when the record(s) is/are updated to the _kunena_messages and _kunena_message_text tables. It would be preferable if Kunena reacted to bad data in a more elegant manner than simply throwing in the towel and saying "access denied"/

(2) Last Post Date: 42 years ago is symptomatic of the same issue as (1) above. The timestamp on the record written to the _kunena_messages table is empty (NULL) and PHP formats this timestamp value as 1-Jan-1970. PHP dates are calculated as the number of milliseconds from this reference date (i.e. dates after 1-Jan-1970 are positive, dates before then are negative). The explanation for why this field contains a NULL value is, as I have written before, an error in the MySQL transaction that writes the record in the _kunena_messages table.

(3) We've seen this before at www.kunena.org - very rarely. Our suspicion is that this may occur if/when the SQL server goes "walkabout" (because the server is busy with some other processing occurring at the time) and what next happens is that users who are trying to post a message, in some "desperate" attempt to get a response, hit the SUMBIT button again. Pressing the submit button (or refreshing the page) may result in the server receiving another transaction in the queue before the first one has completed and, because the original transaction was incomplete (and a subsequent transaction may contain invalid data) this could result in the database getting itself tangled in a knot. One "possible" way to avoid this is to ask users to be more "patient" ... but we know that's not likely to be successful, don't we?

(4) The developers are investigating ways to minimise potential data corruption. Whether a solution can be developed in readiness for the release of K 2.0.3 remains to be seen - my guess is that it probably will not be done before K 2.0.3 is released - and so this issue may have to remain on the "watch list" for some time.

(5) The Kunena team is treating this matter seriously. The incidence of the condition is low. The steps to resolve resultant data corruption are relatively straightforward (until such time as the incidence on a particular site grows to the extent that the workload to manage each case becomes too great, of course).

(6) We don't know why, specifically, this issue seems to mainly affect posts that create new topics. We have no information, at this time, that this "empty data" thing affects replies but, again, that's something people may be able to contribute more to this topic if they have evidence that replying to a topic also results in the conditions we've been discussing here.

(7) It's possible that increasing the execution time may alleviate the symptoms (assuming, of course, that your webhost allows you the ability to do that). It is also possible that your server, no matter how well it's configured, may simply be underpowered to take the load. For example, we have been aware for some time that the server on which www.kunena.org is hosted, does not really have sufficient memory to accommodate the workload that is sometimes generated here. In spite of many efforts to tweak various configuration settings, the stark reality is that our problems will only be solved by investing money into upgrading the hardware (adding more physical memory) and that's not something we're particularly enthusiastic about doing for a product that does not generate any real income.

Those are just some initial thoughts I have concluded from our discussions. I hope they help.

I came to the same conclusions on numbers 1 and 2, as you might have guessed from my comments.

I'm puzzled by the assumption that the database is at fault, though this may be how the sessions are handled in the application to push data integrity onto the database.

From reports of the times it happened, I'd guess double clicking submit is not a factor, but that depends on how aware the users were of their own actions. Also the cases were always new posts. We have a very...vocal...community, so if there were issues with broken replies, I would have heard about it.

Underpowered servers are not the issue in my case as our host just upgraded them last year, but I'm glad to hear it's being treated seriously because your straightforward steps involve interacting directly with the database, not something every administrator of this sort of site has any experience with.

Probably unrelated, but I'll pass this on in case it's another side to the same issue, but we've had a higher instance report of quick replies not posting. This has happened to me directly, so I can give you the steps, but as it is also intermittent, it is not something I can consistently reproduce.

1) Click quick reply
2) Write your response (whether this takes a long or short while makes no difference so it's not a session expiring.
3) Click the "submit" button.
4) Instead of posting your reply, it redirects you to the "Recent topics" tab.
5) Click back, and your reply is still in the box.
6) Click "submit" and it saves correctly.

Just an update since I uninstalled, dropped all associated Kunena tables, and reinstalled.

The problem has not recurred. Not once. I went from 25% of the topics reporting that error, to none.

Which makes me wonder if it's perhaps the installation order or version that caused a conflict..

In my case, the installation order went like this:

Joomla (obviously)
Kunena
Community Builder (latest free version)

I've also upgraded to Community Builder Pro (there were enough add-ons I wanted to make it cost-effective) before I uninstalled, dropped tables, reinstalled Kunena.

I'm wondering if anyone else installed in a similar order or if they're running the free version of CB.

slayer99199 wrote: ... perhaps the installation order or version that caused a conflict ...

I don't think it matters to that extent but it may matter depending on the order that software is loaded. It's also possible that the installation of some Joomla extension - Kunena or something else - was not 100% successful (even if you received a message saying that the installation was successful). (Strange things that go "bump in the night" and all that.)

I'm glad that your problems have been sorted out and, maybe, this was an isolated incident that won't appear again. We will keep our fingers crossed for your continued good fortune. Thank you for your update.

No panic...
42 is the Answer to the Ultimate Question of Life, The Universe, and Everything .


(sorry, but I found the topic title and couldn't resist... :evil: )

The developers have informed me that they think they have a solution to this issue . The fix may make it into K 2.0.3.

sozzled wrote: The developers have informed me that they think they have a solution to this issue . The fix may make it into K 2.0.3.

This is great news! Thanks a lot.

Neil