Commit Graph

11 Commits

Author SHA1 Message Date
Daniel Schalla
531897b1f0 add megacheck as makefile target (#9288)
Fix code issues in channel_test.go

Fix Channel Test Issues detected by Megacheck

Fix API Emoji Test Issues detected by Megacheck

Fixed API Issues Reported by Megacheck

Fixed App issues reported by megacheck

Remaining fixes

removed test added by mistake from old HEAD

gofmt

Store Fixes

simplified returns

Fix test for multi member channel delete

revert to delete unused function
2018-09-03 14:08:40 +02:00
Jesse Hallam
835c0871a0 MM-11431: handle plugin deadlocks (#9167)
* ensure plugin is always shutdown

Once we call `.client.Client()` the plugin has started, and must be shut
down. `newSupervisor` sometimes returned with an error (and without a
reference to the supervisor), leaving the client running indefinitely.

* Clarify the documentation to explain that plugin hooks will not trigger until `OnActivate` returns successfully, and will stop triggering just before `OnDeactivate` is called.

* test for plugin deadlock

* plugin/environment.go: switch to sync.Map

From: https://golang.org/pkg/sync/#Map

> If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock.

The previous `RWMutex` was not safe given that we effectively acquired read locks recursively (hook -> api -> hook). This worked up until we activated or deactivated plugins, tried to acquire a write lock, and the plugin used the API to effectively trigger another hook.

Switching to sync.Map avoids this by divesting the need to lock at all, avoiding the potential for a recursive lock in the first place.
2018-07-27 11:37:17 -04:00
Jesse Hallam
e718d2544f MM-11366: support a plugin bundle with multiple executables (#9121)
This avoids the need to distribute multiple plugins per architecture.
2018-07-17 15:47:05 -07:00
Jesse Hallam
17f211c393 MM-11292: clean up plugins GoDoc (#9109)
* clean up plugins GoDoc:

- eliminate plugin.NewBlankContext() as unnecessary
- export ValidIdRegex as a string vs. the less readable var
- add/update various documentation strings
- hide everything by default, except where used by client plugins or the mattermost-server. The exception to this rule are the `*(Args|Returns)` structs which must be public for go-plugin, but are now prefixed with `Z_` with a warning not to use.
- include a top-level example to get plugin authors started

This is not a breaking change for existing plugins compiled against
plugins-v2.

* remove commented out ServeHTTPResponseWriter

* update examples to match developer docs

* add missing plugin/doc.go license header
2018-07-13 10:29:50 -04:00
Christopher Speller
83a3ac089c MM-11029 Adding plugin logging functionality. (#9034)
* Capturing stdout, stderr of plugins in logs.

* Cleanup go-plugin debug logs.

* Adding logging to plugin API

* Generating mocks.

* godoc convention
2018-07-03 09:58:28 -07:00
Christopher Speller
1e5c432e10 MM-10702 Moving plugins to use hashicorp go-plugin. (#8978)
* Moving plugins to use hashicorp go-plugin.

* Tweaks from feedback.
2018-06-25 12:33:13 -07:00
Jesse Hallam
847c181ec9 MM-8622: Improved plugin error reporting (#8737)
* allow `Wait()`ing on the supervisor

In the event the plugin supervisor shuts down a plugin for crashing too
many times, the new `Wait()` interface allows the `ActivatePlugin` to
accept a callback function to trigger when `supervisor.Wait()` returns.
If the supervisor shuts down normally, this callback is invoked with
a nil error, otherwise any error reported by the supervisor is passed
along.

* improve plugin activation/deactivation logic

Avoid triggering activation of previously failed-to-start plugins just
becase something in the configuration changed. Now, intelligently
compare the global enable bit as well as the each individual plugin's
enabled bit.

* expose store to manipulate PluginStatuses

* expose API to fetch plugin statuses

* keep track of whether or not plugin sandboxing is supported

* transition plugin statuses

* restore error on plugin activation if already active

* don't initialize test plugins until successfully loaded

* emit websocket events when plugin statuses change

* skip pruning if already initialized

* MM-8622: maintain plugin statuses in memory

Switch away from persisting plugin statuses to the database, and
maintain in memory instead. This will be followed by a cluster interface
to query the in-memory status of plugin statuses from all cluster nodes.

At the same time, rename `cluster_discovery_id` on the `PluginStatus`
model object to `cluster_id`.

* MM-8622: aggregate plugin statuses across cluster

* fetch cluster plugin statuses when emitting websocket notification

* address unit test fixes after rebasing

* relax (poor) racey unit test re: supervisor.Wait()

* make store-mocks
2018-05-23 14:26:35 -04:00
Chris
3c7b40063d call OnActivate after plugin crash, update example (#7940) 2017-12-05 09:19:32 -05:00
Chris
d2cff9b77c more plugin doc updates (#7767) 2017-11-03 09:34:44 -07:00
Chris
5dd4466ab3 add missing license headers, test to makefile (#7711) 2017-10-25 09:33:19 -07:00
Chris
f80d50adbd PLT-7407: Back-end plugin mechanism (#7177)
* begin backend plugin wip

* flesh out rpcplugin. everything done except for minor supervisor stubs

* done with basic plugin infrastructure

* simplify tests

* remove unused test lines
2017-08-16 17:23:38 -05:00