Announcement Announcement Module
Collapse
No announcement yet.
outof memory issue Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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

    Comment


    • #17
      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.

      Comment


      • #18
        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.
        Last edited by Gary Russell; May 24th, 2010, 12:11 PM.

        Comment


        • #19
          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

          Comment


          • #20
            @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

            Comment


            • #21
              ok ill test it out when youve had a chance to add it to svn. The delay technique didnt work im pretty sure its because its on the recieve part the catch does not occur.. anyway i will wait and test again over the new implementation in case that just solves it

              keep up the good work

              Comment


              • #22
                OK; I just committed the change. It's in SVN and should be in tonight's nightly. Sorry for the delay, it was a little more involved than I thought it would be.

                I didn't update the documentation yet but, essentially, there is a new attribute 'close' on the inbound and outbound gateways and on the inbound adapters.

                When set to true, an outbound gateway will close the socket when the response is received; an inbound gateway will close the socket after it sends the response; on an inbound adapter it will close the socket after the inbound message has been received and before it is sent to its channel.

                Let us know if this solves your issue; thanks.

                Comment

                Working...
                X