Announcement Announcement Module
No announcement yet.
Most strange issue observed after defining "error-channel" at Gateway Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Something in the instantiation of your bean is causing early creation of other beans...

    2013-07-08 09:11:02,115 DEBUG [localhost-startStop-1] istableBeanFactory - Creating instance of bean ' ptors.MsgMetaDataValidationInterceptor#0'
    2013-07-08 09:11:02,115 DEBUG [localhost-startStop-1] org.springframework.beans.factory.annotation.Injec tionMetadata - Registered injected element on class [ tors.MsgMetaDataValidationInterceptor]: AutowiredFieldElement for private mers.JSONToObjectTransformer tors.MsgMetaDataValidationInterceptor.json2ObjTran sformer
    2013-07-08 09:11:02,130 DEBUG [localhost-startStop-1] org.springframework.beans.factory.annotation.Injec tionMetadata - Processing injected method of bean ' ptors.MsgMetaDataValidationInterceptor#0': AutowiredFieldElement for private mers.JSONToObjectTransformer tors.MsgMetaDataValidationInterceptor.json2ObjTran sformer
    2013-07-08 09:11:02,130 DEBUG [localhost-startStop-1] istableBeanFactory - Creating shared instance of singleton bean 'reportServicesDS'
    2013-07-08 09:11:02,177 INFO [localhost-startStop-1] icationContext - Bean 'onlineReqRcvExceptionHandlerChannel' of type [class nel] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
    2013-07-08 09:11:02,990 DEBUG [localhost-startStop-1] istableBeanFactory - Finished creating instance of bean ' or.GlobalChannelInterceptorWrapper#1'

    You can open a JIRA issue, but I am just saying that there may not be anything we can do to solve it, aside from suggesting you use a different configuration strategy (such as the one I suggested above).

    I'll answer your other question in a different post; it's hard enough to track two issues in the same thread; having the discussion on both issues in the same post makes it harder.


    • #17
      Aync Gateway

      1. Yes. The gateway will run the flow on another thread; returning immediately with a Future which the original thread can later query - but you said you didn't need the reply.
      2. No. If you don't need a reply, just return void and use an ExecutorChannel to immediately hand off to another thread.
      3. Yes, you don't have to call return.get(), but there's no point in doing that; just return a void; it will avoid creating the Future object for no purpose.
      4. Yes; when you've done "other work" on this thread, the get() will block until the result arrives - or you can call result.get(timeout, TimeUnit.SECONDS)) (and catch a TimeoutException).
      5. If the downstream flow does not return a result, the async thread will be "stuck", indefinitely waiting for a reply that will never arrive. This won't affect the calling code, but it will cause a memory leak. You can avoid it by setting the reply-timeout (or default-reply-timeout) to 0; in which case the async thread will not wait for a reply.

      However, it's much simpler to return void and use an ExecutorChannel as the first channel from the gateway.


      • #18
        Ok, now I understand.

        I think the Async Gateway feature best fits for those use cases where you want to "delegate" a part of business logic to another thread for some time and meanwhile carry out some other business logic in the main thread and then take the control back after the child thread has finished execution. Correct ?

        For my use case, as you said, I agree executor channel is the best option.

        However, don't you think it would have been a nice feature to provide end user a functionality by Async Gateway where the entire downstream processing would take place in a separate thread other than the invoked thread and that the invoked thread not waiting for any response.
        In other words, if the framework would have supported a return type of Future<void> or some similar syntax then it would have been great. Seeing the Future as return type would had indicated framework that the downstream on this gateway method should be invoked as part of separate thread and seeing the <void> would have indicated framework that it should not expect any response on its default reply channel.

        I know that I'm sounding contradictory by saying that method has a return type of Future and other point I'm saying that gateway should not expect a response on its reply channel but what I mean is to have some syntax (some keyword) similar to a Future<void> to provide this functionality. Underlying implementation of this functionality could have been abstracted by framework as suggested by you in point 5 above so that the end user need not have to do it at his end.

        Do you agree ?

        Best Regards
        Last edited by lbvirgo; Jul 9th, 2013, 01:39 PM.


        • #19
          Yes; your understanding is correct; that's the best fit for an async gateway.

          I do understand your concern about the (apparent) lack of consistency with regard to async and void return types.

          The main issue is that the only signal to the framework that this gateway is to be async is the Future<?> return type. This is very intuitive to users already familiar with the Future type.

          The language doesn't permit Future<void>; it does support Future<Void> where Void is a special type but it's still not really "right" because Void cannot be instantiated so the return value is a container for something that cannot be instantiated. And, in any case, it wouldn't work because java type erasure means the Void is not available to us at runtime to make the determination.

          One option might be to say that a method that returns "Void" (capital V) means an async void method (since Void can never be instantiated), but that doesn't smell right either.

          So, in order to provide the functionality you want, I think we'd be forced to make it an xml configuration option (on the <gateway/> or its <method/>s).

          I suppose another option might be a new attribute on the @Gateway annotation (async=true).

          In either case, we'd have to add validation to ensure only methods returning a Future or void can be async.

          Feel free to open a new feature JIRA issue or, even better, consider contributing a solution!