That resolved the issue. Thanks for your help.

Henk

On Jan 27, 2010, at 12:22 AM, Henk Flipman wrote:

> Thanks, Dan.
> 
> This is for debug logging. In production it will be turned off so I'm not too 
> worried about the memory impact.
> 
> Thanks!
> 
> Henk
> 
> On Jan 26, 2010, at 7:21 PM, Daniel Kulp wrote:
> 
>> On Tue January 26 2010 5:18:38 pm Henk Flipman wrote:
>>> Hmmm. That outputs:
>>> 
>>> SOAP Response xml: java.io.bufferedoutputstr...@69032c
>>> 
>>> to the log for a large SOAP response. It works fine for 'small' SOAP
>>> responses.
>> 
>> This is a good thing to see.   Basically, once it hits 64K by default, it 
>> starts using a temporary file on the file system to record the bytes.   
>> (under 
>> 64K, it just uses a ByteArrayOutputStream).    What you are seeing here is 
>> the 
>> BufferedOutputStream that is wrappering a FileOutputStream.   
>> 
>> If you want the full bytes, you can call bos.getBytes().   Keep in mind, 
>> that 
>> brings a lot of stuff in memory.  
>> 
>> If you just want the File object to copy the file or something, you can do:
>> bos.getTempFile()
>> 
>> 
>> I think I just realized the next problem you will hit.   The bos stream is 
>> closed before you are calling getInputStream.  Thus, the file may be 
>> deleted.  
>> Move setting the content up a bit.  
>> 
>>     IOUtils.copy(is, bos);
>>     is.close();
>>     bos.flush();
>> 
>>     message.setContent(InputStream.class,
>>                       bos.getInputStream())
>> 
>>     String response = new String(bos.getBytes());
>>     log.debug("SOAP Response xml: " + response);
>>     bos.close();
>> 
>> 
>> Dan
>> 
>> 
>>> 
>>> This is CXF 2.2.5 btw.
>>> 
>>> Thoughts?
>>> 
>>> Henk
>>> 
>>> On Jan 25, 2010, at 8:55 AM, Daniel Kulp wrote:
>>>> Definitely shouldn't be any size limit.....
>>>> 
>>>>>              IOUtils.copy(is, bos);
>>>>>              is.close();
>>>>>              bos.close();
>>>>> 
>>>>>              String response = bos.getOut().toString();
>>>>>              log.debug("SOAP Response xml: " + response);
>>>> 
>>>> Try changing the above to
>>>> 
>>>>               IOUtils.copy(is, bos);
>>>>               is.close();
>>>>               bos.flush();
>>>> 
>>>>               String response = bos.getOut().toString();
>>>>               log.debug("SOAP Response xml: " + response);
>>>>               bos.close();
>>>> 
>>>> Most likely, the bos.close() is triggering the temp file to be deleted as
>>>> that's the last stream to access the file.
>>>> 
>>>> 
>>>> Dan
>>>> 
>>>> On Sun January 24 2010 10:57:34 am Henk Flipman wrote:
>>>>> Hi,
>>>>> 
>>>>> are there any size limits I should be aware of? I'm seeing the following
>>>>> exceptions while parsing large responses:
>>>>> 
>>>>> Caused by: javax.xml.ws.soap.SOAPFaultException: Error reading
>>>>> XMLStreamReader. at
>>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
>>>>> 
>>>>> Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
>>>>> at [row,col {unknown-source}]: [1,0]
>>>>>     at
>>>>> com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:686)
>>>>> 
>>>>> These responses are around 300K.
>>>>> 
>>>>> I wrote an in-interceptor to log the incoming message, and the string I
>>>>> get is blank. I used:
>>>>> 
>>>>>      public void handleMessage(Message message) {
>>>>>          InputStream is = message.getContent(InputStream.class);
>>>>> 
>>>>>          if (is == null) {
>>>>>              return;
>>>>>          }
>>>>> 
>>>>>          CachedOutputStream bos = new CachedOutputStream();
>>>>>          try {
>>>>>              IOUtils.copy(is, bos);
>>>>>              is.close();
>>>>>              bos.close();
>>>>> 
>>>>>              String response = bos.getOut().toString();
>>>>>              log.debug("SOAP Response xml: " + response);
>>>>> 
>>>>>              message.setContent(InputStream.class,
>>>>> bos.getInputStream()); } catch (IOException e) {
>>>>>              throw new Fault(e);
>>>>>          }
>>>>>      }
>>>>> 
>>>>> Any thought?
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>> Henk
>>> 
>> 
>> -- 
>> Daniel Kulp
>> [email protected]
>> http://www.dankulp.com/blog
> 

Reply via email to