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]
