|
From: Ladislav U. <lad...@we...> - 2006-06-28 23:45:24
|
Hi David,
we have not tried bigger payloads than 30MB. If you have several
messages about this size I would consider to look on tomcat settings and
check if tomcat (java container, OS) tries to swap.
The reason is I have not seen any size limit that would cause additional
serialization. Are there such?
Ladislav
On Wed, 2006-06-28 at 10:03 -0700, David RR Webber (XML) wrote:
> Ladislav,
>
> Supplemental question - you mentioned sending 25Mb payloads with
> Hermes 1 - have you tried bigger payloads - say 50MB?
>
> Appears somewhere around 25MB is the threshold where we start to see
> issues - so I'd be interested to know if you have tried bigger
> payloads?
>
> Thanks, DW
>
>
>
> -------- Original Message --------
> Subject: Re: Re-visiting on Hermes 1 performance
> From: Ladislav Urban <lad...@we...>
> Date: Fri, June 23, 2006 8:24 pm
> To: "David RR Webber (XML)" <da...@dr...>
> Cc: Ashique Tanveer <tan...@od...>, Sacha Schlegel
> <sa...@sc...>, Patrick Yee <kc...@ce...>
>
> Hi David,
> I have some questions about the problem.
>
> Firstly, How long does take when you run Send method with
> large payload
> on given registered application context?
>
>
> The code in hermes is here
>
> try {
> responseCode = connection.getResponseCode();
> responseMessage = connection.getResponseMessage();
> } catch (IOException ioe) {
> throw new RequestException(ioe.getMessage());
> }
>
>
>
> Do you have performance problems during receiving large
> messages? Do you
> use encryption and DSigs?
>
> Could you please send me code lines from msh.jar that cause
> the slow?
> Is it inside EbxmlMessage.java
>
> public void writeTo(
> OutputStream out,
> String soapEncoding,
> String payloadEncoding)
> throws IOException, SOAPException {
> // we now keep the SOAP message object away from attachment to
> avoid
> // it to load the payload to memory, therefore we are doing
> our own
> // writeTo() here
> // soapMessage.writeTo(out);
> serialize(out, soapEncoding, payloadEncoding, false);
> }
>
> As you can see they use custom method
>
> private long serialize(
> OutputStream out,
> String soapEncoding,
> String payloadEncoding,
> boolean getLengthOnly)
>
> to prevent keeping large payloads in memory
>
> Instead JAXM's SOAPMessage.writeTo
>
>
>
> On Thu, 2006-06-22 at 07:04 -0700, David RR Webber (XML)
> wrote:
> > Ladislav,
> >
> > OK - here's the saga so far. We thought that replacing the
> JAXM and
> > SAAJ libraries with the very latest ones would resolve the
> issue with
> > large payloads.
> >
> > After spending two days setting up and swapping out those
> libraries -
> > it made no difference.
> >
> > So now we're thinking that the issue is in how Hermes itself
> is
> > packaging the payload and using JAXM calls.
> >
> > Because with Hermes 2 this is not an issue - and in Hermes 2
> the JAXM
> > is not present - we're thinking the solution is to re-factor
> the
> > Hermes 1 code to use SAAJ directly - just like Hermes 2 is
> doing.
> >
> > My understanding is that JAXM serializes the payload first -
> instead
> > of direct streaming from memory - and over course if the
> payload is
> > bigger than the magic 10MB threshold - it does this via disk
> i/o and
> > hence it runs 100 times slower! All this came about I
> believe
> > because of the need to support SMTP delivery - but frankly -
> that is
> > now history.
> >
> > So - can you give any insights? Have you examined the code
> at this
> > depth - and is there a simple way to change Hermes 1 to use
> SAAJ
> > directly?
> >
> > All ideas / code fragments - et al gratefully received!
> >
> > Thanks, DW
> --
> Ladislav Urban
> CEO
> Webswell Inc.
> 1333 Howe Avenue, Suite 100
> Sacramento, 95825 CA
> email: lad...@we...
> phone: +1 (916) 290-2040
> fax: +1 (916) 921-2850
> http://www.webswell.com
--
Ladislav Urban
CEO
Webswell Inc.
1333 Howe Avenue, Suite 100
Sacramento, 95825 CA
email: lad...@we...
phone: +1 (916) 290-2040
fax: +1 (916) 921-2850
http://www.webswell.com
|