Hi Naoki, This is one of few undocumented product features of PredictionIO. We basically had a need to put in custom functionalities in both event server and engine server deployments that do not necessary needs to be compiled into code. The reason is that each plugin adds processing time and latency. Sorry for the lack of documentation. Very impressive that you got all these information correct. :) I'll add more context to it.
Event server input blockers: When these plugins are present, events coming into event server will be passed through all loaded and active plugins before reaching the actual event store. The order of processing is not defined, so events can go through these plugins in arbitrary order. One use case is for validating input data and throw exceptions to prevent bad data from going in. These plugins cannot transform the event. Event server input sniffers: When these are present, events will be broadcasted to these plugins in parallel. They do not block the event from reaching event store. They are useful for logging, statistics, and forwarding to other processing systems. Engine server output blockers: Before predictions go out, they will be processed through all loaded and active plugins. The order of processing is not defined. They are useful for transforming prediction results (e.g. if you do not have access to engine source code). Engine server output sniffers: These should have similar benefits with event server sniffers, but is not currently implemented. You are correct that the start() method is not used, and probably should not be in the base trait. If we find this system useful, we should spend some time tidying up the design and document it. Thanks again for digging this up! Regards, Donald On Mon, Jun 19, 2017 at 6:40 PM, Naoki Takezoe <take...@gmail.com> wrote: > Hi all, > > I found the plug-in system in the event server and the engine server. > It accepts following types of plug-ins: > > - event server > - inputBlocker > - inputSniffer > - engine server > - outputBlocker > - outputSniffer > > It seems useful to validate input events or process predicted values, > but I feel that the design and implementation is somewhat strange. For > example, since plugin.start() seems to be never called I can't > understand why this method is defined in plugin traits. > > However I can't find any documentation or example about them, so I may > not understand the purpose of each plugin type correctly. > > Could anyone help me? > > Regards, > > -- > Naoki Takezoe >
