Loading ...
Sorry, an error occurred while loading the content.

Alternate ways to reload fusebox?

Expand Messages
  • dcmccan@rocketmail.com
    Fusebox has been a boon in speeding development and making maintenance an easy process. Thank you to everyone for their contributions and help. I am wondering
    Message 1 of 7 , Jul 9 8:13 AM
    • 0 Attachment
      Fusebox has been a boon in speeding development and making maintenance an easy process. Thank you to everyone for their contributions and help.

      I am wondering if people might suggest alternate ways to reload fusebox when there is a code update? The URL parameter method is a little tricky due to multiple load balanced servers.

      We have 2 web servers at a hosting site that are using Microsoft network load balancing with sticky sessions (which means that once someone hits a server they stay there for their session, but incoming new users are distributed more or less evenly). To the world the pair of servers has one IP address. This means that if I go to the site URL in the web browser and give the URL reload command, only one of the pair would get reloaded (whichever one I was sent to). So currently, to reload fusebox I need to have a VPN connection to the hosting site and have added special routes and host file entries, so I can be sure to individually hit each one to give the reload command on the URL. I am a little worried because if other people need to do an update when I am on vacation they likely won't have these special settings already in place.

      Is there a way that we could either:

      -- drop a file on the servers when doing an update and have the application check for it and if found, do a reload and delete the file?

      or

      -- set a task or timeout so that the application would get reloaded every hour or something. If this option, is there any danger of problems due to code/cache mismatches between the time the code is updated and the timeout/reload period?

      or

      -- set a value in the database telling each server to reload fusebox and have the application query for it and then clear the flag for that server?

      Other ideas?

      It seems like the timeout or scheduled task would be the easiest as it would require no special user action. The file would be the next easiest and the database the third.

      Thank you very much for your suggestions.

      David
    • Mike Ritchie
      Hi David, I ran into this problem on an application that was shared across multiple websites on the server, when I wanted to force each website to reload if I
      Message 2 of 7 , Jul 9 8:49 AM
      • 0 Attachment
        Hi David,

        I ran into this problem on an application that was shared across multiple websites on the server, when I wanted to force each website to reload if I changed the application. What I did was the following:

        1 - I set a parameter named dateLastLoaded in the <parameters> section of fusebox.xml
        2 - I wrote an include file in the same folder as fusebox.init, that set a variable that also had that exact same value.
        3 - Any time I made changes to the application that involved changing fusebox.xml or a circuit.xml file, I would change the fusebox dateLastLoaded value, and the value in the include file.
        4 - I included the file in fusebox.init, and if the value of the variable didn't match application.fusebox.dateLastLoaded, I knew I had to reload the fusebox so I would relocate the user to their current URL with '&fusebox.loadclean=true' appended to the querystring.

        It worked quite well for me, I think it would probably work well for you also, though you might want to tweak it somehow because the second application server would only need a fusebox.load, not loadclean (because the first application server would already have deleted the parsed files)

        Mike
        www.fusebuilder.net

        On 10-07-09 08:13 AM, dcmccan@... wrote:
         

        Fusebox has been a boon in speeding development and making maintenance an easy process. Thank you to everyone for their contributions and help.

        I am wondering if people might suggest alternate ways to reload fusebox when there is a code update? The URL parameter method is a little tricky due to multiple load balanced servers.

        We have 2 web servers at a hosting site that are using Microsoft network load balancing with sticky sessions (which means that once someone hits a server they stay there for their session, but incoming new users are distributed more or less evenly). To the world the pair of servers has one IP address. This means that if I go to the site URL in the web browser and give the URL reload command, only one of the pair would get reloaded (whichever one I was sent to). So currently, to reload fusebox I need to have a VPN connection to the hosting site and have added special routes and host file entries, so I can be sure to individually hit each one to give the reload command on the URL. I am a little worried because if other people need to do an update when I am on vacation they likely won't have these special settings already in place.

        Is there a way that we could either:

        -- drop a file on the servers when doing an update and have the application check for it and if found, do a reload and delete the file?

        or

        -- set a task or timeout so that the application would get reloaded every hour or something. If this option, is there any danger of problems due to code/cache mismatches between the time the code is updated and the timeout/reload period?

        or

        -- set a value in the database telling each server to reload fusebox and have the application query for it and then clear the flag for that server?

        Other ideas?

        It seems like the timeout or scheduled task would be the easiest as it would require no special user action. The file would be the next easiest and the database the third.

        Thank you very much for your suggestions.

        David

      • Sean Corfield
        On Fri, Jul 9, 2010 at 8:13 AM, dcmccan@rocketmail.com
        Message 3 of 7 , Jul 9 10:27 AM
        • 0 Attachment
          On Fri, Jul 9, 2010 at 8:13 AM, dcmccan@... <dcmccan@...> wrote:

          I am wondering if people might suggest alternate ways to reload fusebox when there is a code update? The URL parameter method is a little tricky due to multiple load balanced servers.


          Yeah, this is a thorny problem for all the frameworks out there because they all rely on a URL to reload an instance.

          When I have a cluster (which is nearly always), I take a different approach.
          • I drain sessions on a server (set the LB so new sessions go elsewhere and wait until no active sessions are on that server).
          • I shutdown that server instance
          • I update the code via a build script that cleans up any generated files (lots of frameworks generate code)
          • I restart that server instance and run a warm-up script locally
          • I put it back in the LB pool and start on the next server
          Some caveats:
          • If you have DB changes, you usually have to shut the whole site down to avoid inconsistent behavior across the cluster
          • You can't share code between servers (mind you, NFS etc has enough of a performance hit that shared code is rarely a good idea)
          • If you have a large cluster, you can shutdown half of it, upgrade, then switch traffic (i.e., drain the other half)
          This solves all sorts of problems with clusters and upgrades (but it does rely on more scripted, automated build processes).
          --
          Sean A Corfield -- (904) 302-SEAN
          Railo Technologies, Inc. -- http://getrailo.com/
          An Architect's View -- http://corfield.org/

          "If you're not annoying somebody, you're not really alive."
          -- Margaret Atwood
        • Dominic Watson
          We have three load balanced live servers and do our circuit reload on a non-live, deployment server, syncing all the files using Robocopy (rsync would work
          Message 4 of 7 , Jul 12 11:43 AM
          • 0 Attachment
            We have three load balanced live servers and do our circuit reload on a non-live, 'deployment' server, syncing all the files using Robocopy (rsync would work on linux). If the application needs restarting, we take each instance out of the cluster to restart it (this bit could be better).

            HTH

            Dominic

            On 9 July 2010 18:27, Sean Corfield <seancorfield@...> wrote:
             

            On Fri, Jul 9, 2010 at 8:13 AM, dcmccan@... <dcmccan@...> wrote:

            I am wondering if people might suggest alternate ways to reload fusebox when there is a code update? The URL parameter method is a little tricky due to multiple load balanced servers.


            Yeah, this is a thorny problem for all the frameworks out there because they all rely on a URL to reload an instance.

            When I have a cluster (which is nearly always), I take a different approach.
            • I drain sessions on a server (set the LB so new sessions go elsewhere and wait until no active sessions are on that server).
            • I shutdown that server instance
            • I update the code via a build script that cleans up any generated files (lots of frameworks generate code)
            • I restart that server instance and run a warm-up script locally
            • I put it back in the LB pool and start on the next server
            Some caveats:
            • If you have DB changes, you usually have to shut the whole site down to avoid inconsistent behavior across the cluster
            • You can't share code between servers (mind you, NFS etc has enough of a performance hit that shared code is rarely a good idea)
            • If you have a large cluster, you can shutdown half of it, upgrade, then switch traffic (i.e., drain the other half)
            This solves all sorts of problems with clusters and upgrades (but it does rely on more scripted, automated build processes).
            --
            Sean A Corfield -- (904) 302-SEAN
            Railo Technologies, Inc. -- http://getrailo.com/
            An Architect's View -- http://corfield.org/

            "If you're not annoying somebody, you're not really alive."
            -- Margaret Atwood

          • dcmccan@rocketmail.com
            Thanks to everyone for the good suggestions. Based on our work flow and inspired by your comments, I m thinking something like this: --In the application root
            Message 5 of 7 , Jul 21 8:57 AM
            • 0 Attachment
              Thanks to everyone for the good suggestions. Based on our work flow and inspired by your comments, I'm thinking something like this:

              --In the application root add a file like 'latest_changes.txt'.

              --Require an entry into this file when changes are made, check it into source control and deploy when updates are pushed out.

              --In the log-in function add a check using CFDIRECTORY to get the time stamp of the file.

              --Compare the file time stamp to the myFusebox.getApplicationData().startTime and if the file is newer then use CFHTTP to reload the application.

              <cfhttp method="GET" result="myResult" url="http://mysite/index.cfm" redirect="No">
              <cfhttpparam name="fusebox.loadclean" value="true" type="URL">
              <cfhttpparam name="fusebox.parseall" value="true" type="URL">
              <cfhttpparam name="fusebox.execute" value="true" type="URL">
              <cfhttpparam name="fusebox.password" value="myPassword" type="URL">
              </cfhttp>

              We have lots of visitors so the log-in function is fired frequently, but there may be a short time when the application has not been reloaded. Would this just mean that the changes would not be applied yet or do I need to do this check more often? Does it seem like a good plan?

              Thank you for your feedback,

              David


              --- In fusebox5@yahoogroups.com, Dominic Watson <watson.dominic@...> wrote:
              >
              > We have three load balanced live servers and do our circuit reload on a
              > non-live, 'deployment' server, syncing all the files using Robocopy (rsync
              > would work on linux). If the application needs restarting, we take each
              > instance out of the cluster to restart it (this bit could be better).
              >
              > HTH
              >
              > Dominic
              >
              > On 9 July 2010 18:27, Sean Corfield <seancorfield@...> wrote:
              >
              > >
              > >
              > > On Fri, Jul 9, 2010 at 8:13 AM, dcmccan@... <
              > > dcmccan@...> wrote:
              > >
              > >> I am wondering if people might suggest alternate ways to reload fusebox
              > >> when there is a code update? The URL parameter method is a little tricky due
              > >> to multiple load balanced servers.
              > >>
              > >
              > > Yeah, this is a thorny problem for all the frameworks out there because
              > > they all rely on a URL to reload an instance.
              > >
              > > When I have a cluster (which is nearly always), I take a different
              > > approach.
              > >
              > > - I drain sessions on a server (set the LB so new sessions go elsewhere
              > > and wait until no active sessions are on that server).
              > > - I shutdown that server instance
              > > - I update the code via a build script that cleans up any generated
              > > files (lots of frameworks generate code)
              > > - I restart that server instance and run a warm-up script locally
              > > - I put it back in the LB pool and start on the next server
              > >
              > > Some caveats:
              > >
              > > - If you have DB changes, you usually have to shut the whole site down
              > > to avoid inconsistent behavior across the cluster
              > > - You can't share code between servers (mind you, NFS etc has enough of
              > > a performance hit that shared code is rarely a good idea)
              > > - If you have a large cluster, you can shutdown half of it, upgrade,
              > > then switch traffic (i.e., drain the other half)
              > >
              > > This solves all sorts of problems with clusters and upgrades (but it does
              > > rely on more scripted, automated build processes).
              > > --
              > > Sean A Corfield -- (904) 302-SEAN
              > > Railo Technologies, Inc. -- http://getrailo.com/
              > > An Architect's View -- http://corfield.org/
              > >
              > > "If you're not annoying somebody, you're not really alive."
              > > -- Margaret Atwood
              > >
              > >
              >
            • Ray Varner
              Depending on your implementation, how about an XFA approach for reloading: event.xfa( ReloadApp , myFusebox.getApplication().defaultFuseaction, fusebox.load ,
              Message 6 of 7 , Jul 21 1:51 PM
              • 0 Attachment
                Depending on your implementation, how about an XFA approach for reloading:

                event.xfa('ReloadApp', myFusebox.getApplication().defaultFuseaction,
                'fusebox.load', 'true',
                'fusebox.parse', 'true',
                'fusebox.password',
                myFusebox.getApplication().password,
                'SomeOtherVar', 'WhateverVal');

                myFusebox.relocate(xfa='ReloadApp',addToken='false');

                On Wed, Jul 21, 2010 at 11:57 AM, dcmccan@... <dcmccan@...> wrote:
                 

                Thanks to everyone for the good suggestions. Based on our work flow and inspired by your comments, I'm thinking something like this:

                --In the application root add a file like 'latest_changes.txt'.

                --Require an entry into this file when changes are made, check it into source control and deploy when updates are pushed out.

                --In the log-in function add a check using CFDIRECTORY to get the time stamp of the file.

                --Compare the file time stamp to the myFusebox.getApplicationData().startTime and if the file is newer then use CFHTTP to reload the application.

                <cfhttp method="GET" result="myResult" url="http://mysite/index.cfm" redirect="No">
                <cfhttpparam name="fusebox.loadclean" value="true" type="URL">
                <cfhttpparam name="fusebox.parseall" value="true" type="URL">
                <cfhttpparam name="fusebox.execute" value="true" type="URL">
                <cfhttpparam name="fusebox.password" value="myPassword" type="URL">
                </cfhttp>

                We have lots of visitors so the log-in function is fired frequently, but there may be a short time when the application has not been reloaded. Would this just mean that the changes would not be applied yet or do I need to do this check more often? Does it seem like a good plan?

                Thank you for your feedback,

                David



                --- In fusebox5@yahoogroups.com, Dominic Watson <watson.dominic@...> wrote:
                >
                > We have three load balanced live servers and do our circuit reload on a
                > non-live, 'deployment' server, syncing all the files using Robocopy (rsync
                > would work on linux). If the application needs restarting, we take each
                > instance out of the cluster to restart it (this bit could be better).
                >
                > HTH
                >
                > Dominic
                >
                > On 9 July 2010 18:27, Sean Corfield <seancorfield@...> wrote:

                >
                > >
                > >
                > > On Fri, Jul 9, 2010 at 8:13 AM, dcmccan@... <
                > > dcmccan@...> wrote:
                > >
                > >> I am wondering if people might suggest alternate ways to reload fusebox
                > >> when there is a code update? The URL parameter method is a little tricky due
                > >> to multiple load balanced servers.
                > >>
                > >
                > > Yeah, this is a thorny problem for all the frameworks out there because
                > > they all rely on a URL to reload an instance.
                > >
                > > When I have a cluster (which is nearly always), I take a different
                > > approach.
                > >
                > > - I drain sessions on a server (set the LB so new sessions go elsewhere
                > > and wait until no active sessions are on that server).
                > > - I shutdown that server instance
                > > - I update the code via a build script that cleans up any generated
                > > files (lots of frameworks generate code)
                > > - I restart that server instance and run a warm-up script locally
                > > - I put it back in the LB pool and start on the next server
                > >
                > > Some caveats:
                > >
                > > - If you have DB changes, you usually have to shut the whole site down
                > > to avoid inconsistent behavior across the cluster
                > > - You can't share code between servers (mind you, NFS etc has enough of
                > > a performance hit that shared code is rarely a good idea)
                > > - If you have a large cluster, you can shutdown half of it, upgrade,
                > > then switch traffic (i.e., drain the other half)
                > >
                > > This solves all sorts of problems with clusters and upgrades (but it does
                > > rely on more scripted, automated build processes).
                > > --
                > > Sean A Corfield -- (904) 302-SEAN
                > > Railo Technologies, Inc. -- http://getrailo.com/
                > > An Architect's View -- http://corfield.org/
                > >
                > > "If you're not annoying somebody, you're not really alive."
                > > -- Margaret Atwood
                > >
                > >
                >


              • dcmccan@rocketmail.com
                Nice example. Thanks. I m thinking that by using cfhttp the reload will happen in the background without redirecting the user.
                Message 7 of 7 , Jul 22 2:13 PM
                • 0 Attachment
                  Nice example. Thanks. I'm thinking that by using cfhttp the reload will happen in the background without redirecting the user.



                  --- In fusebox5@yahoogroups.com, Ray Varner <RayVarner@...> wrote:
                  >
                  > Depending on your implementation, how about an XFA approach for reloading:
                  >
                  > event.xfa('ReloadApp', myFusebox.getApplication().defaultFuseaction,
                  > 'fusebox.load', 'true',
                  > 'fusebox.parse', 'true',
                  > 'fusebox.password',
                  > myFusebox.getApplication().password,
                  > 'SomeOtherVar', 'WhateverVal');
                  >
                  > myFusebox.relocate(xfa='ReloadApp',addToken='false');
                  >
                  > On Wed, Jul 21, 2010 at 11:57 AM, dcmccan@... <
                  > dcmccan@...> wrote:
                  >
                  > >
                  > >
                  > > Thanks to everyone for the good suggestions. Based on our work flow and
                  > > inspired by your comments, I'm thinking something like this:
                  > >
                  > > --In the application root add a file like 'latest_changes.txt'.
                  > >
                  > > --Require an entry into this file when changes are made, check it into
                  > > source control and deploy when updates are pushed out.
                  > >
                  > > --In the log-in function add a check using CFDIRECTORY to get the time
                  > > stamp of the file.
                  > >
                  > > --Compare the file time stamp to the
                  > > myFusebox.getApplicationData().startTime and if the file is newer then use
                  > > CFHTTP to reload the application.
                  > >
                  > > <cfhttp method="GET" result="myResult" url="http://mysite/index.cfm"
                  > > redirect="No">
                  > > <cfhttpparam name="fusebox.loadclean" value="true" type="URL">
                  > > <cfhttpparam name="fusebox.parseall" value="true" type="URL">
                  > > <cfhttpparam name="fusebox.execute" value="true" type="URL">
                  > > <cfhttpparam name="fusebox.password" value="myPassword" type="URL">
                  > > </cfhttp>
                  > >
                  > > We have lots of visitors so the log-in function is fired frequently, but
                  > > there may be a short time when the application has not been reloaded. Would
                  > > this just mean that the changes would not be applied yet or do I need to do
                  > > this check more often? Does it seem like a good plan?
                  > >
                  > > Thank you for your feedback,
                  > >
                  > > David
                  > >
                  > >
                  > > --- In fusebox5@yahoogroups.com <fusebox5%40yahoogroups.com>, Dominic
                  > > Watson <watson.dominic@> wrote:
                  > > >
                  > > > We have three load balanced live servers and do our circuit reload on a
                  > > > non-live, 'deployment' server, syncing all the files using Robocopy
                  > > (rsync
                  > > > would work on linux). If the application needs restarting, we take each
                  > > > instance out of the cluster to restart it (this bit could be better).
                  > > >
                  > > > HTH
                  > > >
                  > > > Dominic
                  > > >
                  > > > On 9 July 2010 18:27, Sean Corfield <seancorfield@> wrote:
                  > >
                  > > >
                  > > > >
                  > > > >
                  > > > > On Fri, Jul 9, 2010 at 8:13 AM, dcmccan@ <
                  > > > > dcmccan@> wrote:
                  > > > >
                  > > > >> I am wondering if people might suggest alternate ways to reload
                  > > fusebox
                  > > > >> when there is a code update? The URL parameter method is a little
                  > > tricky due
                  > > > >> to multiple load balanced servers.
                  > > > >>
                  > > > >
                  > > > > Yeah, this is a thorny problem for all the frameworks out there because
                  > > > > they all rely on a URL to reload an instance.
                  > > > >
                  > > > > When I have a cluster (which is nearly always), I take a different
                  > > > > approach.
                  > > > >
                  > > > > - I drain sessions on a server (set the LB so new sessions go elsewhere
                  > > > > and wait until no active sessions are on that server).
                  > > > > - I shutdown that server instance
                  > > > > - I update the code via a build script that cleans up any generated
                  > > > > files (lots of frameworks generate code)
                  > > > > - I restart that server instance and run a warm-up script locally
                  > > > > - I put it back in the LB pool and start on the next server
                  > > > >
                  > > > > Some caveats:
                  > > > >
                  > > > > - If you have DB changes, you usually have to shut the whole site down
                  > > > > to avoid inconsistent behavior across the cluster
                  > > > > - You can't share code between servers (mind you, NFS etc has enough of
                  > > > > a performance hit that shared code is rarely a good idea)
                  > > > > - If you have a large cluster, you can shutdown half of it, upgrade,
                  > > > > then switch traffic (i.e., drain the other half)
                  > > > >
                  > > > > This solves all sorts of problems with clusters and upgrades (but it
                  > > does
                  > > > > rely on more scripted, automated build processes).
                  > > > > --
                  > > > > Sean A Corfield -- (904) 302-SEAN
                  > > > > Railo Technologies, Inc. -- http://getrailo.com/
                  > > > > An Architect's View -- http://corfield.org/
                  > > > >
                  > > > > "If you're not annoying somebody, you're not really alive."
                  > > > > -- Margaret Atwood
                  > > > >
                  > > > >
                  > > >
                  > >
                  > >
                  > >
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.