Announcement Announcement Module
Collapse
No announcement yet.
SI chain does not return response (Soap UI) sometimes due to Task executor Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • SI chain does not return response (Soap UI) sometimes due to Task executor

    I have the following chain setup:

    Inbound Gateway > Primary Channel (with dispatcher task-executor) > ... (splitters, routers etc..) > Aggregator > Response Channel.

    We are testing using SOAP UI.
    Before the task-executor was added, we would consistently get the responses.
    Since it was added, we do not get responses in the following cases:
    1. Initial request. When first request is fired, it starts up hibernate session and slows down for a few seconds. Results in 0 byte response. It does not wait for all the processing to complete.
    2. A debugging point was added in one of the chain components. Results in 0 byte response.

    This does not seem to be an issue when executing the tests programmatically. Is this a particular quirk with SOAP UI?
    As soon as I remove the task-executor, it works consistently. Task executor is in place to support multiple requests being handled simultaneously. Please let me know why this is happening.

    Thanks.

  • #2
    With async processing downstream, the gateway only waits 1 second, by default, for the reply.

    You can increase this with the reply-timeout attribute (milliseconds).

    Comment


    • #3
      However, with a web (WS) based gateway, you really don't need to go async because each request will come in on a web container thread - the concurrency is managed by the web container.

      Comment


      • #4
        Hi!

        You shold understand, that introducing task-executor to your message flow breaks it to several threads, so your hibernate session won't be avaliable within those threads - it is thread-scoped proxy by nature.
        Nevertheless, can you show your config here? Minimize it, please, to localize the issue and show.

        Take care,
        Artem

        Comment


        • #5
          Originally posted by Gary Russell View Post
          With async processing downstream, the gateway only waits 1 second, by default, for the reply.
          You can increase this with the reply-timeout attribute (milliseconds).
          This is very useful to know!
          Originally posted by Gary Russell View Post
          However, with a web (WS) based gateway, you really don't need to go async because each request will come in on a web container thread - the concurrency is managed by the web container.
          Alright, I just tried this again and it is indeed working as described. I think my initial test for this was faulty, I did not actually notice that it is a separate thread for each request I sent. That's what I expected from the get go, but my test mislead me. In any case this was not a waste of time, it is alright, as I got an introduction to task-executor, which we might need to use for parallel processing of request contents in the future.
          Thanks.

          Originally posted by Cleric View Post
          Hi!

          You shold understand, that introducing task-executor to your message flow breaks it to several threads, so your hibernate session won't be avaliable within those threads - it is thread-scoped proxy by nature.
          Nevertheless, can you show your config here? Minimize it, please, to localize the issue and show.

          Take care,
          Artem
          I understand about breaking messages into threads, that's what I wanted to achieve, but since the app container manages it for me, then I can skip on task-executor for this use case.
          Thanks.

          Comment

          Working...
          X