1 2 Previous Next 24 Replies Latest reply on Nov 16, 2012 6:30 AM by mr.bee

    Management of IronJacamar

    jesper.pedersen

      I have started an article here

       

      http://community.jboss.org/wiki/IronJacamarManagement

       

      about management of IronJacamar.

       

      Feedback on what people would like to see is more than welcome.

        • 1. Management of IronJacamar
          jesper.pedersen

          So the first thing that is up for discussion is basically if properties that are read during container start should be writable from the management layer.

           

          I think that would be ok, as values are persisted in f.ex. the domain model of JBoss Application Server 7. That way we will leave to the client of the management API to expose these properties or not.

          • 2. Management of IronJacamar
            jesper.pedersen

            Another thing to consider is if we should support batch updates - e.g. multiple value changes applied in one go.

            • 3. Management of IronJacamar
              jesper.pedersen

              Statistics is an important part of management IMHO.

               

              We can divide statistics into two overall groups

               

              1. Container
              2. Resource adapter

               

              where "Container" is statistics which aims at the core container. "Resource adapter" is statistics that is specific to a resource adapter.

               

              While the "Container" part is important it is crucial to give vendors a way to expose statistics through IronJacamar. We have an example of this ourself - namely the JDBC resource adapter, so that can serve as a Proof-of-Concept.

               

              Using modern datastructures to collect information doesn't impose a big overhead, so for now we will just hook statistics directly into the call stack.

               

              A couple of points:

               

              • A statistics plugin must provide a generic interface
              • A statistics plugin must provide a way to enable / disable collection of information
              • A statistics plugin must provide a way to clear collected information
              • A statistics plugin must collect information in milliseconds
              • A statistics plugin must use atomic datastructures as much as possible

               

              While resource adapters will have to expose the statistics plugin to IronJacamar - we can do a solution for JDBC that is hidden inside the datasource deployer chain.

               

              I'll code up a prototype of the above.

              • 4. Management of IronJacamar
                jesper.pedersen

                Another thought: Many resource adapters will use JMX directly, so we should have a generic JMX statistics bridge that we can plug in (if possible).

                • 5. Management of IronJacamar
                  jesper.pedersen

                  The code has been committed under JBJCA-542.

                  • 6. Management of IronJacamar
                    jesper.pedersen

                    Andy Miller:

                     

                    In looking over this I don't see any real holes, but I do have a couple of questions.  How does the CachedConnectionManager play into the JCA container now?  Is it still a hard dependency?  If its still there, it would be really great to be able to remove it completely from the configuration.

                     

                    I like the fact that you will be able to turn on and off the statistics, as we will be able to directly measure the difference, and it probably helps with the benchmarking activities.  The one statistic that seems to be missing is the max connection count in use, which is probably also the worst from a performance perspective.  Was that intentional?  It seems like you could just use the created count for that, if it was greater than the min and less than the max anyway.

                    • 7. Re: Management of IronJacamar
                      jesper.pedersen

                      How does the CachedConnectionManager play into the JCA container now?  Is it still a hard dependency?  If its still there, it would be really great to be able to remove it completely from the configuration.

                       

                      CCM is still there, since it implements one of the SPIs. If it'll be used is another matter - I think EJB is the only user of the SPI in question. Discussing for another thread.

                       

                      I like the fact that you will be able to turn on and off the statistics, as we will be able to directly measure the difference, and it probably helps with the benchmarking activities.

                       

                      The overhead of statistics is minimal. However I considered that there will be use-cases where you don't want to record the results. The key method is clear(), which will allow you to reset all counters.

                       

                      The one statistic that seems to be missing is the max connection count in use, which is probably also the worst from a performance perspective.  Was that intentional?  It seems like you could just use the created count for that, if it was greater than the min and less than the max anyway.

                       

                      https://issues.jboss.org/browse/JBJCA-545

                      • 8. Management of IronJacamar
                        andy.miller

                        Jesper Pedersen wrote:

                         

                        How does the CachedConnectionManager play into the JCA container now?  Is it still a hard dependency?  If its still there, it would be really great to be able to remove it completely from the configuration.

                         

                        CCM is still there, since it implements one of the SPIs. If it'll be used is another matter - I think EJB is the only user of the SPI in question. Discussing for another thread.

                         

                        I like the fact that you will be able to turn on and off the statistics, as we will be able to directly measure the difference, and it probably helps with the benchmarking activities.

                         

                        The overhead of statistics is minimal. However I considered that there will be use-cases where you don't want to record the results. The key method is clear(), which will allow you to reset all counters.

                         

                        The one statistic that seems to be missing is the max connection count in use, which is probably also the worst from a performance perspective.  Was that intentional?  It seems like you could just use the created count for that, if it was greater than the min and less than the max anyway.

                         

                        https://issues.jboss.org/browse/JBJCA-545

                        Did you want to start another thread on the CCM here?

                        • 9. Management of IronJacamar
                          jesper.pedersen
                          Did you want to start another thread on the CCM here?

                           

                          I think it belongs in the EJB3 development forum for now, as they need CCM for lazy enlistment.

                          • 10. Management of IronJacamar
                            andy.miller

                            Jesper Pedersen wrote:

                             

                            Did you want to start another thread on the CCM here?

                             

                            I think it belongs in the EJB3 development forum for now, as they need CCM for lazy enlistment.

                            Yes, but in AS 5.x/EAP 5.x there is a hard dependency in the jca-jboss-beans.xml, so it cannot be removed from JCA, which is why I asked.  I actually can remove it from the interceptors stack on EJB 3, via the ejb-interceptors-aop.xml, but if you remove it from the jca-jboss-beans.xml the server won't start.  I want to make sure that its not a hard dependency anymore.

                             

                            The reason I don't think it should be a hard dependency, is that the EE specification requirement that it implements is both an edge case, and an anti-pattern.

                             

                            Probably 99% of applications can be run without it, and those that cannot, can actually be changed very easily to not need that requirement anymore.  I even outlined how you can change your application to not require the CCM in the performance tuning guide for EAP 5.

                            • 11. Management of IronJacamar
                              jesper.pedersen

                              There is no hard requirement inside JCA on the CCM now to my knowledge - if there is its a bug. Anyway, this is a discussing for another thread, as this doesn't have anything to do with management.

                              • 12. Management of IronJacamar
                                andy.miller

                                Jesper Pedersen wrote:

                                 

                                There is no hard requirement inside JCA on the CCM now to my knowledge - if there is its a bug. Anyway, this is a discussing for another thread, as this doesn't have anything to do with management.

                                Okay, great.

                                • 13. Re: Management of IronJacamar
                                  mr.bee

                                  Hi Jesper,

                                   

                                  I was looking a way to get the list of deployed resource adapters and it's requried config properties but unable to do so.

                                  Server is Jboss AS 7.1.1.Final

                                  Can you provide me some sample or help, that how can i acheive this ?

                                   

                                  thanks,

                                  Nabeel Ahmed

                                  • 14. Re: Management of IronJacamar
                                    jesper.pedersen

                                    You need to use the DMR API - see the AS7 user forum and AS7 documentation for examples.

                                    1 2 Previous Next