No "send-timeout" attribute in <int:resequencer> when placed in <int:chain> [INT-2578]

[spring-operator]

Shawn Guo opened INT-2578 and commented

As described in Docs 2.1.1.RELEASE/2.2.0.M1, there are a "send-timeout" attribute in int:resequencer which used to config the timeout for sending out messages.

but when place int:resequencer inside int:chain, the org.xml.sax.SAXParseException happens:
cvc-complex-type.3.2.2: Attribute 'send-timeout' is not allowed to appear in element 'int:resequencer'.
at com.sun.org.apache.xerces.internal.util.ErrorHandl erWrapper.createSAXParseException(ErrorHandlerWrap per.java:195)

I also check the xsd files in http://www.springframework.org/schem...ration-2.1.xsd, it seems there are no attribute named "send-timeout".

---

Affects: 2.1.1

Reference URL: http://forum.springsource.org/showthread.php?126650-quot-send-timeout-quot-attribute-in-lt-int-resequencer-gt

[spring-operator]

Artem Bilan commented

I think this is not a bug, but it maybe correct issue. There are a lot of elements which can be placed inside a <chain>, however some their attributes is lost, but they are apropriate within chain too.
Right now: what is a problem do not to use "send-timeout" attribute for <resequencer> or <aggregator> inside the <chain>?
MessageHandlerChain sets for all MessageProducers 'nextChannel' in-line MessageChannel implementetation which has this enforce:

public boolean send(Message<?> message, long timeout) {
	return this.send(message);
}

So, in current logic any 'send-timeout' is ignored.

If I'm right I can go ahead and fix it for all elements which can be used inside the <chain> and when it is make sence.

[spring-operator]

Oleg Zhurakousky commented

Artem, I am assigning this to you. Feel free to re-assign if need to.

[spring-operator]

Artem Bilan commented

I've investigated more and here is my conclusions:

1. In-line channels of chained handlers work like DirectChannel
2. This type of channels ignores 'timeout' and invokes next handler at the same Thread, similar:

method1();
method2();
...
methodN();

3. This behavior is guaranteed in the flow of processing the message as quickly as possible.
4. 'timeout' makes sance only on like-queue channels, when it is necessary to block send-thread to avoid exceeding allowable capacity.

So, I've found this issue as 'Won't fix' and maybe we should think about some WARN in the AbstractSubscribableChannel#doSend(..), when 'timeout' parameter > -1.
Also maybe there is a sence to add some global description into Manual about 'send-timeout'('request-timeout' etc.) attribute logic. Or just refactor XSD documentation on this attribute during entire project and add note about <chain>.
Two words to comlete:
The logic about 'send-timeout' is correct.