Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 18 21:17

    sneiland on v4.3.0

    (compare)

  • Apr 18 21:17

    sneiland on master

    (compare)

  • Jan 07 15:43
    lramirez925 commented #541
  • Jan 07 14:16
    matthewjones commented #541
  • Jan 07 01:31
    lramirez925 commented #541
  • Jan 06 21:01
    sneiland labeled #541
  • Jan 06 21:01
    sneiland assigned #541
  • Jan 06 21:01
    sneiland opened #541
  • Dec 16 2021 16:48
    sneiland labeled #540
  • Dec 16 2021 16:48
    sneiland labeled #540
  • Dec 16 2021 16:25
    tonyjunkes commented #540
  • Dec 16 2021 16:00
    lramirez925 commented #540
  • Dec 16 2021 15:48
    mjclemente opened #540
  • Oct 31 2021 20:52

    sneiland on fw1-538

    (compare)

  • Oct 29 2021 21:16

    sneiland on master

    Update to match FW1 implementat… (compare)

  • Oct 29 2021 20:58
    sneiland commented #518
  • Oct 29 2021 20:57
    sneiland closed #527
  • Oct 29 2021 20:56
    sneiland commented #538
  • Oct 29 2021 20:55
    sneiland closed #522
  • Oct 29 2021 19:44
    sneiland labeled #539
Sean Corfield
@seancorfield
[Sean Corfield, cfml] I think there is still a thread safety bug in DI/1 — there are two lines of comments around the section that would need to be locked (as a fairly brutal single-threading fix).
[Sean Corfield, cfml] See resolveCreateBean(), lines 818-880.
[Sean Corfield, cfml] I’d rather not wrap that whole thing in an application lock for performance reasons but I believe it would “solve” that particular known issue.
[Sean Corfield, cfml] FWIW, we’ve never encountered it at World Singles — but we also never reload the app under load :)
[jcberquist, cfml] @seancorfield I thought that issue particularly related to the init() method returning something other than this? Was it a broader issue than that?
[Sean Corfield, cfml] I think there could be a better fix than just sledgehammer-locking that section but I haven’t figured it out yet :| No, this is a general issue that could explain what both of you are seeing.
[jtreher, cfml] I'm beginning to think that we might have been relying on it not being thread safe :face_vomiting:
[Sean Corfield, cfml] Oh?
[jtreher, cfml] I'm just trying to figure out how it was working in 3.0 without issue.
[jtreher, cfml] We've been running that for 3 years now? I was the one that originally jammed it in.
Sean Corfield
@seancorfield
[John Whish, cfml] So there was an issue a while back of wiring a singleton into a transient. Is that the kind of thing you are doing?
[jtreher, cfml] Again, the only thing we had to modify was to switch the thinking around "unhandled" paths to bring in the concept of "handled" paths. Other than that, it works out of the box.
[jtreher, cfml] Nah, these are all singletons.
[jtreher, cfml] The things we are having trouble with (and we can get it to error at different spots) are all .addBean one is a number, others are instances of cfcs. Stuff created outside of DI/1 but made availble by DI/1 for property injection.
Sean Corfield
@seancorfield
[John Whish, cfml] Hmm, so if I follow, you do something like:
[John Whish, cfml] Does FW/1 create DI/1 for you?
[jtreher, cfml] Yep
[jtreher, cfml] Our overrides amount to about 10 lines of code just around the handled request logic.
[jtreher, cfml] I don't wnat you guys to think that we rewrote the whole thing ;)
[John Whish, cfml] ha :) We have a legacy app and I've put FW/1 into it so had to jump through some hoops like you. In the end I create DI/1 explicitly and pass it in via setBeanFactory() for ... reasons!
Sean Corfield
@seancorfield
[John Whish, cfml] If I follow, FW/1 creates DI/1, scans and finds beans (all good). Some (say foo) of those beans need a bean which you add manually via addBean. So my current guess is that the 'foo' bean is being asked for (getbean('foo')) before the addBean code has run. Wild stab in the dark there...
[John Whish, cfml] So, I think you may be able to leverage onLoadEvent (which runs directly after discoverbeans) to do all the addBean stuff.
Sean Corfield
@seancorfield
[John Whish, cfml] So do you call addBean in your listener passed to onLoad?
[John Whish, cfml] Ah yeah, you say you are using loadListener. In that case - no idea. Sorry.
Sean Corfield
@seancorfield
[John Whish, cfml] mind you the lock in discoverBeans ends before it does the loadListener bit
Sean Corfield
@seancorfield
[jtreher, cfml] hmmmm, right, that could be the issue.
[jtreher, cfml] Maybe I'll try the aggressive locking to see how that goes.
Sean Corfield
@seancorfield
[jtreher, cfml] No dice, dang.
Sean Corfield
@seancorfield
[John Whish, cfml] Did you just extend the lock in discoverbeans?
[jtreher, cfml] I might have stumbled on to something here by using getDefaultBeanFactory() in setupRequest()
[jtreher, cfml] Instead of getBeanFactory()
[jtreher, cfml] And calling applicationStop()
Sean Corfield
@seancorfield
[jtreher, cfml] I cannot replicate the issue on local anymore using getDefaultBeanFactory() instead of getBeanFactory() everywhere in application.cfc that wants access to the "main beanfactory" unless I enable the reload on every request flag.
[jtreher, cfml] and, all of our addBean stuff now only happens on the main DI instance unlike when it used to happen for all of them in 3.0
[jtreher, cfml] Previously, each subsystem instance would have had the loadListener firing (something we maybe were taking advantage of?)
[Sean Corfield, cfml] That sounds related to subsystems still being initialized on demand when the first request for an action within it comes in.
[jtreher, cfml] I think so. And every request is in a subsystem now, right?
[Sean Corfield, cfml] No.
[jtreher, cfml] Dang
[Sean Corfield, cfml] You’re using “legacy subsystems” still?
[jtreher, cfml] Yes.
[jtreher, cfml] That only applies to the "new" then, eh?
Sean Corfield
@seancorfield
[Sean Corfield, cfml] The main app is not a subsystem in either case.
[Sean Corfield, cfml] The issue is just that subsystem initialization is on demand and thus could fall foul of thread safety issues if heavy load hits an uninitialized subsystem. The plan was to add an “eager initialization” option to the new subsystems stuff to get around that.
Sean Corfield
@seancorfield
[clockworkrebel, cfml] I'm using FW/1 with DI/1 and I'm trying to figure if the DI/1 methods mentioned in the "Overriding DI/1 Behavior" section of the documentation will be called for FW/1 controllers (particularly the construct method).
[clockworkrebel, cfml] The method doesn't seem to be called for me, but it's entirely possible I've just got something set up wrong.
[clockworkrebel, cfml] So I'm wondering if those methods are expected to be called (and therefore I should keep looking at what I screwed up) or if those methods wouldn't be called even if all my stuff was functioning at 100%
Sean Corfield
@seancorfield
[Sean Corfield, cfml] @clockworkrebel Do you have diLocations set in your FW/1 config?
[Sean Corfield, cfml] The default (if you omit it) is for FW/1 to let DI/1 manage both controllers and the model, but if you override that it and don't tell it to manage the controllers...
[Sean Corfield, cfml] Also, which version of FW/1 are you using?