|RetrieveDocumentSet - Serious Memory Problem [message #587676]
||Wed, 17 September 2008 09:24
| Stefan S.
Registered: July 2009
Recently - during developing the ITI-43 RetrieveDocumentSet - I have
stumbled accross a serious problem.
Please correct me, if I am wrong but the correct workflow is to create a
new RetrieveDocumentSetRepsonseType, loop over all documents that must be
returned and creating a DocumentResponseType by setting basic attributes
as well as the actual document every time.
I achieve this by doing the following (just the relevant lines... *g*):
RetrieveDocumentSetResponseType retrieveDocumentSetResponse =
DocumentResponseType documentResponse =
//Set "easy" attributes
//Set the "tricky" document content part
byte fileBytes = this.getBytesFromFile(document);
As you can see, the document (its content) is set using a byte array.
This tends to be a serious issue as you run out of memory in no time!
So I think the only solution to this problem is to leave setting the
document as a byte array beside, generate an OMElement from the rest of
the model and set the attachments lateron - directly within the OMElement.
(Of course the approach should be a streaming solution, because otherwise
OMElement is very likely to run out of memory, too... ;)
Bu my problem is, that I have no clue on how to achive this.
I already tried setting the attachment "manually", which looks something
FileDataSource fds = new FileDataSource(document);
DataHandler dh = new DataHandler(fds);
MessageContext inMessageContext =
OperationContext operationContext =
MessageContext outMessageContext =
String attachmentID = outMessageContext.addAttachment(dh);
Sadly this does not work, because then the response does not contain a
"Document" Tag (Part), that would hold the actual content of the retrieved
Can anyone provide me some help, hints - or better - has anyone stumbled
across the same problem and can provide a solution? (God, I hope it is so!
Thanks in Advance for your time and your answers!
Powered by FUDForum
. Page generated in 0.12822 seconds