[ https://forge.continuent.org/jira/browse/SEQUOIA-963?page=comments#action_14191 ]
Tommi Takkunen-Lauri commented on SEQUOIA-963: ---------------------------------------------- This feature has been documented and will be publsihed in the next release. > Add RequestInterceptor feature to allow easy addition of logic to monitor and > transform requests > ------------------------------------------------------------------------------------------------ > > Key: SEQUOIA-963 > URL: https://forge.continuent.org/jira/browse/SEQUOIA-963 > Project: Sequoia > Type: New Feature > Components: Core > Versions: Sequoia 2.9 > Environment: All > Reporter: Robert Hodges > Assignee: Tommi Takkunen-Lauri > Priority: Critical > Fix For: sequoia 2.10.10 > > Original Estimate: 1 week > Remaining: 1 week > > It is a common requirement to want to add additional logic that can piggyback > on top of requests in order to monitor or transform them. Here are some > examples: > 1.) Checking for SQL that is forbidden by a particular application. > 2.) Performing transformation on SQL such as adding comments to make it > easier to implement replication strategies between clusters. > 3.) Logging interesting information about requests. > To enable these types of applications I plan to add a new feature called a > RequestInterceptor, which is a specialized interface that is invoked within > VirtualDatabaseWorker threads immediate prior to submitting SQL to the VDB > for execution. The RequestInterceptor is invoked and will receive the > Request as well as some additional information like the VDB object. The > RequestInterceptor can examine the request, make well-defined changes, and > perform functions like logging or monitoring as desired. > The implementation will be approximately as follows. > 1.) The RequestInterceptor interface will have a method that is invoke for > each request. Implementations can perform arbitrary processing in this > method. Multiple RequestInterceptors can be added in which case the > processing methods are invoked in succession. > 2.) Request data will be passed in using interfaces that wrap the underlying > AbstractRequest object. The interfaces will expose only a limited amount of > information and prevent unfortunate transformations that might cause further > processing to fail. There may be additional information passed in such as > the VDB and an abstraction of information in the VirtualDatabaseWorkerThread > (i.e., the closest thing we have to a session). > 3.) There will be a mechanism to configure zero or more RequestInterceptors > for each controller and define parameters for each RequestInterceptor > implementation. This may require an additional configuration file. > 4.) There will be a well-defined lifecycle for RequestInterceptor instances > in which they are initialized with configuration data, invoked zero or more > times, and shut down at controller termination. > 5.) The data structures associated with the RequestInterceptor will be > largely free of dependencies on other Sequoia packages and will be easy to > unit test outside the controller. > This mechanism will apply to request on the way in to the VDB only. Later on > it may make sense to enlarge the feature to permit RequestInterceptors to > generate errors or their own result sets. > Comments and suggestions are welcome. I hope this will turn out to be a > useful feature for Sequoia users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://forge.continuent.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
