Announcement Announcement Module
Collapse
No announcement yet.
How can I specify an error-channel after a hand-off to an async Task-Executor. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How can I specify an error-channel after a hand-off to an async Task-Executor.

    Here is my case:

    At some point in my main flow I Wire-Tap my message for asynchronous monitoring/logging.

    Code:
    ...
     <int:wire-tap channel="dispatchRequestChannel" pattern="externalRequestChannel" />
    ...
     <int:channel id="dispatchRequestChannel">
     	<int:dispatcher task-executor="asynchronousExecutor"/>
     </int:channel>
    ...
    <int:chain input-channel="dispatchRequestChannel">
    	<int:header-enricher>
    		<int:error-channel value="logErrorChannel"/>
    	</int:header-enricher>
    	<int:filter expression="headers.get('serviceId') == 'TimerDispositionForLot'"/>
    	<int:service-activator ref="messageHandler" method="extractRequest" />
    	<int:service-activator ref="monitoringService" method="monitorRequest"/>
    </int:chain>
    ...
     <int:channel id="logErrorChannel"/>
    <int:logging-channel-adapter channel="logErrorChannel" level="DEBUG" auto-startup="true" log-full-message="true" />
    When I inspect the header at the messageHandler-->extractRequest point in time , the reply-channel is still the same as the error-channel. This is because of the direct nature of this flow the error-channel is bounded to the caller's thread, or something like this...
    I would have thought the "header-enricher" would have permit me to define a error-channel anyhow?
    By the way, i'm using s-i version 2.1.2.

  • #2
    Add overwrite="true" to the header (error-channel) element (or default-overwite="true" on the header-enricher element).

    By default, existing headers are not overwritten.

    Comment


    • #3
      Thanks Gary, this worked fine. I didn't try it at first because my IDE (Rational Software Development [Eclipse base]) suggested the default value was true.



      I look over the .xsd file but it doesn't seem to come from there.
      Thanks anyhow.

      Comment


      • #4
        Interesting; that seems to be a side-effect of delcaring the type thus:

        Code:
        			<xsd:simpleType>
        				<xsd:union memberTypes="xsd:boolean xsd:string" />
        			</xsd:simpleType>
        The IDE (in my opinion) is incorrectly taking the first value of the boolean enumeration as the "default".

        I just tried adding a new attribute, which confirmed this.

        We should probably set an explicit default="false" to avoid this misleading eclipse behavior, or at least mention the default in the schema documentation. Feel free to open up a 'Documentation' JIRA.

        Comment

        Working...
        X