UBB.Developers Forums General Discussion Chit Chat anyone still using w3t mod_perl

I've lost track of everything after the transition and was wondering if there were any folks still using w3t with perl / mod_perl. If so, is there a board somewhere where there are any discussions going on? Any URL's would be greatly appreciated.

If it is a general question, ya might as well ask it here. Many of the peeps here used older version and might be able to answer your questions. Don't as me, as I converted a few months back from UBB classic.

Appreciate the reply Aglavalin, I don't have any questions about it, I was just curious if anyone else is still using it or if I'm the only holdout. I really hadn't been around since the sellout and I don't recognize any of the names on the board anymore. Plus there were so many different community boards after the new guys took over, I don't even know where folks are hanging out, if they are at all.

I was also just looking around at some of the new features to see if there are any things I'd like to add to my copy of w3t now since it had been a while since I've looked at this. I really don't plan on switching, we've invested too much time and money to make our copy run on steroids basically and right now I'm real happy with it's performance. You know how it goes, if it ain't broke, don't fix it.

Anyways, if there are folks around still using it, let me know... I'm just curious.

I think Gardener still runs it.

I'm still using 5.4.4perl, but it's not running under mod_perl. Before I upgraded my server it didn't work well with mod_perl (too little memory probably) and there were some strange caching issues if I recall correctly.

But I'm about to move to 6.1 now, I've fixed all new translations and added all basic hacks and will probably go live in the next couple of days. After that I can start upgrading my 10 or so mods from 6.0.x to 6.1 and install them.

How much memory do you have and how big are your boards. We've been running under mod_perl I have to say for at least a year and a half and haven't had any problems at all. I haven't seen anything of caching problems. The only real problem we ever had was that of scalability, I remember when we got 50 users online at the same time, this thing would die, it was so pathetic. But we have long since taken care of that with a mysql/perl specialist who's got this bad boy so tricked out now performance-wise. We've hit 5x what used to kill us and it's not even breathing hard now.

The only minor problem I have is about once a month or so we end up with a few "phantom" posts where for some reason the B_Number field gets set on a new post but B_Main is set to 0, and not the B_Number. We haven't been able to figure out how it happens, especially since it's not that often, so we just keep an eye on it. Ever seen anything like that... I'd love to find that bug and get rid of it.

Good luck on the switch.

Well, the server used to have 384 MB memory and was a Pentium 2 233MHZ, not a speed demon really. =] We have about 3500 users and a couple of hundred posts a day. It's stopped rising for some time because the server couldn't take the load. Probably was mysql tuning issues as well. The weird caching issues could also have been a strange perl/mod_perl install as well, not really sure.

The phantom posts sounds like the problem we had when the mysql server was hogged down. I think the problem is that one of the last queries of addpost.php sets the B_Main and when there aren't enough open connections it can't run that last query. Or, the query dies while executing or something like that. It always happened when the server had huge load anyways, don't know exactly what caused it though.
Don't know why B_Main is set on its own at the end of the script either, but I hope there is a good reason for it even though I couldn't find it when I looked if I remember correctly.

Now, with an Athlon Thunderbird 1200 with 896 MB memory it seems to run very smoothly with ~40 users online. And we have a bunce of other sites running as well, where one is as big or bigger than ours.

There's a nice little upgrade for you. I feel your pain about the load and mysql issues. I went through that a long time ago where page load times were measured in minutes, not seconds. Definitely not fun. I hope the new code works out well for you.

Thanks for the info on the phantom posts, I'll have a look. I have noticed when we get our peaks of over 200 online it seems to happen a bit more, but when we hit those its like a post-fest, so I just figured it's gonna happen more anyways. And I'd usually get plenty of emails when they come up so I could fix them up quickly.

Do you know if anyone else is still running the w3t perl version?

Still running the 5.4 perl version and am not really in a hurry to upgrade at this point. Part of the problem is that we have hacked our board some and the person that knows the programing does not really know anything about php but does know perl.

We get reasonable activity, now that we are getting into our busy season. Get probably a couple of hundered posts a day and now are starting to run into the 70-80's online during some of the peak hours. In a couple of months we should be in the very low 100's online.

We do not run mod perl but have our own dedicated box.

[]Gardener said:Don't know why B_Main is set on its own at the end of the script either, but I hope there is a good reason for it even though I couldn't find it when I looked if I remember correctly.[/]

B_Main has the same value as B_Number when it's the first post in a new thread. Since B_number is autoincrement it can't be known until after the insert, so another query is done to find the number, and then another query is done to set B_Main to that value.

The bug doesn't bother threaded view, but flat chokes on it. I think you're right about the timeout so there's no way to fix it in addpost. The next chance to fix it occurs when someone views the post flat (usually the poster). Here's what we did:

Find this comment in showflat:

# ------------------------------------------
# Grab the main post number for this thread

Add B_Parent and B_Topic to that query and add the following code that checks for the bug and corrects it.


Works like a charm.

That's quite an old thread to bring back to life. =]

What I would do is just find all posts not connected to a thread with one query and update the B_Main for those. One easy query to fix all those problems if they've shown up.

It is an old thread but it still comes up in search results and I just thought to fill in the blanks for future generations...

The reason for adding the fix to showflat is to prevent duplicate posts. When a victim of this bug views their post flat just after posting it, the post is blank, and they inevitably repost it. Of course the admin can clean up later but who needs more work?