On Mon August 17 2009 3:39:57 pm Nepali, Sonam (GE Healthcare, consultant) wrote: > In CXF 2.1.3 version, the CachedOutputStream does not delete the > temporary files that were created. This leads to proliferation of > temporary files residing in the file systems. Wouldn't it be better if > the temporary files created during LoggingInInterceptor and the > LoggingOutInterceptor be deleted after being done with the message? Is > there a project plan for this deletion of temporary files in CXF created > in LoggingInInterceptor and LoggingOutInterceptor?
If it doesn't delete them, it's due to close() not being called properly. All I can suggest is to upgrade to a recent version of CXF. I know some issues with the file deletion not working was fixed in 2.1.5. Dan > > My other solution is to grab the source and modify the Interceptor > myself. > > thanks > > Sonam > > > -----Original Message----- > From: Daniel Kulp [mailto:dk...@apache.org] > Sent: Friday, August 14, 2009 2:06 PM > To: users@cxf.apache.org > Cc: Nepali, Sonam (GE Healthcare, consultant) > Subject: Re: CachedOutputStream writing to temp files for large messages > > On Thu August 13 2009 6:26:06 pm Nepali, Sonam (GE Healthcare, > consultant) > > wrote: > > Hello > > > > What is the difference in that CachedOutputStream.java writes the > > large messages to the file versus for smaller size messages that are > > less than > > (64 * 1024) bytes? If I set a > > "org.apache.cxf.io.CachedOutputStream.Threshold" property to about 5 > > MBs, will that potentially have any negatice impact on performance? > > The two areas it impacts are: > > 1) By allocating larger objects and holding them in memory, it reduces > the > number of concurrent requests that can be processed. For example, if > you > set your jvm max memory to -Mx256M or so, you obviously can have less > than 50 > requests outstanding (actually much less due to overhead itself and > such). > With 64K max before going to disk, many more requests can be in flight. > > 2) Garbage collection - lots of small allocations are generally better > for the > garbage collector. If the message takes a while to process, it may get > moved > from the short lived space to the middle aged space (or even the old gen > > space). Each of those would require a copy. Large allocations tend > to > force the gc to run more often as well. > > Neither are really a huge deal though if you know what the > characteristics of your interactions are. > > Dan > > > Basically, I want to get around the problem for the CachedOutputStream > > > > from creating temp files for large messages. > > > > thanks > > > > > > Sonam > > > > CXF user > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
