GatewayProxyFactoryBean losts messages

[fsancho]

Hi
I'm using M6 and i am experiencing problems with a messaging Gateway. It sometimes lost two or three messages under some heavy load (100 - 200 threads launched with 10 ms of delay).

Here is my Gateway Definition

<gateway id="sendAsync" service-interface="org.sescam.cisos.higeia.integration.pipeline.IIntegrationPort" 
        request-channel="requestChannel" 
        reply-channel="replyChannel"
        message-creator="asyncCreator"
    />

I have installed interceptors in replyChannel and all the messages are successfully inserted in replyChannel (postSend shows the message, and sent is true), and postReceive shows the message too, but in some place between the Gateway reads the message and sends it to my Object the message is lost because it gets a null message (i belive because timeout expires, but giving more timeout doesn't solve the problem).

Sometimes it works ok and no messages are lost, but sometimes it lost one or two. This is not an acceptable behavior.

[fsancho]

I have been looking into Spring Integration Source code and i guess that the problem might be in RetrievalBlockingMessageStore (used as messagestore by ReplyMessageCorrelator, which is used by SimpleMessagingGateway ). The method remove doesn't seem to be thread safe.

	public Message<?> remove(Object key, long timeout) {
		Message<?> message = this.targetMessageStore.remove(key);
		return (message != null) ? message : waitForMessage(key, timeout, true);
	}

this.targetMessageStore is a SimpleMessageStore and it isn't synchronized.

EDIT: Forget this message, I was wrong. The problem might be in waitForMessage

[Mark Fisher]

I think that you are experiencing the same issue that was recently submitted to JIRA: http://jira.springframework.org/browse/INT-361

I'm working on some additional concurrency tests here, but it doesn't appear to be a synchronization issue in the message store.

Do you need an explicit reply channel? If not, then a possible quick solution would be to rely upon the (much simpler) default temporary reply channel. That would be enabled by leaving out the "reply-channel" on the gateway element and also avoiding "output-channel" on the final component of your message flow (so that it falls back to the 'returnAddress' on the Message - which in this case would be a temporary reply channel).

If you are able to make those changes, then you can also set a "reply-timeout" on the gateway element, and it would behave as expected. Hopefully that will work in the mean time, and you can keep an eye on the JIRA issue. Then, once the timeout is correctly applied for reply Message correlation, you can check if the increased timeout resolves your issue.

Regards,
Mark

[Mark Fisher]

After some more investigation, I did find a concurrency issue in the waitForReply method. I am testing the fix now. Can you please add an issue in JIRA?

thanks,
Mark

[Mark Fisher]

Actually, I take that back... what I was looking at is not an issue after all (waitForReply does use synchronization for accessing the listeners map). I will continue to try to reproduce the problem. If you could possibly provide a failing test case, that would be extremely helpful.

Thanks,
Mark

[Mark Fisher]

I've added an issue for this in JIRA: http://jira.springframework.org/browse/INT-366

It should be resolved shortly.