Announcement Announcement Module
Collapse
No announcement yet.
reply-channel for tcp-inbound-gateway Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Never mind... I've reproduced it; the read event is fired to tell us to read the EOS; we need to suppress the error when it's expected, like in this case.

    It's already suppressed when using-nio="false" so if you can use that mode you can avoid the error log.

    Can you create a JIRA issue to suppress the ERROR on an expected CLOSE when using=nio="true"?

    Thanks.

    Comment


    • #32
      I tried the following scenarios

      1) using-nio="false" on both side
      2) single-use="true" with using-nio="true" on the server connection factory

      seems the error is gone for both cases. Looks like I have to specify single-use="true" on the server side as well. But I kind of remember the reference said the single-use="true" does not mean too much on the server side. Anyway, glad the error is gone now and really appreciate your help.

      BTW, I am still in the prototype phase to evaluate Spring integration and my goal is to build a message bus with SI. I am familiar with BEA ESB server and like its inbound and outbound flow concept (seems Mule just added the flow concept). There is a learning curve of SI for me because of the different concepts.

      I also wonder why SI does not provide a JMS message store such as ActiveMQ message store. Seems I need to implement one by myself.

      My another idea is to use hazelcast (a distributed cache system) to implement a distributed publish and subscribe channel, queue, and perhaps message store as well so that the message bus can support clustering. Anything pitfalls I should pay attention to if I implement them?

      Thanks again,

      John

      Comment


      • #33
        Originally posted by Gary Russell View Post
        Never mind... I've reproduced it; the read event is fired to tell us to read the EOS; we need to suppress the error when it's expected, like in this case.

        It's already suppressed when using-nio="false" so if you can use that mode you can avoid the error log.

        Can you create a JIRA issue to suppress the ERROR on an expected CLOSE when using=nio="true"?
        Sure. I will do that.

        Thanks,

        John

        Comment


        • #34
          The JIRA is here:

          https://jira.springsource.org/browse/INT-1797

          Thanks,

          John

          Comment


          • #35
            I did a load test and seems the single-use="true" on the server side did not really fix the problem. Some times, no errors, but some times I still see the following errors.

            ERROR - Exception on Read localhost.localdomain:40238:586744119 null

            ERROR - Exception on Read localhost.localdomain:40329:1585803366 Channel closed
            Is this only an error log and does it affect the message channel behavior? I mean, will the exception be actually thrown in the process?

            I switch back not to use nio now until the problem has been fixed.

            Thanks,

            John

            Comment


            • #36
              Yes, it's just noise in the log; it doesn't affect functionality.

              Whether you get 'null' or 'channel closed' is purely timing.

              Sorry for the inconvenience.

              Comment

              Working...
              X