Release/0.5.0 #102
Release/0.5.0 #102
Conversation
|
It's coming along @ungn! |
executor/Cargo.toml
Outdated
| persistent = "0.3" | ||
| logger = "0.2" | ||
| env_logger = "0.3" | ||
| rustc-serialize = "0.3" |
There was a problem hiding this comment.
executor/src/executor/mod.rs
Outdated
| let mut writer = rwlock.write().unwrap(); | ||
| if writer.is_running() { | ||
| let mut body = String::new(); | ||
| match request.body.read_to_string(&mut body) { |
There was a problem hiding this comment.
| impl Dispatcher { | ||
| pub fn new() -> Dispatcher { | ||
| Dispatcher { | ||
| job_queue: Vec::new(), |
|
Hey @ungn, just to recap my thoughts on what the "thread pool/channels" part of this will look like. At the beginning of the process we create a new thread that will be our "worker manager". We can communicate with this thread using a channel. Each request that comes in should be transformed into a strongly typed request for the "worker manager" by the iron handlers (this means our "worker manager" can be unit tested without being coupled to the actual http requests). This "worker manager" is responsible for:
Jobs themselves can be dispatched on futures provided by this crate. We may not need a separate thread to process a channel (or even need a channel at all). My only reason for including it is so we can dequeue jobs as running jobs are completed (separate from http calls). So, a bit more on "seams" and why I always ramble about them, the Iron request handlers are responsible for converting HTTP requests into some kind of request understandable by our business logic. This means that we can test the business logic without iron. We should be able to test the request handlers convert the right kind of data into business logic requests, also without iron. What we don't need to do however is spin up iron and see that our requests "really" turn into jobs and so on. It'd be nice to add this level of integration testing - entirely optional. I'm on the "tests should run faster than facebook.com loads" kind of camp. Apologies if I'm teaching you to suck eggs here! It's cool if through looking at this in more detail you come up with something better. I just wanted to explain one way that could work - the only bad plan is one that cannot be changed imo. |
373d453 to
83340cf
Compare
0bfcea2 to
e4829a6
Compare
7c8a49f to
1efe674
Compare
|
TODO:
|
|
Closing as changes for #98 are covered in separate factotum-server project and #94 is parked until a better solution for underlying problem can be found (see comments for further info). |
Factotum "server mode":
log file/databasemerge into main factotum Cargo.tomlmove to separate repo