1 2 Previous Next 28 Replies Latest reply on May 30, 2006 12:36 PM by weston.price

    PreFilled Pool Implementation

    weston.price

      Disscussing the following JIRA issue:

      http://jira.jboss.org/jira/browse/JBAS-1466

      Adrian identified two possible solutions for an implementation:

      1) Modifying the actual implementation to allow for this new behavior.
      2) Developing an custom MBean to 'kick start' the pool into gear prior to deployment.

      I am not married to either approach, however it would seem that the 'easiest' implementation would be the custom MBean. The only pitfall I can see here when a client attempts to set up a PoolFiller for a pool wherein the criteria doesn't allow it. However, the custom MBean seems to be the less intrusive approach and even if we went the first route, it would never truly prevent the client from doing this anyway. The nice thing about the MBean approach really is not having to touch the *-ds.xml file at all, just let the Filler service do the dirty work via dependecies.

      Also, we could suggest a temporary workaround on the Wiki, something to the effect of a custom Servlet that does the same thing the MBean does...(basically just grabs a connection and closes it).

      Thoughts?



        • 1. Re: PreFilled Pool Implementation

          The MBean is a workaround.

          Only the pool knows internally whether prefilling makes sense.

          • 2. Re: PreFilled Pool Implementation
            weston.price

            Correct. We could propose the 'workaround' on the Wiki, even attaching an implementation in anticipation of the real solution.

            • 3. Re: PreFilled Pool Implementation
              weston.price

              Ok, I implemented the MBean approach and tested against 4.0.4.GA (Postgres as backend). I guess the only question I have is should we distribute this as a standalone service on the Wiki, check it in to the current GA branch, or wait until the next 4.x release.

              I am inclined to use the Wiki at this point, not wanting to disrupt anything. W e can always roll it in a later 4.x release.

              Of courrse, as we talked about, this is a simple workaround until the prefill can be implemented on the pool itself. I was going to look at doing this next.

              • 4. Re: PreFilled Pool Implementation
                anil.saldhana

                You can always create a testcase in the 4.x testsuite that validates that inclusion in 4.0.4.GA will not break anything.

                If that happens, then I do not think there is any issue in including in GA. Right?

                • 5. Re: PreFilled Pool Implementation

                  The decision should be based on whether you are willing to support it
                  from now to eternity (assuming the proper solution will be implemented later)

                  1) If you don't want to support it, put it on the WIKI as an example.
                  2) If you do want to support it, put it in cvs and add doco on how to use it

                  • 6. Re: PreFilled Pool Implementation
                    weston.price

                    Well Anil, thank you for that slick and generally malicous response :-). The idea basically being that 'if you are not an idiot...all should be well'.

                    I am willing to support it until I can deprecate it when the real prefill implementation is ready to roll. Eternity...judging by your response I will be lucky to last until the end of the week :-).

                    I was merely asking because there is no information on the Wiki regarding any sort of code freeze, halting dev procedures close to a release. A mere question of procedure gentlemen.

                    • 7. Re: PreFilled Pool Implementation

                      The rules are simple. ;-)

                      Supported(able) code remains in the codebase.
                      I am not a big fan of people that dump features in the codebase
                      and then don't support it.

                      On deprecation, I am also not a big fan of lots of cruft for
                      "backwards compatibility" reasons. But I am even less of fan
                      of breaking working user configurations.

                      I don't mind breaking user configurations when the underlying feature
                      doesn't work in the first place. :-)

                      I prefer it when the user facing part doesn't change.
                      e.g. You could add your mbean to the xslt when they use

                      <prefill/>


                      That way they won't even notice when the better solution comes along.

                      • 8. Re: PreFilled Pool Implementation
                        weston.price

                        Bingo! Thanks boss.

                        • 9. Re: PreFilled Pool Implementation
                          weston.price

                          I modified the standalone service to use the XSLT mechanism whereby the element in *-ds.xml kicks in the prefill behavior. A new template just generates the PoolFillerService MBean for now, this code is the same as before.

                          • 10. Re: PreFilled Pool Implementation
                            weston.price

                            And I will say that it was a very elegant suggestion...it would seem to make deployment, management, migration much easier.

                            • 11. Re: PreFilled Pool Implementation
                              weston.price

                              This is pretty much complete, and actually was implmented the 'right' way (ie no hack to use MBean to get DataSource etc, etc). However, a few things remain:

                              The XLST has been updated to include a element that gets set on the JBossManagedConnectionPool. However, as explained before, only certain SubPools can support the prefill mechanism. What will most likely happen is people will put the element in the *-ds.xml file, expect the pool to be filled and be surprised when it doesn't happen.

                              Best solution is to probably implement the prefill method on the other pools and print a warning saying, pool does not support etc, etc. Or, we can check the Criteria in the XSLT and force the attribute to false if things don't match.

                              Again, a bit of cleanup in order but I plan on closing this one down first thing in the morning.


                              • 12. Re: PreFilled Pool Implementation

                                The WARNing is the best option. No silent failures!

                                • 13. Re: PreFilled Pool Implementation
                                  weston.price

                                  I got greedy on this one and jumped ahead of myself. The primary issue is supporting the BySubject pool. Since ConfiguredLoginModule is the only type in which this is supported the tests in jca were failing that were using a DynamicLoginConfig (naturally). Prior to prefilling the pools, there is really no way, that I can determine, to test for the type of login module that would support this feature. I see two options:

                                  1) Still allow for prefilling on Subject based pools, just document that it is only supported for a particular login module type.

                                  2) Remove prefilling for Subject based pools and only allow prefilling on OnePool.

                                  • 14. Re: PreFilled Pool Implementation
                                    weston.price

                                    Answered my own question. I will document the login config modules that allow for this feature. All issues have been fixed and updated.

                                    1 2 Previous Next