5 Replies Latest reply on Oct 2, 2002 11:48 AM by Phill

    Deploying my socket listener as an MBean?

    Phill Newbie

      I'm new to JMX, and want to know if this is a valid use for it, or if y'all think this might not be a reasonable pattern for JMX/JBoss.

      I have an ejb application that uses message driven beans to get messages from the outside world. The messages get pushed through a socket on our box, where a server listens, and places recieved items on a JMS topic to be delivered to the processing beans.

      It seems like instrumenting the socket listener as an MBean would be usefull. I could track whether or not it's connected, attempt reconnects, detect traffic, etc.

      It would also be nice if I could set up my JBoss deployment to start the socketlistener by firing a method via JMX at deploy-time. Is there a way to do this?

      thanks in advance,
      Phill Tornroth

        • 1. Re: Deploying my socket listener as an MBean?
          Juha Lindfors Master

          yes this is a valid use for jmx

          • 2. Re: Deploying my socket listener as an MBean?
            Phill Newbie

            That's good to hear. I'm still confused as to what the correct pattern would be for managing this service though. I open a ServerSocket, and continually pull the data in, and post it to a topic.

            I'd like to be able to do things like, restart the service (tell it to close it's ServerSocket connection and reopen a new one), as well as monitor what port it's listening to, and how many messages it's processed, etc.

            Since there's a thread spinning inside a method of the object shuttling data back and forth, I'm a bit confused as to best-practice for automating it remotely. Should that loop be watching some variables that MBean methods might change to encourage the object to alter it's behavior?

            Please excuse me if this question is fairly amatuerish,
            -phill

            • 3. Re: Deploying my socket listener as an MBean?
              Phill Newbie

              That's good to hear. I'm still confused as to what the correct pattern would be for managing this service though. I open a ServerSocket, and continually pull the data in, and post it to a topic.

              I'd like to be able to do things like, restart the service (tell it to close it's ServerSocket connection and reopen a new one), as well as monitor what port it's listening to, and how many messages it's processed, etc.

              Since there's a thread spinning inside a method of the object shuttling data back and forth, I'm a bit confused as to best-practice for automating it remotely. Should that loop be watching some variables that MBean methods might change to encourage the object to alter it's behavior?

              Please excuse me if this question is fairly amatuerish,
              -phill

              • 4. Re: Deploying my socket listener as an MBean?
                Adrian Brock Master

                Yes, expose the management and monitoring as attributes.

                e.g.
                void setPort(int port);
                int getPort();
                int getMessagesProcessed();

                If you extend ServiceMBean{Support} you will get
                create/start/stop/destroy operations for the lifecyle.
                Your startService() routine would create the thread
                and stopService() would interrupt() the thread
                telling it to exit the loop.

                If you are processing lots of messages, you might
                want to think about a Thread Pool.
                I believe JBoss HEAD (4.0) has an implementation
                of the JCA 1.5 work contract you might want to look at.

                Regards,
                Adrian

                • 5. Re: Deploying my socket listener as an MBean?
                  Phill Newbie

                  Thanks!
                  (and sorry for the double post)

                  In this case, the messages must be processed synchronously, so no thread pool for me... But I'll remember that in case the requirement changes.

                  -phill