CXF
  1. CXF
  2. CXF-3505

CXF attachment doesn't compatible with SUN's ACTIVATION library

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4.1, 2.3.5
    • Component/s: None
    • Labels:
      None

      Description

      if using sun's javax.activation api (version 1.1) instead of geronimo's activation api. CXF's attachments . the http connection cannot be released corrrectly;

        Activity

        Hide
        ext2 added a comment -

        1)attachment is a POM project for testing this problem; the test app is
        SunActivationClientAttachmentRelease.java

        2) while I cannot give a simple assertion for such a test to check system socket's status; but the test program has such special points:
        2.1) the client will invoke the server continuously; and the KEEP-ALIVE options is disabled;
        2.2) if using geronimo's activation , we will find many "TIME_WAITING" status socket at server side; it's correctly, because "TIME_WAITING" is inevitable status according to tcp-ip protocol;
        2.3) if using sun's activation, we will find some "FIN_WAIT2" status socket at server side, and "CLOSE_WAITING" status at client side. this is not correctly and indicate that the server socket is closed but client socket hasn't;

        Show
        ext2 added a comment - 1)attachment is a POM project for testing this problem; the test app is SunActivationClientAttachmentRelease.java 2) while I cannot give a simple assertion for such a test to check system socket's status; but the test program has such special points: 2.1) the client will invoke the server continuously; and the KEEP-ALIVE options is disabled; 2.2) if using geronimo's activation , we will find many "TIME_WAITING" status socket at server side; it's correctly, because "TIME_WAITING" is inevitable status according to tcp-ip protocol; 2.3) if using sun's activation, we will find some "FIN_WAIT2" status socket at server side, and "CLOSE_WAITING" status at client side. this is not correctly and indicate that the server socket is closed but client socket hasn't;
        Hide
        ext2 added a comment -

        the problem is somewhat releate the javax.acivation.DataHandler's implement; check the difference of two activation library:

        Geronimo's :
        public DataHandler(DataSource ds)

        { this.ds = ds; this.flavor = new ActivationDataFlavor(ds.getContentType(), null); }


        // getContentType() of CXF's LazyDataSource will en-force it to be loaded; then: attachments(not last one) will cached, and the last attachment still keep delegate to network stream;

        Sun's:
        public DataHandler(DataSource ds)

        { // save a reference to the incoming DS dataSource = ds; oldFactory = factory; // keep track of the factory }

        //doesn't call any method of LazyDataSource, so it cannot enforce the CXF's LazyDataSource to Load; so the attachments are not cached; Then 2 problem will occurs: 1) cannot release http-connection 2)if user-application doesn't consume the inputstream, just close it. A temporary file will be left on disk and keep open;

        Show
        ext2 added a comment - the problem is somewhat releate the javax.acivation.DataHandler's implement; check the difference of two activation library: Geronimo's : public DataHandler(DataSource ds) { this.ds = ds; this.flavor = new ActivationDataFlavor(ds.getContentType(), null); } // getContentType() of CXF's LazyDataSource will en-force it to be loaded; then: attachments(not last one) will cached, and the last attachment still keep delegate to network stream; Sun's: public DataHandler(DataSource ds) { // save a reference to the incoming DS dataSource = ds; oldFactory = factory; // keep track of the factory } //doesn't call any method of LazyDataSource, so it cannot enforce the CXF's LazyDataSource to Load; so the attachments are not cached; Then 2 problem will occurs: 1) cannot release http-connection 2)if user-application doesn't consume the inputstream, just close it. A temporary file will be left on disk and keep open;
        Hide
        Freeman Fang added a comment -

        Hi,

        Thanks for the testcase, I believe you're using JDK5,right? I can see this difference when I switch back to use JDK5, as with JDK6, by default it will always use SUN built-in activation lib unless we endorse it, so with JDK6 this problem is more severe, as you'll always see this bug.

        Yeah,using SUN activation lib can cause your conclusion 1)cannot release http-connection.
        But your conclusion 2)if user-application doesn't consume the inputstream, just close it. A temporary file will be left on disk and keep open(which I believe tracked by another jira CXF-3504) has nothing to do with this issue, it's actually caused by a bug in org.apache.cxf.attachment.MimeBodyPartInputStream, after close MimeBodyPartInputStream, shouldn't be able to read it, which isn't the case currently.

        Freeman

        Show
        Freeman Fang added a comment - Hi, Thanks for the testcase, I believe you're using JDK5,right? I can see this difference when I switch back to use JDK5, as with JDK6, by default it will always use SUN built-in activation lib unless we endorse it, so with JDK6 this problem is more severe, as you'll always see this bug. Yeah,using SUN activation lib can cause your conclusion 1)cannot release http-connection. But your conclusion 2)if user-application doesn't consume the inputstream, just close it. A temporary file will be left on disk and keep open(which I believe tracked by another jira CXF-3504 ) has nothing to do with this issue, it's actually caused by a bug in org.apache.cxf.attachment.MimeBodyPartInputStream, after close MimeBodyPartInputStream, shouldn't be able to read it, which isn't the case currently. Freeman
        Show
        Freeman Fang added a comment - commit fix http://svn.apache.org/viewvc?rev=1104697&view=rev for trunk http://svn.apache.org/viewvc?rev=1124152&view=rev for 2.3.x branch

          People

          • Assignee:
            Freeman Fang
            Reporter:
            ext2
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development