Hi Alex Thanks again for your efforts I have tried to the override the writeTo() method as you have advised and it didn't work, farther more I have tried to investigate whether if the problem might be with getInputStream() in DataHandler calss and it turned out to be using a PipedInput/OutputStream that has a circular buffer into which incoming data is placed. I wonder if this buffering might be the cause of the delay!
-----Original Message----- From: Alex Dickinson [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 6:04 PM To: [email protected] Subject: Re: Streaming Soap with Attachments Override the writeTo of DataHandler to overcome the caching used by the BufferedOutputStreams (Note that this is the same code as the original implementation of DataHandler.writeTo, but it will flush after each write): public void writeTo(OutputStream os) throws IOException { // for the DataSource case if (dataSource != null) { InputStream is = null; byte data[] = new byte[8 * 1024]; int bytes_read; is = dataSource.getInputStream(); try { while ((bytes_read = is.read(data)) > 0) { os.write(data, 0, bytes_read); os.flush(); } } finally { is.close(); is = null; } } else { // for the Object case DataContentHandler dch = getDataContentHandler(); dch.writeTo(object, objectMimeType, os); } } Peter Makoi wrote: > Thaks a lot Alex > Is it possible that you provide an example code because I have already > tried to write a custom DataSource class and it is not working as I > expected > below is the code > > public javax.activation.DataHandler[] returnStreamingByteArray(final int > timeout) { > DataHandler ret = new DataHandler(new DataSource() { > private long start = System.currentTimeMillis(); > private long end = start + timeout; > > public String getContentType() { > return "text/plain"; > } > > public InputStream getInputStream() throws IOException { > return new InputStream() { > public int read() throws IOException { > try { > Thread.sleep(10); > } catch (InterruptedException e) { > //ignore this exception > } > if (System.currentTimeMillis() > end) { > return -1; > } else { > return (int)(Math.random() * 256); > } > } > }; > } > > public String getName() { > return ""; > } > > public OutputStream getOutputStream() throws IOException { > return null; > } > > > }); > return new DataHandler[]{ret}; > } > > > -----Original Message----- > From: Alex Dickinson [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 04, 2007 10:07 PM > To: [email protected] > Subject: Re: Streaming Soap with Attachments > > The delay is due to the default behaviour of writeObject() in > javax.activation.DataHandler. The stream that gets passed to it is > buffered, which will have to fill up before the bytes are sent over the > socket's stream. > > Also the ByteArrayDataSource requires that the DataSource be fully > written to before it can be read from. > > I had to do something similar. I had small amounts of data that had to > be sent over a long period of time. I ended up having to write a custom > DataSource that made data available to the InputStream as soon as it was > available, and to implement a custom DataHandler to would flush the > output in writeObject when ever it wrote data. > > Hope that helps, > Alex > > > > Davanum Srinivas wrote: >> Axis1 or Axis2? Can you post some code of what you tried? >> >> thanks, >> dims >> >> On 7/4/07, Peter Makoi <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> Does soap with attachments using MIME multipart support streaming? >>> >>> I have goggled around trying to find out if there is a possibility of >>> doing >>> that but i end up getting some old postings and documentations that >>> suggest >>> that SwA does not support streaming >>> >>> I have also tried to simulate streaming a considerably large amount > of >>> data >>> by sending it as a data handler and then use the streaming capability >>> of the >>> activation framework to stream the data into an output stream >>> >>> But what I got is an overhead equivalent to the time spend to > transmit >>> the >>> whole file to the client before the streaming begins(my conclusion > was >>> that >>> the data is received in a one-go and because of it's large size it > take's >>> the processor sometime to allocate some memory space to save it > before >>> the >>> streaming even begins).... Does anyone have any explanation? Thanks > in >>> advance >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
