[overlord-issues] [JBoss JIRA] (RTGOV-519) Intercept activity from Vertx app interactions and report as activity events

[Gary Brown (JIRA)]

Gary Brown created RTGOV-519:
--------------------------------

             Summary: Intercept activity from Vertx app interactions and report as activity events
                 Key: RTGOV-519
                 URL: https://issues.jboss.org/browse/RTGOV-519
             Project: RTGov (Run Time Governance)
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Gary Brown
            Assignee: Gary Brown
             Fix For: 2.1.0.Final


Vertx has a simple core that is not going to be extended to support any form of intercept mechanism.

The current advice from the vertx team is to create a module that essentially acts as proxy to the real module being used. The problem with this approach is that it does not have any information about the client or service, which are required by rtgov.

Therefore the suggested approach will be to wrap the event bus api with an implementation that can be configured with information about the verticle in which it is being used. Then it can use that information when a message is being sent or received, to create activity events (e.g. request sent/received, response sent/received).

The other issue to consider is how to build ActivityUnits out of the various ActivityType events that may be associated with a business transaction instance. In some environments, the thread can be used to track and accumulate multiple activity events to the same unit. However this approach wouldn't work in Vertx.

One approach to be considered:

The activity events should be reported to an intermediate module responsible for accumulating events into a unit. If a response is expected, then when recording the request it should record the fact, so that the module building the activity unit can determine when invocation scopes have been completed, and therefore the activity unit submitted. (May be more complex than this, but possibly a starting point). The response handler would need to cache a 'replyTo' id that would enable it to submit response events to the same activity unit. This may be controlled on the client side (i.e. event bus proxy), as it may know when it has finished doing its work.

Worst case is that each verticle 'instance' would record its activity in a single activity unit - i.e. request received, and sent messages and received responses, before returning its reply.

Need to investigate whether vertx exposes any form of message ids between verticles - and if not, whether this is something they would consider adding. This would enable correlation of activity across verticles.




--
This message was sent by Atlassian JIRA
(v6.2.6#6264)