Thanks for the suggestions. Since we are using a buffered input stream, we are not garunteed that we will get a full buffer on each read. Also, there is the situation where a client can send over full buffers each time but the data is only part of the buffer. Lastly there is the situation where the data is exactly the size of a buffer causing another read and a block. So checking for an amount read being less than a buffer does not work. This has been verified in testing as well.
Since the client applications are not just java and we send data back, I couldn't use the suggestion from Dennis. But, it did get me looking at the Socket class and as such I've set the soTimeout on the socket and then catch the exception and end the read. While that's not perfect, it does seem to do the trick. Thanks Jeff -----Original Message----- From: Dennis DiMaria [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 2:21 PM To: jdjlist Subject: [jdjlist] Re: Reliable TCP/IP stream reading I couldn't find the class BytesMessage in the 1.3 API. Is it part of an optional package? Normally, reading less data than you asked for does not indicate a socket stream will not send more data in a future read. It depends on how the tcp/ip stack chops up data into packets on the "send" side and how they are then read on the "receive" side." The sender could run the shutdownOutput() method (SocketImpl class) to indicate it's finished sending. It can also close() the socket. Until one of these are done there's no guarantee that the sender is finished. -Dennis D [EMAIL PROTECTED] wrote: > > > > Jeff, > > Instead of waiting for the number of bytes read to be -1, identify when the > byte buffer has not been completely filled. When this condition occurs you > know you have reached the end of your xml document otherwise the call to > read() would block until more data is received to fill the buffer. I've > done this when reading XMLDocuments from a JMS ByteMessage but it will > behave in the same way for a tcp/ip stream. > > int MESSAGE_BUFFER_LENGTH = 500; > > private byte[] buffer = new byte[MESSAGE_BUFFER_LENGTH]; > StringBuffer stringBuffer = new StringBuffer(); > BytesMessage message = (BytesMessage)msg; > int length = 0; > > do > { > length = message.readBytes(m_buffer); > if (length > 0) > { > String read = new String(m_buffer, 0, length, "US-ASCII"); > stringBuffer.append(read); > } > } > while(length == MESSAGE_BUFFER_LENGTH); > > Hope this helps, > HOWARD GAISFORD > > ... > > Is there a reliable way to read from a tcp/ip stream that will identify > when there is nothing left on the stream to read? > > We have been using the following code > > public int readData(StringBuffer buf) throws IOException > { > byte[] InBuf = new byte[2048]; > int totBytes = 0; > int bytesRead = 0; > > // > // Sanity check > if ( buf != null ) { > buf.delete(0, buf.length()); > > Arrays.fill(InBuf, (byte)0); > bytesRead = m_In.read(InBuf, 0, 2048); > > while ( bytesRead != -1 ) { > totBytes += bytesRead; > buf.append(new String(InBuf, 0, bytesRead)); > Arrays.fill(InBuf, (byte)0); > bytesRead = m_In.read(InBuf, 0, 2048); > } > } > > return totBytes; > } > > This has worked great until recently. We have been sending over larger xml > documents than we had before and now this code does not work. > Specifically, read does not return -1 even though there is nothing left on > the stream to read. This causes the code to block. If we use > m_In.available(), that returns a bogus 0 and we only get a partial > document. Besides, the available() function is not reliable based on the > java documentation. > > There seems to be some size threshold here where these fail. > > I've checked on the web, but almost exclusivly I've seen code similar to > the above. Does anyone have any suggestions? > > Thanks > > Jeff Fisher > --- --- You are currently subscribed to jdjlist as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] http://www.sys-con.com/fusetalk To unsubscribe from all mailing lists, click: http://sys-con.com/[EMAIL PROTECTED] on.com --- You are currently subscribed to jdjlist as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] http://www.sys-con.com/fusetalk To unsubscribe from all mailing lists, click: http://sys-con.com/[EMAIL PROTECTED]
