You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by nicolas de loof <ni...@apache.org> on 2009/02/23 11:42:45 UTC
What is a "large" SOAP message ?
Hi
my current project uses CXF as WS stack to expose services. One of them
requires many inputs so the XSD becomes really huge.
Could you please tell me what is considered to be a "large" SOAP message ?
I've found some benchmark comparison of stacks (I don't really care, I like
CXF) and other best practices about XML message weight (
http://www.redbooks.ibm.com/redpapers/pdfs/redp4344.pdf)<http://www.redbooks.ibm.com/redpapers/pdfs/redp4344.pdf>
but
no size in bytes of a "really too big" SOAP message.
Cheers,
Nicolas
Re: What is a "large" SOAP message ?
Posted by Daniel Kulp <dk...@apache.org>.
I know internal to IONA/Progress, last year sometime we had one of our
customers testing with Messages around 400MB without attachments, even larger
with attachments.
Without attachments, you'll need to give the VM quite a bit of memory. We do
stream, but you still need to hold the whole JAXB model for that in memory.
With attachments, you can get by with MUCH lower memory usage as the large
attachments would get buffered into temp files on disk.
That said, I'm not sure I'd recommend that as the "best design" for most
cases, but in many cases, it's unavoidable and it's good to know it works.
Dan
On Mon February 23 2009 5:42:45 am nicolas de loof wrote:
> Hi
> my current project uses CXF as WS stack to expose services. One of them
> requires many inputs so the XSD becomes really huge.
>
> Could you please tell me what is considered to be a "large" SOAP message ?
> I've found some benchmark comparison of stacks (I don't really care, I like
> CXF) and other best practices about XML message weight (
> http://www.redbooks.ibm.com/redpapers/pdfs/redp4344.pdf)<http://www.redbook
>s.ibm.com/redpapers/pdfs/redp4344.pdf> but
> no size in bytes of a "really too big" SOAP message.
>
> Cheers,
> Nicolas
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: What is a "large" SOAP message ?
Posted by Stefan Hackmann <dh...@alice-dsl.net>.
Hi,
I sent 50 MB response messages in sync communication
without attachments ;-)
Cheers,
Stefan
Andrew Clegg schrieb:
> 2009/2/23 nicolas de loof <ni...@apache.org>:
>
>
>> Could you please tell me what is considered to be a "large" SOAP message ?
>> I've found some benchmark comparison of stacks (I don't really care, I like
>> CXF) and other best practices about XML message weight (
>> http://www.redbooks.ibm.com/redpapers/pdfs/redp4344.pdf)<http://www.redbooks.ibm.com/redpapers/pdfs/redp4344.pdf>
>> but
>> no size in bytes of a "really too big" SOAP message.
>>
>
> I've sent and received messages of up to about 12-13MB successfully
> with CXF -- purely XML, no attachments.
>
> I'm guessing that's at the upper end of the size spectrum (not
> counting MTOM etc.). I used Provider services and Dispatch clients, so
> no databinding -- the XSD for these services is actually pretty simple
> (mainly just long lists) which made parsing/generating them myself
> seem like the better idea.
>
> Andrew.
>
>
Re: What is a "large" SOAP message ?
Posted by Andrew Clegg <an...@nervechannel.com>.
2009/2/23 nicolas de loof <ni...@apache.org>:
> Could you please tell me what is considered to be a "large" SOAP message ?
> I've found some benchmark comparison of stacks (I don't really care, I like
> CXF) and other best practices about XML message weight (
> http://www.redbooks.ibm.com/redpapers/pdfs/redp4344.pdf)<http://www.redbooks.ibm.com/redpapers/pdfs/redp4344.pdf>
> but
> no size in bytes of a "really too big" SOAP message.
I've sent and received messages of up to about 12-13MB successfully
with CXF -- purely XML, no attachments.
I'm guessing that's at the upper end of the size spectrum (not
counting MTOM etc.). I used Provider services and Dispatch clients, so
no databinding -- the XSD for these services is actually pretty simple
(mainly just long lists) which made parsing/generating them myself
seem like the better idea.
Andrew.
--
:: http://biotext.org.uk/ ::