Uploaded image for project: 'Openfire (ARCHIVED)'
  1. Openfire (ARCHIVED)
  2. JM-343

Improve connection pool recovery logic

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.0 Beta 2
    • Fix Version/s: 3.4.5
    • Component/s: Core, Database
    • Labels:
      None

      Description

      Improve the connection pool recovery logic if possible. More info at:

      http://www.jivesoftware.org/forums/thread.jspa?threadID=15165

        Attachments

          Activity

          Hide
          jadestorm Daniel Henninger added a comment -

          Hi Matt! I actually already am including the web servlet! Though now that you mention it, I might need to make a config tweak to trigger the graphing to actually occur. Good test suggestion!

          Show
          jadestorm Daniel Henninger added a comment - Hi Matt! I actually already am including the web servlet! Though now that you mention it, I might need to make a config tweak to trigger the graphing to actually occur. Good test suggestion!
          Hide
          matt Matt Tucker added a comment -

          Rather than include the web servlet, it seems like it would be much better to incorporate that same data into the existing database page.

          Show
          matt Matt Tucker added a comment - Rather than include the web servlet, it seems like it would be much better to incorporate that same data into the existing database page.
          Hide
          jadestorm Daniel Henninger added a comment -

          Hrm. Good point. I had planned on doing that "in the future" but might as well do it now instead of using the servlet. =)

          BTW I ran your test and wow. it didn't miss a beat! (I took down MySQL, almost immediately did it detect problems, things broke, etc, and then I started MySQL back up and it immediately was happy again) I also did a rude test -> i kill -9'd mysql out from under openfire and it didn't detect the mysql shutdown immediately in terms of .. immediately show that mysql died, but the first database request caught it. (and I imagine the every 30 second check would have seen it) Brought up MySQL, all is well again immediately.

          I'm quite pleased with it's behavior!

          I'll look into improving the servlet.

          BTW, looks like the ClearSpace folk aren't particularly interested for now, sounds like they solved their problems with their stuff. Bruce did tell me that JNDI has some sort of it's own connection pooling, but I'm not sure it has the powerful connection testing that this has. (proxool is testing the connection before and after it's used to see if it's still a valid connection, it seems to be very robust in that sense ... the caveat of course is that' it's doing extra "SELECT 1" commands, but I explicitly picked something super quick like that so it shouldn't be a noticable performance hit.

          Speaking of which, at some point I'd like to investigate where we could use some indexes and such to improve our database interactions altogether. Guus found at least one instance where we were missing a possible important index that sped things up quite a bit.

          Show
          jadestorm Daniel Henninger added a comment - Hrm. Good point. I had planned on doing that "in the future" but might as well do it now instead of using the servlet. =) BTW I ran your test and wow. it didn't miss a beat! (I took down MySQL, almost immediately did it detect problems, things broke, etc, and then I started MySQL back up and it immediately was happy again) I also did a rude test -> i kill -9'd mysql out from under openfire and it didn't detect the mysql shutdown immediately in terms of .. immediately show that mysql died, but the first database request caught it. (and I imagine the every 30 second check would have seen it) Brought up MySQL, all is well again immediately. I'm quite pleased with it's behavior! I'll look into improving the servlet. BTW, looks like the ClearSpace folk aren't particularly interested for now, sounds like they solved their problems with their stuff. Bruce did tell me that JNDI has some sort of it's own connection pooling, but I'm not sure it has the powerful connection testing that this has. (proxool is testing the connection before and after it's used to see if it's still a valid connection, it seems to be very robust in that sense ... the caveat of course is that' it's doing extra "SELECT 1" commands, but I explicitly picked something super quick like that so it shouldn't be a noticable performance hit. Speaking of which, at some point I'd like to investigate where we could use some indexes and such to improve our database interactions altogether. Guus found at least one instance where we were missing a possible important index that sped things up quite a bit.
          Hide
          jmcmillan James Mc Millan added a comment -

          Hi Guys

          Just to let you know, we upgraded to 3.5.0rc1 from 3.3.2 and we had major issues with the Proxool connection pooling, and we had to give it an unreasonably high number of connections in order for it to work (most of the time). It seems to hold onto connections for longer than it should and not release them.

          The good news is switching to c3p0 (an easy implementation of ConnectionProvider) solved the problem for us. So, if anyone else has problems, switching to c3p0 is simple enough. At the moment though, we don't have statistics on the database page, which throws an exception as it is hardcoded to look for Proxool.

          Thanks
          James

          Show
          jmcmillan James Mc Millan added a comment - Hi Guys Just to let you know, we upgraded to 3.5.0rc1 from 3.3.2 and we had major issues with the Proxool connection pooling, and we had to give it an unreasonably high number of connections in order for it to work (most of the time). It seems to hold onto connections for longer than it should and not release them. The good news is switching to c3p0 (an easy implementation of ConnectionProvider) solved the problem for us. So, if anyone else has problems, switching to c3p0 is simple enough. At the moment though, we don't have statistics on the database page, which throws an exception as it is hardcoded to look for Proxool. Thanks James
          Hide
          jadestorm Daniel Henninger added a comment -

          There's an improvement coming to the current pool implemention in RC2.

          Show
          jadestorm Daniel Henninger added a comment - There's an improvement coming to the current pool implemention in RC2.

            People

            • Assignee:
              jadestorm Daniel Henninger
              Reporter:
              matt Matt Tucker
            • Votes:
              20 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: