You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by Paul Marshall <pa...@jambit.com> on 2002/11/13 15:49:12 UTC
streaming out large xml documents to an rpc-based client
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
We have an rpc-based soapinterface to our system ( using apache - soap )
,that tries to return extremely large dataobjects.
Now we see,that these objects get so big, that we run out of memory
resulting in an OutOfMemoryException on an average soap - method
invocation.
Now the idea would be to somehow keep the clientinterface stable, but to
change the server-side as to commit parts of the response-xml ( in our
case there is an underlying
list structure ) into the response-stream.
This way we would not need to build up the entire response in memory (
as it currently stands with our huge java-object ) before piping it out
to the client.
This is important, as changing client-systems can result in quite some
cost.
Does apache soap support any such idea, or can we use some parts under
the hood ?
How big a job would you estimate this to be ?
Thanks,
Paul
- --
Kostenlose Stundenerfassung mit http://time.jambit.com
- ------------------------------------------------------
Dipl.Phys. Paul Marshall, Software Architect
jambit Software Development & Management GmbH
Sendlinger Strasse 24, D-80331 Muenchen
http://www.jambit.com
fon: +49.89.260 19 609
fax: +49.89.260 19 585
PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
PGP Keyserver: http://www.dfn-pca.de/pgpkserv
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE90mZoragPljgZBjMRAs3oAKCIJx/Myzg0yZ1bVcbAfx9DEpZVxwCdENHZ
xXm3Db7fEKWkKyQhhxaKHLU=
=vbjy
-----END PGP SIGNATURE-----
Re: streaming out large xml documents to an rpc-based client
Posted by Scott Nichol <sn...@scottnichol.com>.
Serializers do currently write to a stream. At issue, I believe, is the
fact that Apache SOAP *always* serializes the SOAP envelope into a
string, and then serializes that envelope and any attachments into a
byte array to send. The latter is done so that an HTTP Content-Length
header can be created. The former may just be done for no other reason
than that is how the code was originally written.
I have already started contemplating a change to the second step, namely
streaming the response with no Content-Length header. This is less of a
help on calls with large SOAP envelopes than calls with large
attachments (because, as I said, the SOAP envelopes would already be
serialized to Strings), but it would help a lot of people who are
basically transferring large documents as Strings, byte arrays or DOM
Elements, since those documents could be handled as attachments.
Unfortunately, folks that must interop with .NET would not benefit from
this, since .NET does not support the original SOAP Attachments spec
(which they co-authored), choosing to support DIME exclusively instead.
So, the handling of large payloads is definitely something we are
looking to improve.
If you are interested in exploring alternative technologies to alleviate
your problems, I highly recommend you consider Axis
(http://xml.apache.org/axis/), which may be better than Apache SOAP for
your application.
Scott Nichol
----- Original Message -----
From: "Paul Marshall" <pa...@jambit.com>
To: <so...@xml.apache.org>
Sent: Thursday, November 14, 2002 8:07 AM
Subject: Re: streaming out large xml documents to an rpc-based client
> Scott Nichol wrote:
> > Paul,
> >
> > Is the OutOfMemoryException occuring on the server? What is the
Java
> > data type of the object you are returning? Do you use one of the
> > supplied serializers, or a custom one?
> >
> > Scott Nichol
> >
>
> Hi Scott,
>
> Thanks for resoponding.
> I'me talking about a custom Class that is serialized/deserialized with
a
> custom serialzier ( both are part of a custom databinding framework ).
> The problem of the return object getting too big has currently only
> occured on the server. Once the server actually has enough memory to
> respond with the large object, the client might well also run into
> problems. That's a separate problem however.
>
> So the idea of writing xml to the servlet response stream would only
be
> valid to improve serverside efficiency.
> Some first ideas would involve having a way of declaring a method to
be
> "streaming", so that the SOAP Implementation stops to be responsible
for
> the serialization of the return object but instead passes some open
> stream ( perhaps not directly the servlet response stream ) to the
> implementing service. The service could then "manually" serialize
chunks
> of the inteded return object and print these into the stream, in stead
> of growing a large object in memory. The soap framework would just
> handle the envelop etc. and blend the surrounding envelop xml text
with
> the streaming body of the method return value into the servlet
response
> stream. A change to this "streaming" architecture would definitely
mean
> a lot of work, even if the soap implementation would support it out of
> the box, as the implementing classes are currently ejb's that can not
so
> easily take a stream as input argument...
>
> On my project however, we are still evaluating other options to deal
> with the problem, and so it's not sure yet, that we will try anything
of
> the likes.
>
>
> I will get in touch with Virender Sandhu ( who seams to have a
solution
> like this ) as soon as I get more time.
>
> Cheers
>
> Paul
>
>
>
>
> --
> Kostenlose Stundenerfassung mit http://time.jambit.com
> ------------------------------------------------------
> Dipl.Phys. Paul Marshall, Software Architect
>
> jambit Software Development & Management GmbH
> Sendlinger Strasse 24, D-80331 Muenchen
> http://www.jambit.com
>
> fon: +49.89.260 19 609
> fax: +49.89.260 19 585
>
> PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
> PGP Keyserver: http://www.dfn-pca.de/pgpkserv
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: streaming out large xml documents to an rpc-based client
Posted by Scott Nichol <sn...@scottnichol.com>.
Serializers do currently write to a stream. At issue, I believe, is the
fact that Apache SOAP *always* serializes the SOAP envelope into a
string, and then serializes that envelope and any attachments into a
byte array to send. The latter is done so that an HTTP Content-Length
header can be created. The former may just be done for no other reason
than that is how the code was originally written.
I have already started contemplating a change to the second step, namely
streaming the response with no Content-Length header. This is less of a
help on calls with large SOAP envelopes than calls with large
attachments (because, as I said, the SOAP envelopes would already be
serialized to Strings), but it would help a lot of people who are
basically transferring large documents as Strings, byte arrays or DOM
Elements, since those documents could be handled as attachments.
Unfortunately, folks that must interop with .NET would not benefit from
this, since .NET does not support the original SOAP Attachments spec
(which they co-authored), choosing to support DIME exclusively instead.
So, the handling of large payloads is definitely something we are
looking to improve.
If you are interested in exploring alternative technologies to alleviate
your problems, I highly recommend you consider Axis
(http://xml.apache.org/axis/), which may be better than Apache SOAP for
your application.
Scott Nichol
----- Original Message -----
From: "Paul Marshall" <pa...@jambit.com>
To: <so...@xml.apache.org>
Sent: Thursday, November 14, 2002 8:07 AM
Subject: Re: streaming out large xml documents to an rpc-based client
> Scott Nichol wrote:
> > Paul,
> >
> > Is the OutOfMemoryException occuring on the server? What is the
Java
> > data type of the object you are returning? Do you use one of the
> > supplied serializers, or a custom one?
> >
> > Scott Nichol
> >
>
> Hi Scott,
>
> Thanks for resoponding.
> I'me talking about a custom Class that is serialized/deserialized with
a
> custom serialzier ( both are part of a custom databinding framework ).
> The problem of the return object getting too big has currently only
> occured on the server. Once the server actually has enough memory to
> respond with the large object, the client might well also run into
> problems. That's a separate problem however.
>
> So the idea of writing xml to the servlet response stream would only
be
> valid to improve serverside efficiency.
> Some first ideas would involve having a way of declaring a method to
be
> "streaming", so that the SOAP Implementation stops to be responsible
for
> the serialization of the return object but instead passes some open
> stream ( perhaps not directly the servlet response stream ) to the
> implementing service. The service could then "manually" serialize
chunks
> of the inteded return object and print these into the stream, in stead
> of growing a large object in memory. The soap framework would just
> handle the envelop etc. and blend the surrounding envelop xml text
with
> the streaming body of the method return value into the servlet
response
> stream. A change to this "streaming" architecture would definitely
mean
> a lot of work, even if the soap implementation would support it out of
> the box, as the implementing classes are currently ejb's that can not
so
> easily take a stream as input argument...
>
> On my project however, we are still evaluating other options to deal
> with the problem, and so it's not sure yet, that we will try anything
of
> the likes.
>
>
> I will get in touch with Virender Sandhu ( who seams to have a
solution
> like this ) as soon as I get more time.
>
> Cheers
>
> Paul
>
>
>
>
> --
> Kostenlose Stundenerfassung mit http://time.jambit.com
> ------------------------------------------------------
> Dipl.Phys. Paul Marshall, Software Architect
>
> jambit Software Development & Management GmbH
> Sendlinger Strasse 24, D-80331 Muenchen
> http://www.jambit.com
>
> fon: +49.89.260 19 609
> fax: +49.89.260 19 585
>
> PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
> PGP Keyserver: http://www.dfn-pca.de/pgpkserv
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: streaming out large xml documents to an rpc-based client
Posted by Paul Marshall <pa...@jambit.com>.
Scott Nichol wrote:
> Paul,
>
> Is the OutOfMemoryException occuring on the server? What is the Java
> data type of the object you are returning? Do you use one of the
> supplied serializers, or a custom one?
>
> Scott Nichol
>
Hi Scott,
Thanks for resoponding.
I'me talking about a custom Class that is serialized/deserialized with a
custom serialzier ( both are part of a custom databinding framework ).
The problem of the return object getting too big has currently only
occured on the server. Once the server actually has enough memory to
respond with the large object, the client might well also run into
problems. That's a separate problem however.
So the idea of writing xml to the servlet response stream would only be
valid to improve serverside efficiency.
Some first ideas would involve having a way of declaring a method to be
"streaming", so that the SOAP Implementation stops to be responsible for
the serialization of the return object but instead passes some open
stream ( perhaps not directly the servlet response stream ) to the
implementing service. The service could then "manually" serialize chunks
of the inteded return object and print these into the stream, in stead
of growing a large object in memory. The soap framework would just
handle the envelop etc. and blend the surrounding envelop xml text with
the streaming body of the method return value into the servlet response
stream. A change to this "streaming" architecture would definitely mean
a lot of work, even if the soap implementation would support it out of
the box, as the implementing classes are currently ejb's that can not so
easily take a stream as input argument...
On my project however, we are still evaluating other options to deal
with the problem, and so it's not sure yet, that we will try anything of
the likes.
I will get in touch with Virender Sandhu ( who seams to have a solution
like this ) as soon as I get more time.
Cheers
Paul
--
Kostenlose Stundenerfassung mit http://time.jambit.com
------------------------------------------------------
Dipl.Phys. Paul Marshall, Software Architect
jambit Software Development & Management GmbH
Sendlinger Strasse 24, D-80331 Muenchen
http://www.jambit.com
fon: +49.89.260 19 609
fax: +49.89.260 19 585
PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
PGP Keyserver: http://www.dfn-pca.de/pgpkserv
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: streaming out large xml documents to an rpc-based client
Posted by Virender Sandhu <vi...@m-trilogix.com>.
Hi Scott Nichol,
It is very important issue, you are right, we should discuss it in this
group.
Virender
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Wednesday, November 13, 2002 11:14 AM
Subject: Re: streaming out large xml documents to an rpc-based client
> Paul,
>
> Is the OutOfMemoryException occuring on the server? What is the Java
> data type of the object you are returning? Do you use one of the
> supplied serializers, or a custom one?
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Paul Marshall" <pa...@jambit.com>
> To: "soap-user" <so...@xml.apache.org>
> Sent: Wednesday, November 13, 2002 9:49 AM
> Subject: streaming out large xml documents to an rpc-based client
>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > We have an rpc-based soapinterface to our system ( using apache -
> soap )
> > ,that tries to return extremely large dataobjects.
> > Now we see,that these objects get so big, that we run out of memory
> > resulting in an OutOfMemoryException on an average soap - method
> > invocation.
> >
> > Now the idea would be to somehow keep the clientinterface stable, but
> to
> > change the server-side as to commit parts of the response-xml ( in our
> > case there is an underlying
> > list structure ) into the response-stream.
> > This way we would not need to build up the entire response in memory (
> > as it currently stands with our huge java-object ) before piping it
> out
> > to the client.
> >
> > This is important, as changing client-systems can result in quite some
> > cost.
> >
> > Does apache soap support any such idea, or can we use some parts under
> > the hood ?
> >
> > How big a job would you estimate this to be ?
> >
> > Thanks,
> >
> > Paul
> >
> > - --
> > Kostenlose Stundenerfassung mit http://time.jambit.com
> > - ------------------------------------------------------
> > Dipl.Phys. Paul Marshall, Software Architect
> >
> > jambit Software Development & Management GmbH
> > Sendlinger Strasse 24, D-80331 Muenchen
> > http://www.jambit.com
> >
> > fon: +49.89.260 19 609
> > fax: +49.89.260 19 585
> >
> > PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
> > PGP Keyserver: http://www.dfn-pca.de/pgpkserv
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.6 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQE90mZoragPljgZBjMRAs3oAKCIJx/Myzg0yZ1bVcbAfx9DEpZVxwCdENHZ
> > xXm3Db7fEKWkKyQhhxaKHLU=
> > =vbjy
> > -----END PGP SIGNATURE-----
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: streaming out large xml documents to an rpc-based client
Posted by Virender Sandhu <vi...@m-trilogix.com>.
Hi Scott Nichol,
It is very important issue, you are right, we should discuss it in this
group.
Virender
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Wednesday, November 13, 2002 11:14 AM
Subject: Re: streaming out large xml documents to an rpc-based client
> Paul,
>
> Is the OutOfMemoryException occuring on the server? What is the Java
> data type of the object you are returning? Do you use one of the
> supplied serializers, or a custom one?
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Paul Marshall" <pa...@jambit.com>
> To: "soap-user" <so...@xml.apache.org>
> Sent: Wednesday, November 13, 2002 9:49 AM
> Subject: streaming out large xml documents to an rpc-based client
>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > We have an rpc-based soapinterface to our system ( using apache -
> soap )
> > ,that tries to return extremely large dataobjects.
> > Now we see,that these objects get so big, that we run out of memory
> > resulting in an OutOfMemoryException on an average soap - method
> > invocation.
> >
> > Now the idea would be to somehow keep the clientinterface stable, but
> to
> > change the server-side as to commit parts of the response-xml ( in our
> > case there is an underlying
> > list structure ) into the response-stream.
> > This way we would not need to build up the entire response in memory (
> > as it currently stands with our huge java-object ) before piping it
> out
> > to the client.
> >
> > This is important, as changing client-systems can result in quite some
> > cost.
> >
> > Does apache soap support any such idea, or can we use some parts under
> > the hood ?
> >
> > How big a job would you estimate this to be ?
> >
> > Thanks,
> >
> > Paul
> >
> > - --
> > Kostenlose Stundenerfassung mit http://time.jambit.com
> > - ------------------------------------------------------
> > Dipl.Phys. Paul Marshall, Software Architect
> >
> > jambit Software Development & Management GmbH
> > Sendlinger Strasse 24, D-80331 Muenchen
> > http://www.jambit.com
> >
> > fon: +49.89.260 19 609
> > fax: +49.89.260 19 585
> >
> > PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
> > PGP Keyserver: http://www.dfn-pca.de/pgpkserv
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.6 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQE90mZoragPljgZBjMRAs3oAKCIJx/Myzg0yZ1bVcbAfx9DEpZVxwCdENHZ
> > xXm3Db7fEKWkKyQhhxaKHLU=
> > =vbjy
> > -----END PGP SIGNATURE-----
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@xml.apache.org>
> > For additional commands, e-mail:
> <ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: streaming out large xml documents to an rpc-based client
Posted by Paul Marshall <pa...@jambit.com>.
Scott Nichol wrote:
> Paul,
>
> Is the OutOfMemoryException occuring on the server? What is the Java
> data type of the object you are returning? Do you use one of the
> supplied serializers, or a custom one?
>
> Scott Nichol
>
Hi Scott,
Thanks for resoponding.
I'me talking about a custom Class that is serialized/deserialized with a
custom serialzier ( both are part of a custom databinding framework ).
The problem of the return object getting too big has currently only
occured on the server. Once the server actually has enough memory to
respond with the large object, the client might well also run into
problems. That's a separate problem however.
So the idea of writing xml to the servlet response stream would only be
valid to improve serverside efficiency.
Some first ideas would involve having a way of declaring a method to be
"streaming", so that the SOAP Implementation stops to be responsible for
the serialization of the return object but instead passes some open
stream ( perhaps not directly the servlet response stream ) to the
implementing service. The service could then "manually" serialize chunks
of the inteded return object and print these into the stream, in stead
of growing a large object in memory. The soap framework would just
handle the envelop etc. and blend the surrounding envelop xml text with
the streaming body of the method return value into the servlet response
stream. A change to this "streaming" architecture would definitely mean
a lot of work, even if the soap implementation would support it out of
the box, as the implementing classes are currently ejb's that can not so
easily take a stream as input argument...
On my project however, we are still evaluating other options to deal
with the problem, and so it's not sure yet, that we will try anything of
the likes.
I will get in touch with Virender Sandhu ( who seams to have a solution
like this ) as soon as I get more time.
Cheers
Paul
--
Kostenlose Stundenerfassung mit http://time.jambit.com
------------------------------------------------------
Dipl.Phys. Paul Marshall, Software Architect
jambit Software Development & Management GmbH
Sendlinger Strasse 24, D-80331 Muenchen
http://www.jambit.com
fon: +49.89.260 19 609
fax: +49.89.260 19 585
PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
PGP Keyserver: http://www.dfn-pca.de/pgpkserv
Re: streaming out large xml documents to an rpc-based client
Posted by Scott Nichol <sn...@scottnichol.com>.
Paul,
Is the OutOfMemoryException occuring on the server? What is the Java
data type of the object you are returning? Do you use one of the
supplied serializers, or a custom one?
Scott Nichol
----- Original Message -----
From: "Paul Marshall" <pa...@jambit.com>
To: "soap-user" <so...@xml.apache.org>
Sent: Wednesday, November 13, 2002 9:49 AM
Subject: streaming out large xml documents to an rpc-based client
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> We have an rpc-based soapinterface to our system ( using apache -
soap )
> ,that tries to return extremely large dataobjects.
> Now we see,that these objects get so big, that we run out of memory
> resulting in an OutOfMemoryException on an average soap - method
> invocation.
>
> Now the idea would be to somehow keep the clientinterface stable, but
to
> change the server-side as to commit parts of the response-xml ( in our
> case there is an underlying
> list structure ) into the response-stream.
> This way we would not need to build up the entire response in memory (
> as it currently stands with our huge java-object ) before piping it
out
> to the client.
>
> This is important, as changing client-systems can result in quite some
> cost.
>
> Does apache soap support any such idea, or can we use some parts under
> the hood ?
>
> How big a job would you estimate this to be ?
>
> Thanks,
>
> Paul
>
> - --
> Kostenlose Stundenerfassung mit http://time.jambit.com
> - ------------------------------------------------------
> Dipl.Phys. Paul Marshall, Software Architect
>
> jambit Software Development & Management GmbH
> Sendlinger Strasse 24, D-80331 Muenchen
> http://www.jambit.com
>
> fon: +49.89.260 19 609
> fax: +49.89.260 19 585
>
> PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
> PGP Keyserver: http://www.dfn-pca.de/pgpkserv
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE90mZoragPljgZBjMRAs3oAKCIJx/Myzg0yZ1bVcbAfx9DEpZVxwCdENHZ
> xXm3Db7fEKWkKyQhhxaKHLU=
> =vbjy
> -----END PGP SIGNATURE-----
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: streaming out large xml documents to an rpc-based client
Posted by Scott Nichol <sn...@scottnichol.com>.
Paul,
Is the OutOfMemoryException occuring on the server? What is the Java
data type of the object you are returning? Do you use one of the
supplied serializers, or a custom one?
Scott Nichol
----- Original Message -----
From: "Paul Marshall" <pa...@jambit.com>
To: "soap-user" <so...@xml.apache.org>
Sent: Wednesday, November 13, 2002 9:49 AM
Subject: streaming out large xml documents to an rpc-based client
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> We have an rpc-based soapinterface to our system ( using apache -
soap )
> ,that tries to return extremely large dataobjects.
> Now we see,that these objects get so big, that we run out of memory
> resulting in an OutOfMemoryException on an average soap - method
> invocation.
>
> Now the idea would be to somehow keep the clientinterface stable, but
to
> change the server-side as to commit parts of the response-xml ( in our
> case there is an underlying
> list structure ) into the response-stream.
> This way we would not need to build up the entire response in memory (
> as it currently stands with our huge java-object ) before piping it
out
> to the client.
>
> This is important, as changing client-systems can result in quite some
> cost.
>
> Does apache soap support any such idea, or can we use some parts under
> the hood ?
>
> How big a job would you estimate this to be ?
>
> Thanks,
>
> Paul
>
> - --
> Kostenlose Stundenerfassung mit http://time.jambit.com
> - ------------------------------------------------------
> Dipl.Phys. Paul Marshall, Software Architect
>
> jambit Software Development & Management GmbH
> Sendlinger Strasse 24, D-80331 Muenchen
> http://www.jambit.com
>
> fon: +49.89.260 19 609
> fax: +49.89.260 19 585
>
> PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
> PGP Keyserver: http://www.dfn-pca.de/pgpkserv
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE90mZoragPljgZBjMRAs3oAKCIJx/Myzg0yZ1bVcbAfx9DEpZVxwCdENHZ
> xXm3Db7fEKWkKyQhhxaKHLU=
> =vbjy
> -----END PGP SIGNATURE-----
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: streaming out large xml documents to an rpc-based client
Posted by Scott Nichol <sn...@scottnichol.com>.
The discussion would be of great value to the Apache SOAP user
community. If you will be discussing proprietary topics, I understand
taking it off-line, but otherwise I encourage you to share your
experience here.
Scott Nichol
----- Original Message -----
From: "Virender Sandhu" <vi...@m-trilogix.com>
To: <so...@xml.apache.org>
Sent: Sunday, September 29, 2002 9:54 AM
Subject: Re: streaming out large xml documents to an rpc-based client
> Hi Paul Marshall:
>
> I had the same problem when one of my soap method was returning ~32MB
xml
> file. If you are interested in my solution (free) or want further
> discussion, send me email.
>
> Virender Sandhu
> Senior Engineer
> m-trilogix Inc.
> Mobile Solutions Provider
> www.m-trilogix.com
> virenders@m-trilogix.com
>
>
> ----- Original Message -----
> From: "Paul Marshall" <pa...@jambit.com>
> To: "soap-user" <so...@xml.apache.org>
> Sent: Wednesday, November 13, 2002 10:49 AM
> Subject: streaming out large xml documents to an rpc-based client
>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > We have an rpc-based soapinterface to our system ( using apache -
soap )
> > ,that tries to return extremely large dataobjects.
> > Now we see,that these objects get so big, that we run out of memory
> > resulting in an OutOfMemoryException on an average soap - method
> > invocation.
> >
> > Now the idea would be to somehow keep the clientinterface stable,
but to
> > change the server-side as to commit parts of the response-xml ( in
our
> > case there is an underlying
> > list structure ) into the response-stream.
> > This way we would not need to build up the entire response in memory
(
> > as it currently stands with our huge java-object ) before piping it
out
> > to the client.
> >
> > This is important, as changing client-systems can result in quite
some
> > cost.
> >
> > Does apache soap support any such idea, or can we use some parts
under
> > the hood ?
> >
> > How big a job would you estimate this to be ?
> >
> > Thanks,
> >
> > Paul
> >
> > - --
> > Kostenlose Stundenerfassung mit http://time.jambit.com
> > - ------------------------------------------------------
> > Dipl.Phys. Paul Marshall, Software Architect
> >
> > jambit Software Development & Management GmbH
> > Sendlinger Strasse 24, D-80331 Muenchen
> > http://www.jambit.com
> >
> > fon: +49.89.260 19 609
> > fax: +49.89.260 19 585
> >
> > PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
> > PGP Keyserver: http://www.dfn-pca.de/pgpkserv
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.6 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQE90mZoragPljgZBjMRAs3oAKCIJx/Myzg0yZ1bVcbAfx9DEpZVxwCdENHZ
> > xXm3Db7fEKWkKyQhhxaKHLU=
> > =vbjy
> > -----END PGP SIGNATURE-----
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@xml.apache.org>
> > For additional commands, e-mail:
<ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
Re: streaming out large xml documents to an rpc-based client
Posted by Scott Nichol <sn...@scottnichol.com>.
The discussion would be of great value to the Apache SOAP user
community. If you will be discussing proprietary topics, I understand
taking it off-line, but otherwise I encourage you to share your
experience here.
Scott Nichol
----- Original Message -----
From: "Virender Sandhu" <vi...@m-trilogix.com>
To: <so...@xml.apache.org>
Sent: Sunday, September 29, 2002 9:54 AM
Subject: Re: streaming out large xml documents to an rpc-based client
> Hi Paul Marshall:
>
> I had the same problem when one of my soap method was returning ~32MB
xml
> file. If you are interested in my solution (free) or want further
> discussion, send me email.
>
> Virender Sandhu
> Senior Engineer
> m-trilogix Inc.
> Mobile Solutions Provider
> www.m-trilogix.com
> virenders@m-trilogix.com
>
>
> ----- Original Message -----
> From: "Paul Marshall" <pa...@jambit.com>
> To: "soap-user" <so...@xml.apache.org>
> Sent: Wednesday, November 13, 2002 10:49 AM
> Subject: streaming out large xml documents to an rpc-based client
>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > We have an rpc-based soapinterface to our system ( using apache -
soap )
> > ,that tries to return extremely large dataobjects.
> > Now we see,that these objects get so big, that we run out of memory
> > resulting in an OutOfMemoryException on an average soap - method
> > invocation.
> >
> > Now the idea would be to somehow keep the clientinterface stable,
but to
> > change the server-side as to commit parts of the response-xml ( in
our
> > case there is an underlying
> > list structure ) into the response-stream.
> > This way we would not need to build up the entire response in memory
(
> > as it currently stands with our huge java-object ) before piping it
out
> > to the client.
> >
> > This is important, as changing client-systems can result in quite
some
> > cost.
> >
> > Does apache soap support any such idea, or can we use some parts
under
> > the hood ?
> >
> > How big a job would you estimate this to be ?
> >
> > Thanks,
> >
> > Paul
> >
> > - --
> > Kostenlose Stundenerfassung mit http://time.jambit.com
> > - ------------------------------------------------------
> > Dipl.Phys. Paul Marshall, Software Architect
> >
> > jambit Software Development & Management GmbH
> > Sendlinger Strasse 24, D-80331 Muenchen
> > http://www.jambit.com
> >
> > fon: +49.89.260 19 609
> > fax: +49.89.260 19 585
> >
> > PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
> > PGP Keyserver: http://www.dfn-pca.de/pgpkserv
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.6 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQE90mZoragPljgZBjMRAs3oAKCIJx/Myzg0yZ1bVcbAfx9DEpZVxwCdENHZ
> > xXm3Db7fEKWkKyQhhxaKHLU=
> > =vbjy
> > -----END PGP SIGNATURE-----
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@xml.apache.org>
> > For additional commands, e-mail:
<ma...@xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@xml.apache.org>
> For additional commands, e-mail:
<ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: streaming out large xml documents to an rpc-based client
Posted by Virender Sandhu <vi...@m-trilogix.com>.
Hi Paul Marshall:
I had the same problem when one of my soap method was returning ~32MB xml
file. If you are interested in my solution (free) or want further
discussion, send me email.
Virender Sandhu
Senior Engineer
m-trilogix Inc.
Mobile Solutions Provider
www.m-trilogix.com
virenders@m-trilogix.com
----- Original Message -----
From: "Paul Marshall" <pa...@jambit.com>
To: "soap-user" <so...@xml.apache.org>
Sent: Wednesday, November 13, 2002 10:49 AM
Subject: streaming out large xml documents to an rpc-based client
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> We have an rpc-based soapinterface to our system ( using apache - soap )
> ,that tries to return extremely large dataobjects.
> Now we see,that these objects get so big, that we run out of memory
> resulting in an OutOfMemoryException on an average soap - method
> invocation.
>
> Now the idea would be to somehow keep the clientinterface stable, but to
> change the server-side as to commit parts of the response-xml ( in our
> case there is an underlying
> list structure ) into the response-stream.
> This way we would not need to build up the entire response in memory (
> as it currently stands with our huge java-object ) before piping it out
> to the client.
>
> This is important, as changing client-systems can result in quite some
> cost.
>
> Does apache soap support any such idea, or can we use some parts under
> the hood ?
>
> How big a job would you estimate this to be ?
>
> Thanks,
>
> Paul
>
> - --
> Kostenlose Stundenerfassung mit http://time.jambit.com
> - ------------------------------------------------------
> Dipl.Phys. Paul Marshall, Software Architect
>
> jambit Software Development & Management GmbH
> Sendlinger Strasse 24, D-80331 Muenchen
> http://www.jambit.com
>
> fon: +49.89.260 19 609
> fax: +49.89.260 19 585
>
> PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
> PGP Keyserver: http://www.dfn-pca.de/pgpkserv
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE90mZoragPljgZBjMRAs3oAKCIJx/Myzg0yZ1bVcbAfx9DEpZVxwCdENHZ
> xXm3Db7fEKWkKyQhhxaKHLU=
> =vbjy
> -----END PGP SIGNATURE-----
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: streaming out large xml documents to an rpc-based client
Posted by Virender Sandhu <vi...@m-trilogix.com>.
Hi Paul Marshall:
I had the same problem when one of my soap method was returning ~32MB xml
file. If you are interested in my solution (free) or want further
discussion, send me email.
Virender Sandhu
Senior Engineer
m-trilogix Inc.
Mobile Solutions Provider
www.m-trilogix.com
virenders@m-trilogix.com
----- Original Message -----
From: "Paul Marshall" <pa...@jambit.com>
To: "soap-user" <so...@xml.apache.org>
Sent: Wednesday, November 13, 2002 10:49 AM
Subject: streaming out large xml documents to an rpc-based client
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> We have an rpc-based soapinterface to our system ( using apache - soap )
> ,that tries to return extremely large dataobjects.
> Now we see,that these objects get so big, that we run out of memory
> resulting in an OutOfMemoryException on an average soap - method
> invocation.
>
> Now the idea would be to somehow keep the clientinterface stable, but to
> change the server-side as to commit parts of the response-xml ( in our
> case there is an underlying
> list structure ) into the response-stream.
> This way we would not need to build up the entire response in memory (
> as it currently stands with our huge java-object ) before piping it out
> to the client.
>
> This is important, as changing client-systems can result in quite some
> cost.
>
> Does apache soap support any such idea, or can we use some parts under
> the hood ?
>
> How big a job would you estimate this to be ?
>
> Thanks,
>
> Paul
>
> - --
> Kostenlose Stundenerfassung mit http://time.jambit.com
> - ------------------------------------------------------
> Dipl.Phys. Paul Marshall, Software Architect
>
> jambit Software Development & Management GmbH
> Sendlinger Strasse 24, D-80331 Muenchen
> http://www.jambit.com
>
> fon: +49.89.260 19 609
> fax: +49.89.260 19 585
>
> PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633
> PGP Keyserver: http://www.dfn-pca.de/pgpkserv
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE90mZoragPljgZBjMRAs3oAKCIJx/Myzg0yZ1bVcbAfx9DEpZVxwCdENHZ
> xXm3Db7fEKWkKyQhhxaKHLU=
> =vbjy
> -----END PGP SIGNATURE-----
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>