Announcement Announcement Module
No announcement yet.
Does Spring Integration provide any out-of-box solution to capture execution time ? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Does Spring Integration provide any out-of-box solution to capture execution time ?


    I've a simple requirement to capture my application's overall execution time for a use case so that I can judge the performance of my app.

    The use case is a below:

    Client makes a REST request. The request is recvd by a POJO that in-turn places the request on the Spring Integration's Gateway.
    From hereon, the request is processed by various external and internal components that are invoked using <chain> elements.
    While to few external components, invoke is asynchronous (via JMS), for others it is synchronous (via REST).
    However at the end, handle comes back to Gateway's default-reply-channel.

    I need to know that when the handle comes back to the Gateway's default-reply-channel, is there a way to know what was the total time taken by the request to get processed (i.e., starting from the time it was put on Gateway until the time response was recvd on Gateway's default-reply-channel) ?

    I know that I can handle it through code but just need to know if Spring Integration can provide an out-of-box solution.

    Many thanks & Best Regards

  • #2
    If you use only DirectChannels (no queue channels or executor channels), you can enable JMX and use the sendDuration property of the initial request channel's metrics. It's an exponential moving average though; if you want to capture the response time of each individual request you'll have to do it in the POJO that calls the gateway.

    Spring provides a convenient StopWatch class for this purpose.


    • #3
      Thanks for responding, Gary.

      Do you think it could be a good proposition to have this feature provided in upcoming version (if any) of Spring Integration framework ?
      Will that not be a "nice" feature to provide user with an attribute at "Gateway" level (or for that matter even at "chain" level) using which user can ask the framework to calculate the time elapsed between when a message was put on it and when the response was recvd on its "output-channel"/"reply-channel" ?



      • #4
        Do you mean keep an average? Or do you mean some mechanism to get the time for each and every request?

        Feel free to put your ideas, in some detail, in a JIRA 'New Feature' issue; even better - consider contributing!!


        • #5
          Sure, will do.

          I meant some mechanism to get the time for each and "every" request that is put on the Gateway (i.e., the elapsed time when the request was placed on Gateway and when a response was recvd on its reply-channel).

          Best Regards


          • #6
            The problem is that the gateway "encourages" the use of POJIs and the client does not know it's calling a messaging system.

            It's difficult to do what you want as a separate call on the gateway. The statistics really need to be returned with the reply.

            If the client doesn't mind "knowing" about SI, I suppose you could declare a gateway service-interface thus...

            Message<?> getReply(String foo)
            and have the gateway optionally populate a header on the message with the stats.


            • #7
              I thought of that but problem with "my" use case is, in the overall execution chain, few external components have to be invoked asynchronously (via JMS).
              I'm thinking of trying to achieve this through wire-tap interceptor.
              I just read about this interceptor in reference doc but not clear on one point (though an attempt has been made in the reference doc to clarify the point specifically):
              I understand that wire-tap can route the "same" message over two different channels (i.e., the main channel - say Channel A which is part of main thread; and side channel - say Channel B) and the processing of message over Channel B will be sync/async depending on what is the "type" of channel B.
              I want my Channel B to process the message in async manner but I'm not clear what type of Channel I should define it (Pollable, Subscriable, etc...bit confused on their functionality). Can you pls suggest what should be the channel type for Channel B based on the details mentioned above ?


              • #8
                It doesn't matter if some components are sync and some are async because your're using a gateway (request/response) so eventually everything syncs up anyway.


                • #9
                  Ok. Regarding wire-tap can you pls suggest on the Channel type I should be using ?


                  • #10
                    You probably shouldn't be using a wire tap for that kind of thing.

                    A publish-subscribe channel with a task executor is generally better. However, if this is in your gateway scenario you'll need some mechanism to "join" the two results (such as an aggregator).