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
Assigned to: Robert Hodges
Priority: Critical
Fix For: Sequoia 2.9
It is a common requirement to want to add additional logic that can piggyback
on top of requests in order to monitor 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.
--
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
