1
0
-1

Hi,

I am seeing some unexpected behaviour for some of our exception handling and wonder about the architecture of Groovy services in TM. This is related to legacy code, but I'm interested to know if the same solution would be required for Fluent services.

I have three services that call each other in a chain sequence, svcA calls svcB which calls svcC.

However, if svcC throws an exception, it does not seem to get passed to svcB, or in turn passed to svcA.

Does each groovy service run in it's own thread?

if so, how can I handle the exceptions such that they are passed back through the chain to to originating service?

In this scenario of chained services can I use the Groovy exception handling or do I need another approach?

Two options that may be possible (from my research so far) are:

  • catch the exception and pass an error (or result, or message) object back to the calling service
  • use the Future concept and handle the result of the future call

The service chain above needs to work synchronously; svcA should not continue until it gets a result from svcB, and svcB should not continue until it gets a result from svcC.

Any guidance would be appreciated.

Thanks 

    CommentAdd your comment...

    1 answer

    1.  
      1
      0
      -1

      Hi Murry,

      Can you specify how the Groovy service execution timeouts (Service Parameter) are defined with your services. If you have a non zero execution timeout configured, the service will be executed in a separate thread.  The originating exception will generally be wrapped in another exception passed to the calling service.

      As a general principle you should only configure execution timeouts for background processes (e.g. Delivery Process) which run in the Transaction Processor to prevent them from stalling the delivery of other transactions. The Transaction Processor job is essentially single threaded.

      With regard to form services (dynamic data, form prefill, save processor, submission completed etc), these should not be configured with an execution timeout, as it does not generally help with availability and does consume more resources.

      regards Malcolm

      1. Mark Murray

        Hi Malcolm,

        the services are as follows:

        svcA

        • Submission Preprocessor
        • connectTimeout - no parameter set

        svcB

        • Groovy Service
        • connectTimeout - no parameter set

        svcC

        • Groovy Service
        • connectTimeout = 50000

        svcC calls our backend system using http; this service uses an http client which has a readTimeout = 50000.

        So, it seems that it is not necessary to have the two settings. For this service it seems that it is enough to have the http readTimout only.

         

        There are two scenarios that I need to cover:

        • business errors
        • Exceptions

        If I set the connectTimeout = 0 for svcC as you mention, that should cover the exception handling, because all three scripts will run as one thread, so exceptions should be passed through the chain appropriately.

        In that case when a business error occurs is it best to throw an exception, as this will be handled by the scripts. That seems like the most elegant solution as it means I can handle both business errors and also system/code errors using the 'Exception' handling mechanism.

        Thanks

        Mark

      CommentAdd your comment...