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...

    2 answers

    1.  
      1
      0
      -1

      Hi,

      I have experienced some issues in our Production environment today that have highlighted the need for improved logging of errors and exceptions.

      I have started using GroovyLogger as logger, which has been helpful at a submission and service level. However, it lacks the global perspective.

      I'm trying to determine the best approach to balance logger records vs Event Log and or Error Log entries.

      So, the question is: what is the best approach for recording errors and exceptions?

      The options include GroovyLogger, EventLogService, ErrorLogService or a combination of the three.

      It appears that a combination may be best: use logger for recording service activity, and use EventLog or ErrorLog to record exceptions - is there any benefits of using one or the other?. I have also noticed some log entries for service use, so need to consider that in the mix as well.

      There is also RedirectException that is available as another option; this may be useful to display messages to the user, rather than simply throw an Exception that is logged, but not displayed to the user.

      Any recommendations would be appreciated.

      Thanks

      Mark

        CommentAdd your comment...
      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...