Skip to content

Mach II Team Meeting June 29, 2011

Jump to bottom Edit New page
thofrey edited this page Apr 1, 2014 · 7 revisions

Table of Contents

  1. General
  2. Mach-II 1.9 M3/Final
  3. Enlist

Attendees: Peter Farrell, Kurt Wiersma, Jason York, Mike Rogers, Matt Woodward

General

  • Would like to have semi-regular public calls to grow the community, inspire more
  • Will potentially try Ecko-It in the future (audio wiki) -record the calls and upload to Ecko-It for tagging, notes, discussion, etc. tied to the audio

Mach-II 1.9 M3/Final

  • Mike Rogers had a baby (congrats!) so we’re regrouping on the workload on the globalization/internationalization pieces, which is the bulk of what’s left for 1.9 M3

  • Ticket (trac-wiki) #678 "enhancement: Locale negotiation via new globalization config parameters (closed: fixed)") - locale negotiation

    • Complete?
    • Mike recalls that the user could change the locale based on a URL parameter, but needs to be reviewed

  • Ticket (trac-wiki) #679 "enhancement: Modify BuildURL to be Locale-sensitive (closed: Moved to GitHub)") - making BuildUrl locale sensitive

    • internationalization wiki page is pretty up to date in terms of where we are
    • Peter: need to get this out the door, been 16 months since last stable release doesn’t need to be 100% complete as compared to milestone goals

  • Ticket (trac-wiki) #795 "defect: Reloading base throws exception in Log.cfc (closed: Moved to GitHub)") - reloading Base from Dashboard throws exception in Log.cfc

    • Jason will work with Doug to re-test and nail down specifically why this happens has to do with deconfigure cycle

    • Overview: if you call deconfigure when under load, requests start erroring out because the requests are taking long enough that the new app manager isn’t yet available

      • potentially has to do with destroying objects on a separate thread that are still actually in use
      • work-around for now is when base or module reload is needed, take servers out of service on load balancer to wait for requests to die down, but this can potentially take a couple of hours to reload all the production servers

    • one potential solution relates to thread tracking - see ticket (trac-wiki) #726 "defect: Premature deconfigure during config reload (closed: fixed)") (closed) for more info

      • preference would be not to have to track threads, get into race conditions, heavy-weight process, etc.
      • Basically have to track thread IDs and see if they were started before deconfigure is called
      • want to get newly spawned threads calling the new app manager so you know it’s OK to call deconfigure because nothing is still using the old app manager
        • e.g. say there’s 10 threads in the pool - can get the IDs of live threads in the pool if a thread is reused from the pool the internal ID changes - these get reused but it’s infrequent enough that it’s not an issue (at least based on ApacheBench testing
        • Peter emailed with Sean on CFGuru and the speculation is something changed under the hood in CF 9 related to how struct loops are handled
        • Will probably try running thread tracking all the time to see if there’s a negative performance impact
        • May add a configurable parameter to set how long the old app manager hangs around before it gets destroyed
        • or, could leave old app manager around for a long enough time (several minutes) so we’d “know” for sure that the old one isn’t still being used
        • could tie to environments too - wouldn’t care about this on dev, so could only kick in on production
        • will try tracking threads all the time first and see if there’s an adverse performance hit. if so, we’ll try some of the other ideas (wait longer to kill the old app manager)

  • check wiki for other m3 tickets - this is still accurate

    • ticket (trac-wiki) #785 "defect: Element DATA is undefined in DATASTORAGE (closed: Moved to GitHub)") is probably also related to the odd behavior with structkeydelete in CF 9
    • ticket (trac-wiki) #703 "defect: processCfdump() in MachIILogger breaks UI on Railo (closed: Moved to GitHub)") - Railo specific. Need to determine how urgent this is.

targeting 1.9 M3 by end of July

Enlist

  • couple of blockers in new version of OpenBD for GAE are about fixed
  • probably 80% done with the vertical areas of functionality, just need to tie them together better, do some UI work once the OpenBD functionality is done
  • might help to start stubbing out some of the additional screens - do UI and create a ticket but just stub out the code
Add a custom footer
Add a custom sidebar
Clone this wiki locally