This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
whenever i make a post all i see see is "saving.." and i never get confirmation if the post has been made, I don't get redirected to the post I made and I don't get a "sit tight we;re taking you..." message like I used to get with the old JR.
I too am having many problems posting on the JavaRanch. I would say that 1 in 4 posts will not succeed and will not be recoverable. I don't like to retype posts so this makes me abandon the thread where someone could have been helped. Also, about 1 out of 20 posts crashes my browser entirely. I am running Win XP, IE 7 or FF 3, and 1G ram.
Glad to hear you can confirm the improved behavior.
I'm happy to share the details, as it's the kind of thing that could happen to anybody. What I found was that JForum was using a standard thread pool to handle the work of sending email notification messages (the ones you get if you're watching a thread.) The default behavior of this standard thread pool was to run a request on the calling thread if the thread pool was "full", so the request wouldn't be lost. The long delay after a reply was occurring when there was a large volume of email, the mail server was backed up, the pool was full of threads waiting to connect to the mail server, and a request was being forced to handle email notification synchronously. The lost posts were caused by a database connection timeout due to that long delay.
Brian Legg wrote:So what was the fix? Making the mail server request asynchronous?
Using the default thread pool configuration meant losing posts under high system load, but ensuring mail would be delivered. I changed the pool strategy and increased the size of the pool, so that we'll never lose posts, but under even more extreme load (5x as bad) we'll start to drop notification emails. I think that's a good trade for now. We're going to look at a more sophisticated queuing solution that could store the failed messages and resend them at a later time.