cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ext2" <x...@tongtech.com>
Subject Re: MTOM Attament Cleaning Problems / Bugs ?
Date Fri, 06 May 2011 06:10:01 GMT

Hi:
This problem is caused by javax.activation library;
The failure project using javax.activation/activation/1.1. while the correct
project using org.apache.geronimo.specs/geronimo-activation_1.1_spec/ 1.1;

For illustrate the problem more clearly, 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;

> -----original-----
> ext2 [mailto:xuhb@tongtech.com]	 2011/5/6 11:43
> 
> Hi Daniel:
> 
> I think the problem is some what concern with my project's environment;
> 
> 1) At first the test is running in a test project which not only
dependency
> cxf and spring, also dependency on other librarys(etc camel) for other
> testing purpose. Then the problem  occurs;
> 
> 2) but if I create a more simple project which only dependency on cxf and
> spring, and running the test in this project, every thing is ok;
> 
> 3) Because I have no idea about which cause the difference, the Client's
> TestCase's code are exactly same; But when I debugging my program , I find
> that:
> 
> 3.1) when running in un-correct environment, when client return the
> response, all the attachments are not cached, (using the java debugger, I
> see the   DataHandler 's LazyDataSource are not loaded) so the
> DataSource().getInputStream() always return a DelegateInputStream(), then
> ...all things is wrong;
> 
> 3.2) But when running in the correct environment, only the last
attachment's
> DataSource is not loaded, the other are already loaded, so only the last
> datasource's inputStream is DelegateInputStream, the others 's inputStream
> is Cached; then everything is ok;
> 
> I thinks the 3.2) case is correctly, because it works just like you have
> told me; But I have no any ideas about  why  3.1)  all attachment  are not
> loaded. :(
> 
> 
> > ----original -----
> >Sender: Daniel Kulp [mailto:dkulp@apache.org]
> >Date: 2011-5-6 0:58
> > Sender: users@cxf.apache.org
> > CC: ext2
> > Subject: Re: MTOM Attament Cleaning Problems / Bugs ?
> >
> > On Thursday, May 05, 2011 12:53:41 PM ext2 wrote:
> > > By the way, if the attachment is bigger than 64K. the temporary file
of
> > > first attachment will be left on disk and keep open until the web
> service
> > > client's jvm exit;
> > >
> > > The CXF version is 2.3.3
> >
> > Can you try with 2.3.4 just to make sure (I'm not expecting much of a
> change,
> > but it may fix it)?
> >
> > If it's still an issue, is there anyway to create a "hello world" type
> test
> > case for it and attach to a JIRA?
> >
> > Dan
> >
> >
> > >
> > > > -----original-----
> > > > Sender: ext2 [mailto:xuhb@tongtech.com]
> > > > Time: 2011/5/6 0:00
> > > > Receiver: users@cxf.apache.org
> > > > Subject: MTOM Attament Cleaning Problems / Bugs ?
> > > >
> > > > Hi:
> > > > When webservice client receiving the MTOM reponse(which  have more
> than
> > >
> > > one
> > >
> > > > attachments), the client cannot release Http-Connection correctly;
> > > >
> > > > In my program all DataHandler's input stream have been consumed and
> > > > closed correctly; but the http-connection still cannot be released
> > > > correctly;
> > > >
> > > > the import thing is : if we only have one attachment, the
> http-connection
> > > > can be released correctly. But more than one attachments, cannot
> release
> > > > http-connection correctly;
> > > >
> > > >
> > > > Following is a simple example for illustrate the wsdl and clients:
> > > > MTOM Reponse Schema:
> > > > <complexType name="DataHandlerType2">
> > > >
> > > >  <sequence>
> > > >
> > > >   <element name="nameR" type="xsd:string" />
> > > >   <element name="attachinfoR1" type="xsd:base64Binary"
> > > >
> > > > xmime:expectedContentTypes="application/octet-stream"/>
> > > > <element name="attachinfoR2" type="xsd:base64Binary"
> > > > xmime:expectedContentTypes="application/octet-stream"/>
> > > > </sequence>
> > > > </complexType>
> > > >
> > > >
> > > > Program is :
> > > >
> > > > ...do webservice invoke and got the reply
> > > > is = reply.getAttachinfoR1().getDataSource().getInputStream();
> > > > readClose(is);
> > > > is = reply.getAttachinfoR2().getDataSource().getInputStream();
> > > > readClose(is);
> > > >
> > > > private void readClose(InputStream is) throws IOException {
> > > >
> > > > 	while(is.read() != -1)
> > > >
> > > >         	;
> > > >
> > > >     is.close();
> > > >
> > > > }
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
> 




Mime
View raw message