On Tue June 16 2009 3:10:14 am Vijay Bansal wrote:
> One thing I forgot to mention is that  we cant write to a file by an app
> deployed on GAE.
> So I think  logging should be disabled as "CachedOutStream.java" seems to
> be flushing out the cache to a temp file on the local file system.
> So if I remove that operation of writing to file(as it is not allowed on
> GAE), as I suppose its just used for logging purposes, would it create any
> problems in turn  ?

It's not just used for logging.   It's used in a couple other places:

1) Attachment processing - normally, we can stream attachments in, but in some 
cases, we cannot.  In those cases, we need to cache the data.   The 
CachedOutStream is used to provide the cache so if the attachments are too 
large, they get dumped on disk rather than consume memory.   Example: someone 
sends a GB sized attachment.  Don't really want that in memory.

2) HTTP redirects/digest auth support - for those, we need to buffer the 
outgoing message.   Again, CachedOutStream is used so if the message is too 
large, memory is not consumed.

3) JMS Transport - same as HTTP

HOWEVER, on GAE, the maximum message size GAE allows in or out is 1MB (if I 
remember correctly).  Thus, the message sizes you'll see in all the above 
cases is reasonable enough that not dumping to files would likely be OK.   
Anyway, I'll look at your patch later today.

Dan



> Thanks
>
> On Mon, Jun 15, 2009 at 7:03 PM, Daniel Kulp <[email protected]> wrote:
> > On Mon June 15 2009 4:35:11 am Vijay Bansal wrote:
> > > Hi all
> > >
> > > I am trying to port CXF on GAE. GAE has several limitations though.
> > > Following are the issues in CXF not supported by GAE
> > >       JAXB
> > >       No Threads....everything has to be single threaded
> >
> > Normally, that would be the case.   Thus, for normal two way ops, it
> > should be
> > OK.   I'd work on getting the normal cases working first and then we can
> > figure out what to do about the others.  (On trunk, there IS  a flag that
> > can
> > set the endpoint to use the same thread for the one ways as well.   Not
> > in a
> > released version yet though)
> >
> > >       JAXWS, JAXRS..... I am interested in JAXRS only
> >
> > Well, I don't think JAX-RS would ever use the workqueue anyway.  They
> > don't have one-way ops.   Thus, it may not be an issue for you.
> >
> >
> > Actually, your last note to me made me think of something else that could
> > be
> > problematic.   For attachments (and message logging), we use a special
> > output
> > stream that once a threshold is reached (64K by default), it starts
> > saving to
> > temporary files on the file system.   There is a system property (and I
> > think
> > a config setting) to control that.   However, it would probably be good
> > to update the code and if "new FileOutputStream(...)" fails (or
> > createTempFile or
> > whatever), it would just proceed keeping it in memory.   Patches would be
> > welcome.   :-)
> >
> > Dan
> >
> > > I was able to support JAXB on GAE by modifying its sources.
> > > I see that CXF uses threads for work queue, probably for one way
> >
> > operation.
> >
> > > Is there any way to disable threads or make it all single threaded.
> > >
> > >
> > > Any pointers / Ideas
> > >
> > > Regards
> >
> > --
> > Daniel Kulp
> > [email protected]
> > http://www.dankulp.com/blog

-- 
Daniel Kulp
[email protected]
http://www.dankulp.com/blog

Reply via email to