You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Vijay Bansal <vi...@gmail.com> on 2009/06/15 10:35:11 UTC
CXF support on GAE
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
JAXWS, JAXRS..... I am interested in JAXRS only
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
--
Vijay Bansal
Undergraduate Junior
Dept. of Computer Science and Engineering
International Institute of Information Technology
Mob No. - 9966655745
Re: CXF support on GAE
Posted by Daniel Kulp <dk...@apache.org>.
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 <dk...@apache.org> 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
> > dkulp@apache.org
> > http://www.dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: CXF support on GAE
Posted by Vijay Bansal <vi...@gmail.com>.
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 ?
Thanks
On Mon, Jun 15, 2009 at 7:03 PM, Daniel Kulp <dk...@apache.org> 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
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
Vijay Bansal
Undergraduate Junior
Dept. of Computer Science and Engineering
International Institute of Information Technology
Mob No. - 9966655745
Re: CXF support on GAE
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://www.dankulp.com/blog