1 Reply Latest reply on Apr 14, 2003 12:50 PM by adrian.brock

    jboss standalone using JMX

    sugramoin

      Case: Single Table data base generation.
      Data source in this application is a stream buffer which consists of comma seperated lines.
      I want each of that line to be stored in the database. Line has 5 fields. so created CMP with five fileds.
      i don't want to use a seperate client and make lookups and stuff. I want my JBOSS server to take the input which is a string buffer, and populate the database.
      to be more specific i was even planning to make a JMX service for taking my streambuffer and populating the database using an entity bean.

      I want some feedback on this approach and comments.
      if am out of sence, suggest me the best Go
      TIA
      Moin.

        • 1. Re: JMX Connectors vs. JBoss Invokers

          My arguments are purely technical,
          we know JMX will work but...

          Decoupling is an aspect
          For a service, it makes sense to wrap the POJO
          (Plain Old Java Object) in an {X}MBean to decouple the
          client from the service.

          Decoupling has overhead
          Every access goes through the MBeanServer with a
          lookup into the registry to find the mbean
          using the ObjectName.

          In general we are talking about a POJO which we want to
          make "remote". Do we wrap it in an XMBean, give it an
          ObjectName and register that with the MBeanServer?
          What if there are 1000 of these POJOs
          each representing a jmx notification listener,
          subscription to a jms topic or a client side cache
          invalidator?

          To avoid the 1000 mbeans, do we use an AOP remoting
          service MBean instead?
          That would have three indirections:

          Invoker -- Registry --> AOP remoting ObjectName
          MBeanServer -- MBeanRegistry --> AOP remoting MBean
          MBean -- object id --> AOP wrapped POJO

          What about optimizing local access? It now goes through
          the extra layer of the MBeanServer, only because the
          invokers must talk JMX.
          Remember I don't need the additional decoupling,
          just the ability to hand the invocation over to the
          correct flow/POJO.

          Why not the more direct
          Invoker -- Registry (object id) --> handler --> POJO

          if my config includes the decoupling
          handler -- MBeanServer (objectname) --> MBean/POJO

          That way we don't pay for what we don't use/need.

          Ideally, the payload marshalling and registry access
          should be optimized away locally, but I don't understand
          the implication this has for the current interceptors
          that assume the transaction/principal/etc are in the
          invocation.

          I started this by talking about clients generating
          a remote proxy allowing the server to asynchronously
          respond.
          What if the client is running in a sandbox (e.g. an applet)?
          We might not have the correct priviledges to create
          an MBeanServer or register in an MBeanServer that is
          already present.
          There are other problems with sandboxes.

          And finally, in remote mode, the invoker/handler has to
          know the correct classloader before it tries to unmarshall
          the payload.
          RMI does a bad job at this, assuming the classloader is
          where it loaded the stub, rather than the TCL of
          the application that exported the object.
          It looks like jmx1.2 is making a similar mistake with
          MBeanServer.getClassLoaderFor(ObjectName)

          Regards,
          Adrian