outof memory issue

[Mark Fisher]

Sorry, I didn't see anything related to the TCP adapter in your configuration, so I assumed you were rolling your own.

Marten is definitely right though. You don't want to create a new ApplicationContext at runtime.

[leeo]

Hi can you give me some pointers on how to do this ie how do i tell spring about my config file si-config.xml

also with injection do you mean annotate my controller with something like

@Autowired
private GatewayInterface gateway;

also i changed my GatewayInterface method adding
@Gateway(requestChannel = "input")

now in the code my gateway instance is always null

[Marten Deinum]

The same way you tell it to load the xml file which contains your controller (or the component-scan to detect your controller).

[leeo]

Im now using the component scan and @autowire to inject this value into my controller and i have the desired behaviour. However my requirement is that i need a new Socket for each request i send. The current implementation works fine for the first request but on subsequent requests it attempts to use the same instance of Socket to send the second request. If there a way to force the socket to get recreated or should i be looking at creating a new instance of the SimpleTcpNetOutboundGateway for each request. Given that performance is an issue what would be the best approach.

[Gary Russell]

This should work if the remote end closes the socket after sending the reply. However, it does not work due to a defect in the code.

Please create an 'INT' JIRA issue at http://jira.springframework.org.

I will try to get a fix into tonight's nightly build.

Thanks for finding this issue.

[leeo]

ok ive made the issue

http://jira.springframework.org/browse/INT-1145

i will be interested to see how you implement this as the issue has made me look more at the framework side of the code

[Gary Russell]

The fix is in the trunk.

You can see the changes here...

https://fisheye.springsource.org/cha...ation/?cs=3202

Thanks, again, for finding this.

[Gary Russell]

Note that the fix still requires an attempt to write, catching the exception and retrying. I have created a JIRA subtask (http://jira.springframework.org/browse/INT-1146) to add an option to the gateway to always use a new Socket for each request.

Also, in very high volume situations, it would still be possible to successfully write to a socket that is in the process of being closed. I will therefore make INT-1146 a priority.

[leeo]

cheers for that Gary.

right my current situation is this.

im using custom reader and writer.

now my first request works, the second fails, the third works.

it appears that my second request write does not complain and i get a recv on the second read. This happens in my assembleDataCustomFormat() method. So from what i can see the AbstractTcpSendingMessageHandler.java fix is fine if the error is on sending but there is a different class dealing with the recieve.

like i say the 3rd request works so it leaves me in a good state but does not auto try with another socket


becaues i know i always need a new socket the option to create this each time will solve this but thought it might be good to have a full failover.

The problem could still be in my implementation just thought id let you know where im at.

Cheers

[Gary Russell]

@leeeo

Sorry for the delay, I was travelling today - the good news is it gave me time to start the patch, the bad news is I won't be able to get it in to tonight's nightly build.

The problem you're seeing is because it takes the FIN (close) some time to propagate from the server back to the client.

As a work around, if you could put a small delay between sends, you should be good. I will get the proper fix in the next day or so.

I have reopened your JIRA issue.

Gary