You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by ext2 <xu...@tongtech.com> on 2011/04/25 05:16:42 UTC
could cxf save larget attachemnt in temporary file?
Hi:
Sometimes, web service (both service and client) need to receive
very large attachment.
1) does cxf support save large attachment in temporary file for
service to receive request , and client to receive response?
2)how could I configure the temporary directory and threshold?
Re: could cxf save larget attachemnt in temporary file?(A new doubt)
Posted by ext2 <xu...@tongtech.com>.
It's great.
Thanks Daniel Kulp. Thank you very much;
> -----original -----
>Sender: Daniel Kulp [mailto:dkulp@apache.org]
>Date: 2010/4/28 2:25
> Receiver: users@cxf.apache.org
> Subject: Re: could cxf save larget attachemnt in temporary file?(A new
doubt)
>
> On Tuesday, April 26, 2011 11:40:06 PM ext2 wrote:
> > Thanks Daniel Kulp for your explain.
> >
> > Because CXF maintain the attachments stream underlying, now I feel
doubt
> > about how could I cleaning the temporary file.
> >
> > There are two use case, as following:
> >
> > 1) at server side, receiving request with large attachment.
> > Could CXF engine clean the temporary files automatically, just after the
> > service send response?
>
> Well, yes and no. When STREAMING attachments into the service, when the
> stream is closed, the attachment file gets deleted. Thus, if you are
seeing
> a bunch of stuff left on disk, it's likely that your code isn't properly
> closing the input streams.
>
>
> > 2) at client side, receiving response with large attachment.
> > Now the CXF Engine cannot automatically clean temporary files, only the
> > user know the time when to clean.
>
> Same as above. The inputstreams we provide to the datahandler/datasource
> things override the close() method to track things and will remove the
temp
> files automatically.
>
> > Because the CXF may buffer the last attachment's stream to disk
> > automatically, the user may unaware of this conversion.
> > So does CXF providing some method(API),which I could use to clean the
> > temporary attachment file safely?
>
> Just close the inputstreams. Note: this is ALSO important for the non-
> buffered attachments (like the last one) as the call to close will let us
know
> to close the underlying HTTP input stream and the URL connect can be
returned
> to the keep-alive pool and such.
>
> Dan
>
>
>
> >
> > Thanks any suggestion;
> >
> >
> > -----Original -----
> > Sender: Daniel Kulp [mailto:dkulp@apache.org]
> > Date: 2011/4/26 10:35
> > Sender: users@cxf.apache.or
> > Subject: Re: could cxf save larget attachemnt in temporary file?
> >
> >
> > What Freeman describes below isn't the FULL story. Normally, even with
a
> > single large attachment, nothing would be written to disk. Whenever
> > possible, CXF tries to stream things directly. In the case of a single
> > attachment, or the last attachment when using multiple attachments, CXF
can
> > stream directly and thus it wouldn't normally create the files on disk.
> >
> > However, when any of the cases that force the attachment to be fully
> > realized
> > occurs and breaks the streaming, it would automatically buffer them into
> > the
> >
> > files on disk like Freeman describes.
> >
> > Dan
> >
> > On Sunday 24 April 2011 11:36:01 PM Freeman Fang wrote:
> > > Hi,
> > >
> > > My comment inline
> > >
> > > On 2011-4-25, at 上午11:16, ext2 wrote:
> > > > Hi:
> > > > Sometimes, web service (both service and client) need to
receive
> > > >
> > > > very large attachment.
> > > >
> > > > 1) does cxf support save large attachment in temporary file
for
> > > >
> > > > service to receive request , and client to receive response?
> > >
> > > Yeah,
> > > When cxf message exceed a threshold(64 k by default), it will save the
> > > memory message to temp file on hard disk(by default it save to the
> > > folder specified by a pre-set well-known java system properties
> > > java.io.tempdir + cxf-temp-random ).
> > >
> > > > 2)how could I configure the temporary directory and
threshold?
> > >
> > > You can specify the threshold with property
> > > org.apache.cxf.io.CachedOutputStream.Threshold (64k by default) t
> > > and specify the cxf temp dir for big size message with property
> > > org.apache.cxf.io.CachedOutputStream.OutputDirectory
> > > to a folder you have full acesss permission.
> > > Freeman
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------
> > > Freeman Fang
> > >
> > > FuseSource
> > > Email:ffang@fusesource.com
> > > Web: fusesource.com
> > > Twitter: freemanfang
> > > Blog: http://freemanfang.blogspot.com
> > > Connect at CamelOne May 24-26
> > > The Open Source Integration Conference
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: could cxf save larget attachemnt in temporary file?(A new doubt)
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, April 26, 2011 11:40:06 PM ext2 wrote:
> Thanks Daniel Kulp for your explain.
>
> Because CXF maintain the attachments stream underlying, now I feel doubt
> about how could I cleaning the temporary file.
>
> There are two use case, as following:
>
> 1) at server side, receiving request with large attachment.
> Could CXF engine clean the temporary files automatically, just after the
> service send response?
Well, yes and no. When STREAMING attachments into the service, when the
stream is closed, the attachment file gets deleted. Thus, if you are seeing
a bunch of stuff left on disk, it's likely that your code isn't properly
closing the input streams.
> 2) at client side, receiving response with large attachment.
> Now the CXF Engine cannot automatically clean temporary files, only the
> user know the time when to clean.
Same as above. The inputstreams we provide to the datahandler/datasource
things override the close() method to track things and will remove the temp
files automatically.
> Because the CXF may buffer the last attachment's stream to disk
> automatically, the user may unaware of this conversion.
> So does CXF providing some method(API),which I could use to clean the
> temporary attachment file safely?
Just close the inputstreams. Note: this is ALSO important for the non-
buffered attachments (like the last one) as the call to close will let us know
to close the underlying HTTP input stream and the URL connect can be returned
to the keep-alive pool and such.
Dan
>
> Thanks any suggestion;
>
>
> -----Original -----
> Sender: Daniel Kulp [mailto:dkulp@apache.org]
> Date: 2011/4/26 10:35
> Sender: users@cxf.apache.or
> Subject: Re: could cxf save larget attachemnt in temporary file?
>
>
> What Freeman describes below isn't the FULL story. Normally, even with a
> single large attachment, nothing would be written to disk. Whenever
> possible, CXF tries to stream things directly. In the case of a single
> attachment, or the last attachment when using multiple attachments, CXF can
> stream directly and thus it wouldn't normally create the files on disk.
>
> However, when any of the cases that force the attachment to be fully
> realized
> occurs and breaks the streaming, it would automatically buffer them into
> the
>
> files on disk like Freeman describes.
>
> Dan
>
> On Sunday 24 April 2011 11:36:01 PM Freeman Fang wrote:
> > Hi,
> >
> > My comment inline
> >
> > On 2011-4-25, at 上午11:16, ext2 wrote:
> > > Hi:
> > > Sometimes, web service (both service and client) need to receive
> > >
> > > very large attachment.
> > >
> > > 1) does cxf support save large attachment in temporary file for
> > >
> > > service to receive request , and client to receive response?
> >
> > Yeah,
> > When cxf message exceed a threshold(64 k by default), it will save the
> > memory message to temp file on hard disk(by default it save to the
> > folder specified by a pre-set well-known java system properties
> > java.io.tempdir + cxf-temp-random ).
> >
> > > 2)how could I configure the temporary directory and threshold?
> >
> > You can specify the threshold with property
> > org.apache.cxf.io.CachedOutputStream.Threshold (64k by default) t
> > and specify the cxf temp dir for big size message with property
> > org.apache.cxf.io.CachedOutputStream.OutputDirectory
> > to a folder you have full acesss permission.
> > Freeman
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------
> > Freeman Fang
> >
> > FuseSource
> > Email:ffang@fusesource.com
> > Web: fusesource.com
> > Twitter: freemanfang
> > Blog: http://freemanfang.blogspot.com
> > Connect at CamelOne May 24-26
> > The Open Source Integration Conference
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: could cxf save larget attachemnt in temporary file?(A new doubt)
Posted by ext2 <xu...@tongtech.com>.
Thanks Daniel Kulp for your explain.
Because CXF maintain the attachments stream underlying, now I feel doubt
about how could I cleaning the temporary file.
There are two use case, as following:
1) at server side, receiving request with large attachment.
Could CXF engine clean the temporary files automatically, just after the
service send response?
2) at client side, receiving response with large attachment.
Now the CXF Engine cannot automatically clean temporary files, only the user
know the time when to clean.
Because the CXF may buffer the last attachment's stream to disk
automatically, the user may unaware of this conversion.
So does CXF providing some method(API),which I could use to clean the
temporary attachment file safely?
Thanks any suggestion;
-----Original -----
Sender: Daniel Kulp [mailto:dkulp@apache.org]
Date: 2011/4/26 10:35
Sender: users@cxf.apache.or
Subject: Re: could cxf save larget attachemnt in temporary file?
What Freeman describes below isn't the FULL story. Normally, even with a
single large attachment, nothing would be written to disk. Whenever
possible, CXF tries to stream things directly. In the case of a single
attachment, or the last attachment when using multiple attachments, CXF can
stream directly and thus it wouldn't normally create the files on disk.
However, when any of the cases that force the attachment to be fully
realized
occurs and breaks the streaming, it would automatically buffer them into the
files on disk like Freeman describes.
Dan
On Sunday 24 April 2011 11:36:01 PM Freeman Fang wrote:
> Hi,
>
> My comment inline
>
> On 2011-4-25, at 上午11:16, ext2 wrote:
> > Hi:
> > Sometimes, web service (both service and client) need to receive
> > very large attachment.
> >
> > 1) does cxf support save large attachment in temporary file for
> >
> > service to receive request , and client to receive response?
>
> Yeah,
> When cxf message exceed a threshold(64 k by default), it will save the
> memory message to temp file on hard disk(by default it save to the
> folder specified by a pre-set well-known java system properties
> java.io.tempdir + cxf-temp-random ).
>
> > 2)how could I configure the temporary directory and threshold?
>
> You can specify the threshold with property
> org.apache.cxf.io.CachedOutputStream.Threshold (64k by default) t
> and specify the cxf temp dir for big size message with property
> org.apache.cxf.io.CachedOutputStream.OutputDirectory
> to a folder you have full acesss permission.
> Freeman
>
>
>
>
>
>
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> Connect at CamelOne May 24-26
> The Open Source Integration Conference
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: could cxf save larget attachemnt in temporary file?
Posted by Daniel Kulp <dk...@apache.org>.
What Freeman describes below isn't the FULL story. Normally, even with a
single large attachment, nothing would be written to disk. Whenever
possible, CXF tries to stream things directly. In the case of a single
attachment, or the last attachment when using multiple attachments, CXF can
stream directly and thus it wouldn't normally create the files on disk.
However, when any of the cases that force the attachment to be fully realized
occurs and breaks the streaming, it would automatically buffer them into the
files on disk like Freeman describes.
Dan
On Sunday 24 April 2011 11:36:01 PM Freeman Fang wrote:
> Hi,
>
> My comment inline
>
> On 2011-4-25, at 上午11:16, ext2 wrote:
> > Hi:
> > Sometimes, web service (both service and client) need to receive
> > very large attachment.
> >
> > 1) does cxf support save large attachment in temporary file for
> >
> > service to receive request , and client to receive response?
>
> Yeah,
> When cxf message exceed a threshold(64 k by default), it will save the
> memory message to temp file on hard disk(by default it save to the
> folder specified by a pre-set well-known java system properties
> java.io.tempdir + cxf-temp-random ).
>
> > 2)how could I configure the temporary directory and threshold?
>
> You can specify the threshold with property
> org.apache.cxf.io.CachedOutputStream.Threshold (64k by default) t
> and specify the cxf temp dir for big size message with property
> org.apache.cxf.io.CachedOutputStream.OutputDirectory
> to a folder you have full acesss permission.
> Freeman
>
>
>
>
>
>
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> Connect at CamelOne May 24-26
> The Open Source Integration Conference
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: could cxf save larget attachemnt in temporary file?
Posted by ext2 <xu...@tongtech.com>.
Thanks a lot
----original -----
Sender: Freeman Fang [mailto:freeman.fang@gmail.com]
Date: 2011/4/25 11:36
Receiver: users@cxf.apache.org
Subject: Re: could cxf save larget attachemnt in temporary file?
Hi,
My comment inline
On 2011-4-25, at 上午11:16, ext2 wrote:
>
> Hi:
> Sometimes, web service (both service and client) need to receive
> very large attachment.
> 1) does cxf support save large attachment in temporary file for
> service to receive request , and client to receive response?
Yeah,
When cxf message exceed a threshold(64 k by default), it will save the
memory message to temp file on hard disk(by default it save to the
folder specified by a pre-set well-known java system properties
java.io.tempdir + cxf-temp-random ).
> 2)how could I configure the temporary directory and threshold?
You can specify the threshold with property
org.apache.cxf.io.CachedOutputStream.Threshold (64k by default) t
and specify the cxf temp dir for big size message with property
org.apache.cxf.io.CachedOutputStream.OutputDirectory
to a folder you have full acesss permission.
Freeman
>
>
>
>
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
Re: could cxf save larget attachemnt in temporary file?
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
My comment inline
On 2011-4-25, at 上午11:16, ext2 wrote:
>
> Hi:
> Sometimes, web service (both service and client) need to receive
> very large attachment.
> 1) does cxf support save large attachment in temporary file for
> service to receive request , and client to receive response?
Yeah,
When cxf message exceed a threshold(64 k by default), it will save the
memory message to temp file on hard disk(by default it save to the
folder specified by a pre-set well-known java system properties
java.io.tempdir + cxf-temp-random ).
> 2)how could I configure the temporary directory and threshold?
You can specify the threshold with property
org.apache.cxf.io.CachedOutputStream.Threshold (64k by default) t
and specify the cxf temp dir for big size message with property
org.apache.cxf.io.CachedOutputStream.OutputDirectory
to a folder you have full acesss permission.
Freeman
>
>
>
>
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
Re: how generate DataHandler instead of byte[] for SWA attachment?
Posted by Daniel Kulp <dk...@apache.org>.
I think you need a jaxws binding file:
<bindings
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
wsdlLocation="swa-mime.wsdl"
xmlns="http://java.sun.com/xml/ns/jaxws">
<bindings node="wsdl:definitions">
<enableMIMEContent>true</enableMIMEContent>
</bindings>
</bindings>
Dan
On Thursday, May 05, 2011 1:01:21 AM ext2 wrote:
> Hi:
> I am try to write a client to invoke any existing SWA webservice;
> But the generated JAX-WS interface always using byte[] instead of
> DataHandler for the attachment?
> how could I configure cxf to using DataHandler instead of byte[]?
>
> Thanks any suggestion;
>
> Following is a simplified wsdl to illustrate the problem;
> <types>
> <xs:element name="sayHi" type="tns:sayHi"/>
> <xs:element name="sayHiResponse" type="tns:sayHiResponse"/>
> <xs:element name="attachment1" type="xs:base64Binary"/>
> <xs:element name="attachment2" type="xs:base64Binary"/>
> <types>
>
> <wsdl:message name="sayHi">
> <wsdl:part element="tns:sayHi" name="parameters"/>
> <wsdl:part element="tns:attachment1" name="attachment1"/>
> <wsdl:part element="tns:attachment2" name="attachment2"/>
> </wsdl:message>
>
> <wsdl:input name="sayHi">
> <mime:multipartRelated>
> <mime:part>
> <soap:body parts="parameters" use="literal"/>
> </mime:part>
> <mime:part>
> <mime:content part="attachment1"
> type="application/octet-stream"/>
> </mime:part>
> <mime:part>
> <mime:content part="attachment2"
> type="application/octet-stream"/>
> </mime:part>
> </mime:multipartRelated>
> </wsdl:input>
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: MTOM Attament Cleaning Problems / Bugs ?
Posted by Willem Jiang <wi...@gmail.com>.
On 5/6/11 11:42 AM, ext2 wrote:
> 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;
I'm not sure about what's the incorrect environment?
Did you mean using Camel?
If so, that could a bug of Camel.
>
> 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.:(
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com
Re: MTOM Attament Cleaning Problems / Bugs ?
Posted by ext2 <xu...@tongtech.com>.
Thanks Daniel:
I have create two issue relate such problem:
https://issues.apache.org/jira/browse/CXF-3504: for big attachment, a
temporary file is left on disk and keep opend, if the application just close
the DataSource's inputStream and doesn't consume it;
https://issues.apache.org/jira/browse/CXF-3505: CXF attachment doesn't
compatible with SUN's ACTIVATION library
> -----original -----
>Daniel Kulp [mailto:dkulp@apache.org] 2011/5/7 2:48
>
>
> That's quite interesting analysis. I would definitely consider this a
bug
> as
> we SHOULD also be able to work with the Sun version. I'm not sure what
the
> "fix" is yet. My THOUGHT would be in the LazyDataSource.load method
would
> do:
> for (Attachment a : attachments) {
> if (a.getId().equals(id)) {
> this.dataSource = a.getDataHandler().getDataSource();
> break;
> } else {
> //do something to force a load if applicable to make
> //sure the later attachments work
> }
> }
>
> Having a test case would be a huge help though.
>
> Dan
>
>
>
> On Friday, May 06, 2011 2:05:11 AM ext2 wrote:
> > 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) 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(not last one) ,
cannot
> > be pre-cached; then 2 problem will occurs: 1) cannot release
> > http-connection 2)if user-application doesn't consume the inputstream,
> > just it. A temporary file will be left on disk and keep open;
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
Re: MTOM Attament Cleaning Problems / Bugs ?
Posted by Daniel Kulp <dk...@apache.org>.
That's quite interesting analysis. I would definitely consider this a bug as
we SHOULD also be able to work with the Sun version. I'm not sure what the
"fix" is yet. My THOUGHT would be in the LazyDataSource.load method would
do:
for (Attachment a : attachments) {
if (a.getId().equals(id)) {
this.dataSource = a.getDataHandler().getDataSource();
break;
} else {
//do something to force a load if applicable to make
//sure the later attachments work
}
}
Having a test case would be a huge help though.
Dan
On Friday, May 06, 2011 2:05:11 AM ext2 wrote:
> 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) 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(not last one) , cannot
> be pre-cached; then 2 problem will occurs: 1) cannot release
> http-connection 2)if user-application doesn't consume the inputstream,
> just it. A temporary file will be left on disk and keep open;
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: MTOM Attament Cleaning Problems / Bugs ?
Posted by ext2 <xu...@tongtech.com>.
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) 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(not last one) , cannot
be pre-cached; then 2 problem will occurs: 1) cannot release http-connection
2)if user-application doesn't consume the inputstream, just 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
>
Re: MTOM Attament Cleaning Problems / Bugs ?
Posted by ext2 <xu...@tongtech.com>.
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
Re: MTOM Attament Cleaning Problems / Bugs ?
Posted by Daniel Kulp <dk...@apache.org>.
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
Re: MTOM Attament Cleaning Problems / Bugs ?
Posted by ext2 <xu...@tongtech.com>.
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
> -----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();
> }
>
>
>
MTOM Attament Cleaning Problems / Bugs ?
Posted by ext2 <xu...@tongtech.com>.
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();
}
how generate DataHandler instead of byte[] for SWA attachment?
Posted by ext2 <xu...@tongtech.com>.
Hi:
I am try to write a client to invoke any existing SWA webservice;
But the generated JAX-WS interface always using byte[] instead of
DataHandler for the attachment?
how could I configure cxf to using DataHandler instead of byte[]?
Thanks any suggestion;
Following is a simplified wsdl to illustrate the problem;
<types>
<xs:element name="sayHi" type="tns:sayHi"/>
<xs:element name="sayHiResponse" type="tns:sayHiResponse"/>
<xs:element name="attachment1" type="xs:base64Binary"/>
<xs:element name="attachment2" type="xs:base64Binary"/>
<types>
<wsdl:message name="sayHi">
<wsdl:part element="tns:sayHi" name="parameters"/>
<wsdl:part element="tns:attachment1" name="attachment1"/>
<wsdl:part element="tns:attachment2" name="attachment2"/>
</wsdl:message>
<wsdl:input name="sayHi">
<mime:multipartRelated>
<mime:part>
<soap:body parts="parameters" use="literal"/>
</mime:part>
<mime:part>
<mime:content part="attachment1"
type="application/octet-stream"/>
</mime:part>
<mime:part>
<mime:content part="attachment2"
type="application/octet-stream"/>
</mime:part>
</mime:multipartRelated>
</wsdl:input>