Viewing posts after failed captcha post

[Migrated From Jforum.net]

Ok, this was a hard one to find Rafael.

Try this...

First make sure that post caching is on and captcha for posting is on.

Second, act as if you are making a post to any topic, but don't put in the numbers/letters for captcha and let it fail. Then, without having made a successful post, go back into the topics of any forum and click on one to view the posts.

You should recieve an error from PostAction at this line:

List helperList = PostCommon.topicPosts(pm, um, usersMap, canEdit, us.getUserId(), topic.getId(), start, count);

Brakker

[originally posted on jforum.net by coolbreeze]

[Migrated From Jforum.net]

Well, I wasn't able to reproduce this bug. I made a little video:

http://www.jforum.net/tmp/jforum_post_cache_test.wmv

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Thanks for checking into it...I will look further into it later when I have a chance....right now I have to worry about my machine running out of resources. I have a dual xeon with 4 gig that is tapped. I need to buy 3 new servers and start doing some fun load balancing. I also need to upgrade jboss as I am stil back on version 2.x believe it or not. There could also be a memory leak in my version of jboss, although it's not that bad.

See, now you know yur not the only one going crazy over there!

Brakker
[originally posted on jforum.net by coolbreeze]

[Migrated From Jforum.net]

Ok.

I'll take a closer look also.

Thanks

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

So, they are different lists. One is for the action itself, and others are for the dynamic javascripts. pingSession is necessary to avoid session timeout. However, I guess than moving it to a simple jsp file will do the job.

One thing I realized now is that I'm getting a connection in the controller, always, which means that even for actions that does not require a database connection, one will be get.

I obviously should not do that - in fact, I have a project running jforum with this patch, so I'm going to apply it to the cvs head as well. This should improve performance.

I'll do it ASAP.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Stupid me...I figured out the problem with my processor utilization maxed out.

Ok, here's the deal....I have the forums integrated into a site that already has a login. So, basically I have a routine that logs people people in by passing (behind the scenes), their login details. Ok, so on my site I select the latest topics and post them on a very trafficed page which means that people click on the topcs and are redirected to the forum page of that topic while being automatically logged in each time. When I say they are automatically logged in, I don't mean using your auto login feature. I cannot use that feature because people use multiple accounts on my site using the same computer which would cause problems using cookies to log them in. Ok, anyway the problem is the login. How can I bypass all of the login authentication routine when they already have a session active? It seems that my processor spikes big time everytime a user clicks on a topic and is automatically logged in to the forums....and they are clicking the topics a lot!

Brakker
[originally posted on jforum.net by coolbreeze]

[Migrated From Jforum.net]

Yeah, I think that is a good point to reduce the db connections gotten when not needed. I also think it would be a good idea to reduce the overhead, like you stated, for the dynamic javascript. Although it is cool to do it that way, peformance could really get a boost from eliminating these calls. I guess this is a place to start.

Another area that I thought of is reducing any overhead that you can think of for getting cache. Just like in that scenerio when you said yur getting a db connection even for the dynamic javascript, maybe there are places where the code is trying to get cache stuff when it doesn't need to? Just an idea.

Brakker
[originally posted on jforum.net by coolbreeze]

[Migrated From Jforum.net]

By not using my "auto login", you mean the deafult one? because you can make an implementation of net.jforum.sso.SSO that checks the session. RemoveUserSSO just checks if a call to request.getRemoteUser() does not return null, so probably you can use the same approach to check the user session.

About the performance thing, you think it's only related to the auto login functionality or that the sql queries / overall jforum code needs a good improvement?

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Honestly, I don't know at this point whether the queries need revision. I am sure they could always use revision as can mine, although, I can only focus on the problem at hand right now. Once I get past this login issue, I will be able to focus on other parts.

When I said 'auto login', I simply was referring to the fact that I was logging people in behind the scenes everytime they clicked on a topic from my site to go into the forums. I am not using your auto login procedure because I was under the assumption that it wouldn't work because it is cookie based. I guess the only way that would work is if I removed your cookie once people log into my site and then have the forums recreate it when they are logged into the forums for the first time. Then, every time they attempt to view a toppic on my site, they will be auto logged in using your procedures?? Nevermind that idea...I don't like it.

One thing I noticed is that the new code brought my processor to a halt using the same technique (although I did change the cache engine to jboss), whereas the old 2.1.4 code that I originally downloaded was much more efficient. This could be due to a difference in the default login authentication procedure or it could mean a different part of the code is less efficient. What I did notice is that the processor power was being taken by the code and not so much the database. I have to speculate that the majority of the processor issues are coming from my logging in everyone each time they view a new post.

Brakker
[originally posted on jforum.net by coolbreeze]

[Migrated From Jforum.net]

So, you can disable the cookie autologin feature. Take a look here:

http://www.jforum.net/confluence/display/sso/Home

Also, you can set the key auto.login.enabled to false, so jforum will not try to use cookies.

About the poor performance you mentioned, this is very very serious :\

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Well, I changed the login code and it works better, but there are still major performance hits on the cpu. I'm not sure exactly what part is causing it as of yet. I will watch the processor and see java.exe range from 5-70% cup utilization. Maybe what I will do is log each forum action to the console and turn off all other logging. This may help in finding out which action or actions are causing it.

I have to guess and say that the initial login is still killing things some.

Brakker
[originally posted on jforum.net by coolbreeze]

[Migrated From Jforum.net]

Can you think of any major changes from the old code 2.1.4 to the new code? It seems like there is a major difference in cpu spikes between the two versions. The database seems to be relatively small in terms of cpu consumption.

Brakker
[originally posted on jforum.net by coolbreeze]

[Migrated From Jforum.net]

I can't say right now. I'll run a diff tool and see if I can realize anything like that.

Rafael.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Maybe we can clean up the actions somehow. It seems like there are 5 dynamic actions being created for each viewing of posts:

list
list
list
list
pingSession

For the viewing of topics we get

show
list
pingSession

First off, maybe we can eliminate pinging the session. This is just a guess as I really don't know what is being done in that routine.

Secondly, maybe we can kill the bottleneck for viewing posts by either reducing the number of "list" actions or caching the object so they don't need to be reinstiated. My question is why are there 4 calls to "list"?

Brakker





[originally posted on jforum.net by coolbreeze]

[Migrated From Jforum.net]

Ok, I sent the changes to the CVS.

Here's what I did:

:arrow: Left dynamic javascripts, and back to the old style (include it in the page using freemarker expressions). Also, I moved non-dynamic js to flat .js files.

:arrow: A database connection is only get if necessary, and only *when* necessary.

:arrow: Added permission caching. Until this modification, jforum would process security roles for all users. Now some caching, per group, is being done.

:arrow: Changed pingSession to use a flat JSP file (templates/ping_session.jsp), instead of an action.

Hope this helps. You can get all from the CVS HEAD.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Great, I really hope this helps!

Thanks for you speedy changes.

Also, I found another bug that I am going to post by itself.
[originally posted on jforum.net by coolbreeze]

[Migrated From Jforum.net]

The bug I was experience as the topic of this thread is not longer an issue. The new cvs changes seemed to have fixed it.


[originally posted on jforum.net by coolbreeze]

[Migrated From Jforum.net]

Great

Rafael
[originally posted on jforum.net by Rafael Steil]