6 Replies Latest reply on Mar 1, 2007 7:37 AM by dmarchant

    Hot reployment

    marklittle

      As you can see here http://jira.jboss.com/jira/browse/JBESB-431 we're looking at hot redeployment capabilities for the ESB in the 4.2/5.0 timeframe.

        • 1. Re: Hot reployment
          kukeltje

          Added to the jira:

          Not only hot, but
          - Scheduled: e.g. 'deploy now' become active at 23:00 (or 11pm ;-) ), or mark a service as becomming unavailable a 3 weeks from now
          - Versioned: Service A version 1 uses Service B version 2, Service B gets a new version, needed for other things, but Service A should still be able to use Service B version 2 for as long as needed.

          If I think of more examples/requirements, I'll add them here.

          • 2. Re: Hot reployment

            My suggestion is to tie this in with an OSGI approach.
            The OSGI can define the versioning dependencies and will allow for loading and unloading through a variety of options.



            Is the scheduling essentially a grid capability?
            During the day the BUS is supporting XYZ services and during the night it is supporting ABC services. Is this the intent?

            • 3. Re: Hot reployment
              marklittle

              I don't know what Ronald had in mind for scheduling, but I've come across those requirements quite a bit over the years in non-Grid environments. For example, improving fault tolerance or load balancing at certain times of day; moving a service from A to B because of changes in work practices, again at certain times of day; giving advanced warning that a service is going away so applications can gracefully re-bind to alternatives.

              • 4. Re: Hot reployment
                marklittle

                We are looking at OSGi. Whether it is tied to OSGi is another matter though: we don't want to preclude using non-OSGi containers.

                • 5. Re: Hot reployment
                  kukeltje

                  Scheduling:

                  Most of our tech guys work during the day. During the evening there are 'just' people monitoring the system. It is fairly expensive (overtime and organizing it) to have people work during the evening for just a deployment. So if the deployment could be done during the day and tested in one way or another, but is only initially activated during the night (or even days or weeks later) that would reduce deployment costs alot.

                  • 6. Re: Hot reployment

                    Ah I see where you are going.
                    This is more or less a staging concept that a lot of IT shops use.
                    They take a machine out of rotation and "stage" a version.
                    When the version is "OK" they push to production at night.

                    Things happen at night because less reports work at night, in case of outages :)