search

chef / sqerl

General purpose RDBMS abstraction layer
Apache License 2.0
42 stars 18 forks source link

Load application spec before trying to load its modules #98

Closed MattVonVielen closed 9 years ago

MattVonVielen commented 9 years ago

Without this step, it's possible to encounter a situation where sqerl tries to reflect on the module list of an application which has not yet been loaded.

marcparadise commented 9 years ago

Looks good but I have two questions. The context here is that I haven't worked with sqerl_rec yet, and don't know when and how often in an application lifecycle statements gets invoked. It looks like it's going to be at setup/initialization of a connection, which in turn could happen when the sqerl application is loaded. With that in mind:

1) Are there concerns about the frequency at which this might be called, and perf of a re-check of application load state (internal to application:load) for systems with a large number of baseline + loaded applications? Particularly in the case of a connection pool gone bad and needing to have all connections refreshed in short order.

2) If these run during startup of the sqerl application as part of connection allocation, is there the possibility that doing this will change the sequence in which remaining applications load, and cause odd behaviors in other places?

MattVonVielen commented 9 years ago

@marcparadise

Item 1 is probably better answered by @seth; I feel a bit out of my depth on that point

As for Item 2, application:load and application:start are importantly different concepts. The first simply loads the application's metadata (ebin/foo.app) into the node's application controller, while the second load the beam code and starts the process tree. An application can't be started until it's also been loaded, so (I believe) application:start calls into application:load itself under the hood in the event of a cache miss. The upshot is, pre-loading the app metadata shouldn't affect the start order at all.

marcparadise commented 9 years ago

Okay, thanks for the clarification re:2. I had thought that load also pullled in the beams.

seth commented 9 years ago

Regarding (1), I think this code path is only called on system start or, as you mentioned, if we are recreating this part of the supervision tree. The call itself is pretty cheap. Since I don't see how we'd be calling this in a tight loop, I'm not worried about performance impact.

marcparadise commented 9 years ago

Cool, thanks @seth. I'm :+1: