I am writing a socket-based server in java. A client connects to it(a web-browser) and the server sends back a simple html code and sets cookie to recognize next time client connects to it again. I am using PrintStream to write to the socket , but flush is not working. The only way i can flush is to use shutdownoutput or close and both close the socket stream. But i do not want that because i am readin/writing to it several times in several places in the code. What can do? Could't get any help from the tags.
I also tried other buffered writer classes, same problem.
Ah yeah , sillyproblem , you just have to use pstream.writeln(""); since breader.readLine() reads until it finds '\n' character.
so write() won't work.
I would try calling this method instead of flush:
public boolean checkError()
Returns:
True if and only if this stream has encountered an IOException other than InterruptedIOException, or the setError method has been invoked
See if it is failing for some reason to do the flush (checkError calls flush internally and remembers error state).
Also worth trying is connecting to the server using telnet and seeing if the data is being returning immediately, or writing a simple java client socket program to check (cut/paste one off the net).
It might be that the browser has decided to deliberately wait for more input before displaying your html (especially if the html is not perfectly formed). I seem to remember having this issue myself in the past.
Related
Recently I was writing a http server and I transplanted some netty components to my project. When I read the source code of netty's ChannelHandlerContext, I found that actually it doesn't flush into socket. I knew that I have to invoke flush() to flush the internal buffer into socket.
So I wonder will netty automatically flush the internal buffer, I have read some source code, but I am not good at it. And I googled but none answered it, the only answer I got is do flushing.
What I have learned from source code is: write continue writing into outboundbuffer, and if outboundbuffer reaches highwatermark, it will fire writability changed event and the channel is unwritable.
You can call the writeAndFlush method if you want to do it in one line, but otherwise you need to flush or you data will not go through.
4.0 introduced a new operation called flush() which explicitly flushes the outbound buffer of a Channel, and write() operation does not flush automatically. You can think of this as a java.io.BufferedOutputStream, except that it works at message level.
Because of this change, you must be very careful not to forget to call ctx.flush() after writing something. Alternatively, you could use a shortcut method writeAndFlush().
I found it at https://netty.io/wiki/new-and-noteworthy-in-4.0.html#write-does-not-flush-automatically
In fact, I have the similar question at Why did not call ctx.flush() after ctx.write() is called at Netty user guide?
Please contact me if you got the answer.
No, it won't.
However, it could be implemented quite easily.
As you said:
What I have learned from source code is: write continue writing into
outboundbuffer, and if outboundbuffer reaches highwatermark, it will
fire writability changed event and the channel is unwritable.
It's right. and it in fact tells a way to automaticallly flush. Just override ChannelInboundHandler.channelWritabilityChanged to call flush().
I'm developing a distributed system that receives requests via Socket and writes the results back using OutputStream.
I'm facing problems because I have to return a very large string, but Java just keeps the execution of the code after I call the method print() without it finished printing:
public void attendRequisition(Socket clientSocket) {
PrintWriter pw = new PrintWriter(clientSocket.getOutputStream());
pw.print(getResults());
pw.close()
}
Some information:
I need to close the connection after sending the results.
Without the close() instruction, the whole printing process takes about 3~5 seconds to finishes
I'm using telnet to test this method, and I can see the message coming and being cut becase of Java running the close() instruction
I can't count with receiving client's feedback
I believe this is happening because Java thinks the method print() finished executing, but what might be happening is that Java sends the message to the JVM, and JVM send it to the network adapter, and since the message is very large, close() method is called before the network adapter is able to send the entire message.
What I need is a way to make sure Java will only run the instruction close() after the printing process finished and the client received the entire message.
UPDATE: I was able to get it working properly by adding a Thread.sleep(). By doing this, the SO has enough time to send the message before Java closes the connection. But I don't want to use this solution, it implicates on too many problems.
I was able to solve the problem using DataOutputStream.writeBytes(). This way, the execution only continues when the method finishes sending the data. It is slower, but works.
I'll bet that if you use another constructor (i.e., the one whose 2nd argument is a boolean to indicate your desire to flush) then your example will work. The way you're constructing the object, autoflush is disabled.
If your real code is more complex, then you can call pw.flush() at the appropriate moments.
I can see the message coming and being cut becase of Java running the close() instruction
No you can't. You can see the message being cut, unless you're wrong about how long it is, but you're jumping to conclusions about the reason. Java does not close the PrintWriter before it has finished sending. It flushes the writer to the socket send buffer, blocking if necessary, and then closes the underlying socket, which buffers a FIN behind the data. All the data gets sent, and all the data gets received, before the FIN arrives, which signals end of stream to the receiver.
Possibly you are unaware that PrintWriter swallows exceptions and therefore should really not be used over a network.
In the following scenario
ObjectOutputStream output = new ObjectOutputStream(socket.getOutputStream());
output.flush();
// Do stuff with it
Why is it always necessary to flush the buffer after initial creation?
I see this all the time and I don't really understand what has to be flushed. I kind of expect newly created variables to be empty unless otherwise is specified.
Kind of like buying a trash-can and finding a tiny pile of trash inside that came with it.
In over 15 years of writing Java on a professional level I've never once encountered a need to flush a stream before writing to it.
The flush operation would do nothing at all, as there's nothing to flush.
You want to flush the stream before closing it, though the close operation should do that for you it is often considered best practice to do it explicitly (and I have encountered situations where that did make a difference, where apparently the close operation did not actually do a flush first.
Maybe you are confused with that?
When you write data out to a stream, some amount of buffering will occur, and you never know for sure exactly when the last of the data will actually be sent. You might perform many rite operations on a stream before closing it, and invoking the flush()method guarantees that the last of the data you thought you had already written actually gets out to the file. Whenever you're done using a file, either reading it or writing to it, you should invoke the close()method. When you are doing file I/O you're using expensive and limited operating system resources, and so when you're done, invoking close()will free up those resources.
This is needed when using either ObjectInputStream and ObjectOutputStream, because they send a header over the stream before the first write is called. The call to flush() will send that header to the remote side.
According to the spec, the header exists of the following contents:
magic version
If the header doesn't arrive at the moment a ObjectInputStream is build, this call will hang until it received the header bytes.
This means that if the protocol in question is written with ObjectStreams, it should flush after creating a ObjectOutputStream.
I have several questions-
1. I have two computers connected by socket connection. When the program executes
outputStream.writeInt(value);
outputStream.flush();
what actually happens? Does the program wait until the other computer reads the integer value?
2. How can I empty the outputStream or inputStream? Meaning, when emptying
the outputStream or inputStream, whatever is written to that stream gets removed.
(please don't suggest to do it by closing the connection!)
I tried to empty the inputStream this way-
byte[] eatup=new byte[20*1024];
int available=0;
while(true)
{
available=serverInputStream.available();
if(available==0)
break;
serverInputStream.read(eatup,0,available);
}
eatup=null;
String fileName=(String)serverInputStream.readObject();
Program should not process the line as nothing else is being written on the outputStream .
But my program executes it anyway and throws a java.io.OptionalDataException error.
Note: I am working on a client-server file transfer project. The client sends files to
the server. The second code is for server terminal. If 'cancel button' is pressed on server
end then it stops reading bytes from the serverInputStream and sends a signal(I used int -1)
to the client. When client receieves this signal it stops sending data to the server, but I've
noticed that serverInputStream is not empty. So I need to empty this serverInputStream so that
the client computer is able to send the server computer files again(That's why I can't manage a lock
from read method)
1 - No. On the flush() the data will be written to the OS kernel which will likely immediately hand it to the network card driver, which in turn will send it to the receiving end. In a nutshell the send is fire and forget.
2 - As Jeffrey commented available() is not reliable for this sort of operation. If doing blocking IO then as he suggests you should just use read() speculatively. However it should be said that you really need to define a protocol on top of the raw streams, even if it's just using DataInput/DataOutputStream. When using raw write/read the golden rule is one write != one read. For example if you were to write 10 bytes on one side and had a reading loop on the other there is no guarantee that one read will read all 10 bytes. It may be "read" as any combination of chunks. Similarly two writes of 10 bytes might appear as one read of 20 bytes on the receiving side. Put another way there is no concept of a "packet" unless you create a higher level protocol on top of the raw bytes to do packets. An example would be each send is prefixed by a byte length so the receiving side knows how much data to expect in the current packet.
If you do need to do anything more complicated than a basic apps I strongly encourage you to investigate some higher level libraries that have solved many of the gnarly issues of network IO. I would recommend Netty which I use for production apps. However it is quite a big leap in understanding from a simple IO stream to Netty's more event based system. There may be other libraries somewhere in the middle.
I have a webpage that makes an ajax call to get some data. That data takes a long time to calculate, so what I did was the first ajax server call returns "loading..." and then the thread goes on to calculate the data and store it in a cache.
meanwhile the client javascript checks back every few seconds with another ajax call to see if the cache has been loaded yet.
Here's my problem, and it might not be a problem. After the initial ajax to the server call, I do a
...getServletContext().getRequestDispatcher(jsppath).include(request, response);
then I use that thread to do the calculations. I don't mind tying up the webserver thread with this, but I want the browser to get the response and not wait for the server to close the socket.
I can't tell if the server is closing the socket after the include, but I'm guessing it's not.
So how can I forcibly close the stream after I've written out my response, before starting my long calculations?
I tried
o = response.getOutputStream();
o.close();
but I get an illegal state exception saying that the output stream has already been gotten (presumably by the jsp I'm including)
So my qestions:
is the webserver closing the socket (I'm guessing not, because you could always include another jsp)
if it is as I assume not closing the socket, how do I do that?
I don't see how you can even close the OutputStream if the calculation is still going on in the same thread.
You need to start the calculation in a new thread and just return from the Servlet and the response will be sent back automatically.
If you really need to close the writer, do this,
response.getWriter().close();