summaryrefslogtreecommitdiff
path: root/Assistant/Monad.hs
Commit message (Collapse)AuthorAge
* add CredPair cacheGravatar Joey Hess2014-04-29
| | | | | | | Note that this does not yet use SecureMem. It would probably make sense for the Password part of a CredPair to use SecureMem, and making that change is better than passing in a String and having it converted to SecureMem in this code.
* assistant: Now detects immediately when other repositories push changes toGravatar Joey Hess2014-04-08
| | | | | | | | | | | | a ssh remote, and pulls. XMPP is no longer needed in this configuration! Requires the remote server have git-annex-shell with notifychanges support. (untested) This commit was sponsored by Geog Wechslberger.
* assistant: Start a new git-annex transferkeys process after a network ↵Gravatar Joey Hess2014-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | connection change So that remotes that use a persistent network connection are restarted. A remote might keep open a long duration network connection, and could fail to deal well with losing the connection. This is particularly a concern now that we have external special reotes. An external special remote that is implemented naively might open the connection only when PREPARE is sent, and if it loses connection, throw errors on each request that is made. (Note that the ssh connection caching should not have this problem; if the long-duration ssh process loses connection, the named pipe is disconnected and the next ssh attempt will reconnect. Also, XMPP already deals with disconnection robustly in its own way.) There's no way for git-annex to know if a lost network connection actually affects a given remote, which might have a transfer in process. It does not make sense to force kill the transferkeys process every time the NetWatcher detects a change. (Especially because the NetWatcher sometimes polls 1 change per hour.) In any case, the NetWatcher only detects connection to a network, not disconnection. So if a transfer is in progress over the network, and the network goes down, that will need to time out on its own. An alternate approch that was considered is to use a separate transferkeys process for each remote, and detect when a request fails, and assume that means that process is in a failing state and restart it. The problem with that approach is that if a resource is not available and a remote fails every time, it degrades to starting a new transferkeys process for every file transfer, which is too expensive. Instead, this commit only handles the network reconnection case, and restarts transferkeys only once the network has reconnected and another transfer needs to be made. So, a transferkeys process will be reused for 1 hour, or until the next network connection. ---- The NotificationBroadcaster was rewritten to use TMVars rather than MSampleVars, to allow checking without blocking if a notification has been received. ---- This commit was sponsored by Tobias Brunner.
* Another round of s/amoung/among/Gravatar Richard Hartmann2013-12-19
|
* move code around and rename thread; no functional changesGravatar Joey Hess2013-10-29
|
* automatically launch git repository repairGravatar Joey Hess2013-10-27
| | | | | | | | | | | | | | | | | | Added a RemoteChecker thread, that waits for problems to be reported with remotes, and checks if their git repository is in need of repair. Currently, only failures to sync with the remote cause a problem to be reported. This seems enough, but we'll see. Plugging in a removable drive with a repository on it that is corrupted does automatically repair the repository, as long as the corruption causes git push or git pull to fail. Some types of corruption do not, eg missing/corrupt objects for blobs that git push doesn't need to look at. So, this is not really a replacement for scheduled git repository fscking. But it does make the assistant more robust. This commit is sponsored by Fernando Jimenez.
* Switch to MonadCatchIO-transformers for better handling of state while ↵Gravatar Joey Hess2013-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | catching exceptions. As seen in this bug report, the lifted exception handling using the StateT monad throws away state changes when an action throws an exception. http://git-annex.branchable.com/bugs/git_annex_fork_bombs_on_gpg_file/ .. Which can result in cached values being redundantly calculated, or other possibly worse bugs when the annex state gets out of sync with reality. This switches from a StateT AnnexState to a ReaderT (MVar AnnexState). All changes to the state go via the MVar. So when an Annex action is running inside an exception handler, and it makes some changes, they immediately go into affect in the MVar. If it then throws an exception (or even crashes its thread!), the state changes are still in effect. The MonadCatchIO-transformers change is actually only incidental. I could have kept on using lifted-base for the exception handling. However, I'd have needed to write a new instance of MonadBaseControl for the new monad.. and I didn't write the old instance.. I begged Bas and he kindly sent it to me. Happily, MonadCatchIO-transformers is able to derive a MonadCatchIO instance for my monad. This is a deep level change. It passes the test suite! What could it break? Well.. The most likely breakage would be to code that runs an Annex action in an exception handler, and *wants* state changes to be thrown away. Perhaps the state changes leaves the state inconsistent, or wrong. Since there are relatively few places in git-annex that catch exceptions in the Annex monad, and the AnnexState is generally just used to cache calculated data, this is unlikely to be a problem. Oh yeah, this change also makes Assistant.Types.ThreadedMonad a bit redundant. It's now entirely possible to run concurrent Annex actions in different threads, all sharing access to the same state! The ThreadedMonad just adds some extra work on top of that, with its own MVar, and avoids such actions possibly stepping on one-another's toes. I have not gotten rid of it, but might try that later. Being able to run concurrent Annex actions would simplify parts of the Assistant code.
* use TList for ChangePoolGravatar Joey Hess2013-04-24
|
* turn on PackageImports globallyGravatar Joey Hess2013-04-13
| | | | | | | This will make it easier to use the Evil Splicer, when it needs to add package qualified imports And there's no real downside.
* maintain pools of running transferkeys processes (untested)Gravatar Joey Hess2013-03-19
|
* make liftAnnex and liftAssistant polymorphic, like liftIOGravatar Joey Hess2013-03-16
|
* webapp: Now allows restarting any threads that crash.Gravatar Joey Hess2013-01-26
|
* use async to track and manage threadsGravatar Joey Hess2013-01-26
|
* renameGravatar Joey Hess2012-11-08
|
* better handling of lifting from XMPP -> AssistantGravatar Joey Hess2012-11-05
|
* refactor XMPP clientGravatar Joey Hess2012-11-03
|
* xmpp buddy list trackingGravatar Joey Hess2012-11-02
|
* finished pushing Assistant monad into all relevant filesGravatar Joey Hess2012-10-30
| | | | All temporary and old functions are removed.
* pushed Assistant monad down into DaemonStatus codeGravatar Joey Hess2012-10-30
| | | | | | Currently have three old versions of functions that more reworking is needed to remove: getDaemonStatusOld, modifyDaemonStatusOld_, and modifyDaemonStatusOld
* split remaining assistant typesGravatar Joey Hess2012-10-30
|
* split out daemonstatus typesGravatar Joey Hess2012-10-30
|
* split Commits and liftedGravatar Joey Hess2012-10-29
|
* split Changes and liftedGravatar Joey Hess2012-10-29
|
* split BranchChange and liftedGravatar Joey Hess2012-10-29
|
* split ScanRemotes and liftedGravatar Joey Hess2012-10-29
|
* moved ThreadedMonad to TypesGravatar Joey Hess2012-10-29
|
* split and lift Assistant.PushesGravatar Joey Hess2012-10-29
|
* tweakGravatar Joey Hess2012-10-29
|
* Assistant monad, stage 2.5Gravatar Joey Hess2012-10-29
| | | | | | | | | | Converted several threads to run in the monad. Added a lot of useful combinators for working with the monad. Now the monad includes the name of the thread. Some debugging messages are disabled pending converting other threads.
* Assistant monad, stage 1Gravatar Joey Hess2012-10-29
This adds the Assistant monad, and an AssistantData structure. So far, none of the assistant's threads run in the monad yet.