ah, that does complicate things. no serialized objects, that's for sure - only
works when the client is java and has
the same classes loaded locally. not familiar with the Chunk model but it
sounds messy. so the assumption that seems
to make sense is that the server is running out of memory while building the
XML (or DOM) from the large object tree
you want to return to the client. you can go with a non-XML approach to reduce
the size of the response, but if just
building the response takes down the server i would consider adding memory to
that server because if you have
simultaneous client requests (which is pretty normal in most server
environments) then you're going to have that many
more copies of the response to build. it all depends on what's causing the
server to run out of memory - if it's the
process of building a full in-memory copy of the response (i.e., if your
response XML is so much larger than the
original data object it's being built from) you might consider a way to start
streaming the response to the client
that doesn't require a full in-memory copy of the data. or you might consider
exposing an interface to the data that
doesn't require that you stream the whole thing (similar to the more granular
API idea) - something like the way
databases expose cursors to a dataset instead of returning the entire dataset
in one monster response. or you could
use a more compact, tho perhaps not binary, format for returning the data
depending on how complex it is - for
instance if it's many rows of data with no structures perhaps a comma-seperated
sequence of rows would work.
sorry i couldn't be of more help.
................ron.
>
> Thanks a lot Ron.
> Clients typically going to want the whole block as XML, i have implemented
> the Chunk model but its goes very slow.
> What are other ways those can enable me to send Lacs of records to the
> client? Client may be PHP, .NET, Java etc.
>
> With Warm Regards,
>
> Muhammad Iqbal
> Cell#: 0092-300-9377801
> [EMAIL PROTECTED]
> From: "Ron Reynolds"
> Reply-To: [email protected]
> To: [email protected]
> Subject: Re: [axis2] How to control response Serialization
> Date: Fri, 30 Sep 2005 14:52:31 -0700 (PDT)
>>you might consider sending it as a binary attachment (never tried, only read
>>about it) or, if you want to return it
>>within the XML, you can first serialize the object tree into a byte[] and
>>then Base64-encode it (which will make it a
>>about 30% larger) and embed that into the XML as a very big block of text).
>>or you might consider an approach other
>>than web services for this particular call or breaking the API into smaller
>>operatiosn (instead of returning one big
>>lump of data perhaps it can be accessed in pieces - are clients typically
>>going to want the whole block or just
>> pieces
>>of it?).
>>
>>...............ron.
>>
>> >
>> > my web service returns a very huge result, that going to send to the
>> > client. when it retuns result it goes out of
>> > memeory and slow performance. I my service should directly seririalize
>> > result to the output stream as in java
>> servlet
>> > e.g.; out.writel(myOMElement);
>> >
>> >
>> >
>> >
>> > With Warm Regards,
>> >
>> > Muhammad Iqbal
>> > MCIT, DCS, SCJP, MCP (.NET)
>> > Etilize Inc.
>> > Cell#: 0092-300-9377801
>> > [EMAIL PROTECTED]
>>
>>
>
